On Wed, 25 Apr 2007, Carl Worth wrote:
> On Mon, 23 Apr 2007 22:15:04 -0700, Junio C Hamano wrote:
> > Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> 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>".
> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html