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

[Carl Worth <cworth@cworth.org>]

[-- Attachment #1: Type: text/plain, Size: 3609 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]