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

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Apr 25, 2007, 19:44 UTC
Message-ID: <Pine.LNX.4.64.0704251345220.28708@iabervon.org>
In-Reply-To: <87mz0w7g3j.wl%cworth@cworth.org>

On Wed, 25 Apr 2007, Carl Worth wrote:

Show 22 quoted lines

> 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>".

Show 10 quoted lines

> 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*