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:
pgphLx3InKTRo.pgp
Description: PGP signature