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

[Daniel Barkalow <barkalow@iabervon.org>]

On Wed, 25 Apr 2007, Carl Worth wrote:

> On Wed, 25 Apr 2007 15:44:11 -0400 (EDT), Daniel Barkalow wrote:
> 
> > 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.

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