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

On Wed, 25 Apr 2007, Carl Worth wrote:

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

quoted

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.

Well, it's not only a private namespace, it's a namespace of stuff that 
should be meaningful to the user. Sure, there's a certain extent to which 
what's meaningful to the publisher is likely to be meaningful to the user, 
but I've used "subproject" to refer to a "submodule2" remote branch, 
because that's what I was naming the feature in my head, and I wouldn't 
have found the 2 intuitive in general (it was the second attempt at an 
implementation). It's fundamentally a local alias for a global name.

On the other hand, it might be good if the publisher could give 
instructions with an option that prompts the user with a sensible default, 
given the arguments and the state of the repository.

quoted

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 think there's likely to be a reasonably large variation in what 
repositories exist and what branches they have. People could easily have a 
repository per topic, with a branch per stable series (with experimental 
work being potentially queued for a relatively far future series). There 
could be shared repositories for features that multiple people work on, 
with per-person branches. People do all sorts of things, and even within a 
project, they don't all have to be the same, so long as the "URL branch" 
format works for everybody who has to get a branch. But that also means 
that it's hard to find a reliable meaningful sub-part of that format.

	-Daniel
*This .sig left intentionally blank*