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

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Apr 25, 2007, 22:39 UTC
Message-ID: <Pine.LNX.4.64.0704251743300.28708@iabervon.org>
In-Reply-To: <873b2o6vvk.wl%cworth@cworth.org>

On Wed, 25 Apr 2007, Carl Worth wrote:

Show 20 quoted lines

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

Show 14 quoted lines

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