Re: push.default???

Paolo Bonzini <bonzini@gnu.org> writes:

You cannot do anything "in 1.6.3"; The ship has already left the port.

You can set push.default to "tracking" and have it take effect for all remotes you interact with from your repository (set remote.$name.push for some remotes you do not want this to take effect). Instead, you could leave push.default to "matching" and define remote.$name.push with the "push tracking" magic you are going to invent for a specific remote.

Both arrangements can do the same thing, so even if your "HEAD>" is never supported, there is no functionality loss (similarly, if we did not have "push.default", we would be Ok if we had your "HEAD>" magic). Depending on which one you would want to use for majority of remotes you interact with, you would want both.

So in that sense, I do not think the current situation is such a "total nonsense" as you seem to be painting it [*1*]. It just does not have the other half of the story that you are bringing up now.

In other words, I do not have objection to your "HEAD>" at the conceptual level. At the syntax level, I suspect people will have suggestions for better alternatives.

In retrospect, because a push refspec (or "magic" you will be adding) for a specific remote is called "remote.$name.push", it might have been a better idea to use "remote.push" instead of "push.default" as the name of the configuration variable. Then the rules can become

	* if you ask explicitly from the command line, it wins;
	* otherwise, if you have remote.$name,push, it is used;
        * otherwise, if you have remote.push, it is used;
        * otherwise, the default is "matching".

which is slightly nicer to read, than the current situation where the third rule talks about push.default instead.

This is probably sensible if/when we do (1).  

But here I have to qualify what I mean by (1). I am not married to the idea of using remote.$name.push at all. I view (1) as solving this issue:

        Currently with push.default, we can only set push.default to
        something other than "matching" and have specific remote override
        that with remote.$name.push with a more concrete refspec, if we
        want to have the magic 'tracking push' semantics.

        We want to have a way to say "for this and that particular
        remotes, use the magic tracking push" in a more direct way.

And hiding the detail of how this "direct way" is implemented from the end user is a good idea.

This contradicts with (1), I think. The default after cloning is "matching", and if one wants to change it to "track", one not just needs to set push.default but also needs to remove/twaek remote.origin.push if you add such a line.

So I do not think this one makes much sense.

This was already part of one possible option for push.default (change the built-in default to 'nothing-and-warn') when it was introduced, wasn't it? Instead of suggesting to configure remote.$name.push, it would suggest to set push.default to a desired value, which I think is a more sensible thing to do.

[Footnote]

*1* ... even though I admit that I am not convinced 'push "tracking"' makes much sense for me to begin with, because pushing a branch to the branch it forked from rarely if ever makes sense in my workflow. But I can see 'push "tracking"' makes sense in some situations and people seem to want to do this, so we have already added push.default.