On Wed, 25 Apr 2007, Carl Worth wrote:

quoted text
> On Mon, 23 Apr 2007 22:15:04 -0700, Junio C Hamano wrote:
> > Linus Torvalds <torvalds@linux-foundation.org> writes:
> >
> > > I'd personally be ok with a
> > >
> > > 	git clone --default=<branch> <url>
> ...
> > 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>".

quoted text
> 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*
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html