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* - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html