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

On Wed, 25 Apr 2007 15:44:11 -0400 (EDT), Daniel Barkalow wrote:

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

That's a fine syntax too.

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

Yes. That's exactly what I'm talking about, being able to very easily
just paste the branch specifier to a git command. And yes, it would
be convenient if one could do this for as many commands as
possible. The fact that git-clone can't accept this syntax is
unfortunate, (and maybe that is the only reason I was inclined to add
the '#' character).

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]

OK, that still allows for pasting the URL and branch, but the user has
to know not only "git track" but also that she must invent a local for
the branch and insert that into the command as well. And it's hard for
me to help the user on this point (at least in a cut-and-pasteable
way), since the whole point of that argument is to create an entry in
a private namespace that I don't know anything about.

How about making that optional at least? That is create a local branch
named <branch> for:

	git track URL <branch>

but also allow something like:

	git track --as <newbranch> 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]

Yes, this is the kind of stuff I'd like to see. Just create a remote
on behalf of the user with whatever unique name you want, (or use an
existing remote if one already exists for the given URL).

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.

Yes, I would agree with that.

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.

Ah, that's an interesting point.

It's interesting because it's obviously the case for some projects,
but it's also not the case for some, (like the cairo project that I
care about). Maybe we're still overly accustomed to our "central"
mentality, but we don't really have a lot of interesting "master"
branches in our personal repositories. Instead, the central repository
has "master" and one branch for each stable maintenance series, then
each developer's personal repository has a collection of topic
branches for stuff that is cooking.

I guess we just don't have sub-maintainers maintaining entire
collections of patches with git like you get with the kernel for
example.

-Carl