Re: [PATCH] pull: refuse complete src:dst fetchspec arguments

On Thu, 22 Oct 2009, Jeff King wrote:

On Wed, Oct 21, 2009 at 10:05:27AM +0200, Thomas Rast wrote:

quoted

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*