On Sun, Feb 10, 2008 at 02:59:18PM -0800, Junio C Hamano wrote:

quoted text
> > ... Are there any
> > other git commands which use non-HEAD branches that have not been
> > explicitly mentioned by the user?  I can think only of query-type
> > commands (like show-branch, or describe) that are non-state-changing.
> 
> That's an irrelevant comparison.  push and fetch have always
> been multi-branch operations by default from day one.  The issue
> is not HEAD vs non-HEAD.

I think "irrelevant" here is in the eye of the beholder. If you are
coming from the perspective of "historical behavior" then the current
behavior makes sense. If you are coming from the perspective of a user
who does not typically do a lot of branching, then the behavior can be
surprising. And I think there is anecdotal evidence that some users _do_
find this surprising. I have personally seen it, and I think even an
experienced user like Martin is finding the behavior non-intuitive.

quoted text
> You can argue that historically established practices do not
> matter at all (at least to new people), and I'd grant that it
> may be a valid argument.  But a change that breaks existing
> practices needs to be sold much more carefully.  I still do not

Agreed.

quoted text
> understand what the opposition is to keep the current behaviour
> as the default and have a shorthand for the single head push
> accessible with a short and sweet "git push $there HEAD" (and
> default $there to 'origin' when missing).

I think the problem is that you are asking people with particular
workflows to always remember to type something extra, and if they
forget, you punish them by doing a potentially destructive operation
(although admittedly, it is destructive only if you happen to be using
"-f").

quoted text
> If you are introducing a new behaviour, there is no way the new
> behaviour can start out by replacing the longtime default.  It
> should start out as an option, and if it is a commonly useful
> option then make it an _easily accessible_ option.  And accept
> such an _enhancement_ sooner to help people who want such a
> behaviour sooner.  That would not hurt anybody but help
> (hopefully) many people, without downside.

I think we already have that option (as you mentioned): "git push $there
HEAD". We can make it more easily accessible (as you have proposed):
"git push HEAD" (though I still have some reservations about that). But
none of that changes the fact that for some people's workflows, they
will _always_ have to remember to add extra magic to the command line.

What I have proposed is adding a config option to make that option even
more easily accessible. The only argument I have seen against that is
"some users can't use other users' git setup". While this is a downside,
I think this uncommon situation is outweighed by the very common
situation of users using their _own_ git setups.

IOW, such an option makes a tradeoff. Users helping other users must
explicitly say what they mean: "git push --matching" or "git push $there
HEAD". But users using their own setups can use the shorthand "git push"
to do what is most useful for their workflow. And I think we should
optimize for the latter case, as it is much more common.

-Peff
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html