On Thu, 22 Oct 2009, Jeff King wrote: > On Wed, Oct 21, 2009 at 10:05:27AM +0200, Thomas Rast wrote: > > > What if any combination of fetch and merge always gave you the long > > form? After all, even if you do have a tracking branch for whatever > > you are merging, that information is probably useless and it would be > > nicer if all of the following resulted in the long form: > > > > * git fetch git://git.kernel.org/pub/scm/git/git pu > > git merge FETCH_HEAD > > > > * git remote add origin git://git.kernel.org/pub/scm/git/git > > git fetch origin > > git merge origin/pu > > > > * git fetch git://git.kernel.org/pub/scm/git/git pu:tmp > > git merge tmp > > Maybe it's just me, but I actually prefer the shorthand names. Five > years from now when I browse the history and see that I merged > remote branch "mike/topic", I'll know exactly what that means: developer > Mike's version of a certain topic branch. But I am not likely to care > about exactly where we were storing developer repos at that time. > > But probably that is an artifact of the workflow. The scenario I am > describing above implies a somewhat centralized workflow, where the > shorthand contains all of the interesting information. In a totally > distributed, we-don't-share-anything-except-the-url-namespace setup of > an open source repo, the full URL makes more sense. > > So maybe it is something that should be optional. Surely you ought to be able to get the short form with "pull", though, if you happen to like short forms. So it would make sense to decide how to format the merge message based entirely on an option, not at all on whether you use pull or fetch+merge. -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