Jonathan Nieder <> writes:

>> We are in the middle of 5th week now in the 11-week releace cycle
>> for 1.8.4 (, and quite a few topics have
>> graduated to 'master'.  I'd expect the rest of the week to be slow.
> I'd like this or the next release to be 2.0, so the common user
> trouble with "git push" pushing more branches than they intended can
> be over.  Am I crazy?  If not, what can I do to help make it happen?

There are currently three topics slated for 2.0 that changes the
default behaviours in a big way.  The default of the push behaviour
switching from matching to simple is one of them, and it has been
advertised with advice messages since 1.8.0 (Oct 2012).

The other two, "git add -u/-A" without pathspec to operate on the
entire tree, and "git add" with pathspec acting as if it were given
"-A" option to also record removals to the index, haven't had enough
time to be imprinted in users' minds.  The former was only mentioned
in the release notes of 1.8.2 (Mar 2013), and the advertisement for
the latter change appeared first in 1.8.3 (May 2013).

I'd prefer to see users have enough time to adjust to these big
changes, at least 6 months (but preferrably 9 months).  I would say
that the change to the default "git push" behaviour may have had
enough preparation period, but the other two that are scheduled for
2.0 is way too young.

With recent "triangular" addition by Ram, the "simple" mode, the
future behaviour of "git push", was again changed, and has not have
enough time to mature (isn't it still in 'next'?).

Regarding that "simple" thing, I am not sure if the "if you are
pushing to a remote that is different from where you fetch from, we
do exactly the same as 'current'", which is what we tentatively
agreed to implement, is safe enough for new people.  I suspect we
may want to tighten it a bit more (it would update the branch with
the same name as your current local branch, but never try to create
such a branch at the remote, for example).

So in that sense, even the change to "git push" default may not be
old enough for the upcoming release or the next one.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to