Re: Making git disappear when talking about my code (was: Re: GIT vs Other: Need argument)

On Wed, 25 Apr 2007, Carl Worth wrote:

On Mon, 23 Apr 2007 22:15:04 -0700, Junio C Hamano wrote:

quoted

Linus Torvalds [off-list ref] writes:

quoted

I'd personally be ok with a

	git clone --default=<branch> <url>

...

quoted

If Carl is also happy with the syntax, we can conclude this
discussion and:

 (1) have that as an enhancement to git-clone;

I think it's a useful enhancement. It would let me at least document
something like "tracking this project's stable branch" with a single
command, which I think is useful. But I don't know that I would be
totally happy yet. :-)

So please allow me to comment on the syntax a bit. Linus, you claimed
that <url>#<branch> isn't "unixy" enough for your taste. What does
that mean exactly? Is it that two logically independent things are
crammed into a single argument instead of being passed as second
arguments? Or something else?

Linus has stated a preference on the lkml for being told about branches in 
the syntax used for anonymous pulls: URL branchname.

That is, you say:

  Please pull from:
    git://server/path branch

And he cuts and pastes into the command line:

  git pull git://server/path branch

Now, this syntax isn't available for git-clone, because git-clone puts the 
optional directory to create after the URL. But, in an ideal world, this 
is how it would work; you could see a pull request, and just type "git 
some-command <paste>".

Here's the reason I want both the URL and the branch to appear as a
single string, (but I don't really care about the precise syntax). I
really want to be able to say "see my branch at <string>" and have
that <string> be a complete and self-contained description of the
branch that can be used in several different ways including:

* Cloning a new repository to track that branch as the default

* Begin tracking that branch as a new branch within an existing
  repository

Here, you probably need to specify what you want the new branch to be, 
because it will often be the case that the remote branch will be "master" 
in a repository with a long unrecognizable URL, and you need to be able to 
switch to and away from the branch in some sane way. On the other hand, 
the user will presumably never care too deeply about the remote, aside 
from that git remembers stuff appropriately. I say, use the hash of the 
URL as the name of the remote, and provide some shorthand for the tracking 
branch that would be merged by default into the current head, and you're 
set. I.e.:

git track new-name URL [branch]

creates and checks out a new branch "new-name" with the config:

[remote "hash of URL"]
	url = URL
	fetch = +refs/heads/*:refs/remotes/hash of URL/*
[branch "new-name"]
	remote = "hash of URL"
	merge = refs/heads/[branch]

When on this branch, you update with "git pull" (which already works, 
given this configuration). And there would just need to be a better way of 
doing "git log remotes/hash of URL/branch..HEAD", which should probably be 
something like "git log MERGE..HEAD", with MERGE being magic for the thing 
that tracks the current branch's "merge" setting.

Incidentally, I'm not seeing the case of wanting to track multiple 
branches from the same repository as nearly as likely for a novice as 
wanting to track multiple branches from different repositories. I think 
the likely order of being interested in things is:

1. The project's maintainer's repository, exactly one of maint, master, or 
   next.
2. Somebody else's repository for some interesting feature, master
3. Somebody else's repository for all interesting features, some branch
4. Repository from 3, additional branches
5. Maintainer's repository, multiple branches.

With the most common case for two tracking branches being master from two 
repositories, such that upstream branch names are most often useless for 
distinguishing anything.

	-Daniel
*This .sig left intentionally blank*