Please discuss: what "git push" should do when you do not say what to push?

[Junio C Hamano]

There is a proposal to change the default behaviour of 'git push' on the
Git mailing list. The goal of this message is to encourage you to discuss
it before it happens (or the change is aborted, depending on the outcome
of the discussion).

In the current setting (i.e. push.default=matching), 'git push' without
argument will push all branches that exist locally and remotely with the
same name. This is usually appropriate when a developer pushes to his own
public repository, but may be confusing if not dangerous when using a
shared repository. The proposal is to change the default to 'upstream',
i.e. push only the current branch, and push it to the branch 'git pull'
would pull from. Another candidate is 'current'; this pushes only the
current branch to the remote branch of the same name.

For more details on the behavior of Git with these values, read the
documentation about 'push.default' in 'man git-config'
(http://schacon.github.com/git/git-config.html).

You may be negatively affected when such a change happens if you do not
see anything in the output from 'git config push.default' and if you rely
on the default that pushes all your matching branches. On the other hand,
you may want to see the default behaviour to change, especially if you are
using shared repositories. In either case, please join the discussion to
give us more data point and help us decide the future of Git. Also, if
you think your friends and colleagues will be affected by this change,
either positively or negatively, please tell them about this discussion.

What has been discussed so far can be seen in this thread:

http://thread.gmane.org/gmane.comp.version-control.git/192547/focus=192694

Previous relevant discussions include:

http://thread.gmane.org/gmane.comp.version-control.git/123350/focus=123541
http://thread.gmane.org/gmane.comp.version-control.git/166743

To join the discussion, send your messages to:

***@vger.kernel.org

The list accepts messages from non-subscribers, and you do not have to ask
"please Cc me, I am not subscribed", as it's customary to Cc: posters when
replying on this list.

[Junio C Hamano]

If the conclusion of the discussion is that we will change the default,
the transition to the new default will go like this:

1. An announcement message to let the user communities know about the
future change will be distributed in a way similar to the previous
request-for-discussion message was distributed.

2. The first version of Git that is released after such an announcement
will start issuing a warning when you type "git push" to send the
matching branches to the default location unless you have configured
push.default variable. The users who want to keep the current default
can do

$ git config push.default matching

and the users who want to use different settings can do one of:

$ git config push.default current
$ git config push.default upstream
$ git config push.default nothing

to silence this warning. The warning will be issued unless you do so,
to help those who missed the message #1.

3. We wait for a few release cycles.

4. The default changes. If you do not configure push.default variable,
it no longer defaults to matching, but does something else (the choice
among the three other alternatives will be decided in the discussion).
The warning message will be reworded---instead of saying "will stop
being the 'matching' in the future", it will say "has changed to X".

5. We wait for a few release cycles.

6. The warning is removed.

A typical release cycle lasts for 8-10 weeks.

[Andrew Sayers]

Post by Junio C Hamano
If the conclusion of the discussion is that we will change the default,
1. An announcement message to let the user communities know about the
future change will be distributed in a way similar to the previous
request-for-discussion message was distributed.
2. The first version of Git that is released after such an announcement
will start issuing a warning when you type "git push" to send the
matching branches to the default location unless you have configured
push.default variable. The users who want to keep the current default
can do
$ git config push.default matching
$ git config push.default current
$ git config push.default upstream
$ git config push.default nothing
to silence this warning. The warning will be issued unless you do so,
to help those who missed the message #1.
3. We wait for a few release cycles.
4. The default changes. If you do not configure push.default variable,
it no longer defaults to matching, but does something else (the choice
among the three other alternatives will be decided in the discussion).
The warning message will be reworded---instead of saying "will stop
being the 'matching' in the future", it will say "has changed to X".
5. We wait for a few release cycles.
6. The warning is removed.
A typical release cycle lasts for 8-10 weeks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
More majordomo info at http://vger.kernel.org/majordomo-info.html

Unfortunately, "a few release cycles" strikes me as a rather hopeful
description. For example, a user installing the new Ubuntu LTS release
(due out next month) would feel completely justified in not upgrading
until 2017, whereas the rest of us would get rather bored disabling the
same old warning in every new repo we create for the next five years.

Could I suggest when a user inits/clones a new repository using a
post-change version of git, we do an automatic `git config
push.warned_about_default_change true`, then warn forevermore when users
push from a repo with neither that option nor a push.default? This will
warn existing users with arbitrarily long upgrade cycles, and reduce the
amount of noise during the (necessarily) already noisy first days of a
new repo.

FWIW, I've been stung by the old behaviour and think the change of
default is a great idea, but have nothing more useful to add :)

- Andrew

[Junio C Hamano]

Post by Andrew Sayers

Post by Junio C Hamano
If the conclusion of the discussion is that we will change the default,
1. An announcement message to let the user communities know about the
future change will be distributed in a way similar to the previous
request-for-discussion message was distributed.
2. The first version of Git that is released after such an announcement
will start issuing a warning ...
3. We wait for a few release cycles.
4. The default changes. ...
The warning message will be reworded ...
being the 'matching' in the future", it will say "has changed to X".
5. We wait for a few release cycles.
6. The warning is removed.
A typical release cycle lasts for 8-10 weeks.

Unfortunately, "a few release cycles" strikes me as a rather hopeful
description. For example, a user installing the new Ubuntu LTS release
(due out next month) would feel completely justified in not upgrading
until 2017, whereas the rest of us would get rather bored disabling the
same old warning in every new repo we create for the next five years.

There is nothing hopeful about it.

The point of a release like LTS is to shield the users of the distribution
from what happens in upstream, so it is up to the distro to help users. We
do not have a way to help their users in a direct way, other than letting
the distro know about the change, and educate the distros how they help
their users.

If I were a user of such a distro whose sole point is a long term support,
I would expect that a LTS that was originally released before point #2
whose lifespan extends beyond point #6 to backport only the "warning"
changes to such a release between #2 and #6 timespan as a point update to
such a LTS release. Otherwise the distro is actively doing a disservice to
its users. Such a distro can also choose to revert the "warning removal"
change #6 in their binary when they release a new LTS. If they did not
backport "add warning" to their earlier LTS release, that is at least what
they can do to help their users.

But again, that is not something we have direct control over, and it is
not very useful to discuss this on this list. Ubuntu LTS support forum
might be a better place, but in short, it is not a problem we can solve
(nor we should be solving), as long as we have a reasonable migration plan
and if the user is locked out of that migration plan---whoever is doing
the locking-out is taking responsibility for these users who are out of
our reach.

[Ævar Arnfjörð Bjarmason]

But again, that is not something we have direct control over [...]
---whoever is doing the locking-out is taking responsibility for
these users who are out of our reach.

Firstly I'm all for this change, but I agree with Andrew Sayers that
step the deprecation plan is somewhat questionable.

I contribute to the perl core and a few years ago we moved to make
yearly releases, at the same time we introduced a deprecation cycle
saying that if we warn that something will be removed in $YEAR it's
kosher to remove it in $YEAR+2.

The problem with that approach is that as Andrew points out OS release
cycles aren't yearly, so someone might upgrade from $YEAR-2 to YEAR+3
and find that his programs don't compile anymore.

Git is similar to Perl in that most of our users don't get Git from us
with any regular interval, they just use whatever's packaged by their
OS, and in practice:

* Most of your users use your program through their OS vendor

* OS vendors will upgrade their OS whenever they feel like it.

* OS vendors are in all likelyhood not going to backport some
deprecation patch or eject it from their build in a manner that
makes sense with regard to their release schedule.

That sucks, but given that this is how things work I wonder who we're
really helping by implementing deprecation warnings from the
standpoint of our release cycle, probably not the majority of our
users.

Most of our users are either never going to see this warning because
their OS will skip the whole of steps 2-6, or worse yet their OS
might upgrade Git between steps 2-5 and they'll be stuck watching the
warning it for 1-6 years, or however long their upstream vendor takes
up upgrade.

I think a better strategy would be to just announce that we're going
to change it, and then just change it without any intermediate
steps. That's what this is going to look like anyway to most of our
users, and without the danger that our users will be stuck on releases
that'll spew warnings about some upcoming change which in reality
happened in upstream years ago.

We could even use the only way of communicating to everyone involved
that something major changed: bump the major version number.

[Junio C Hamano]

Post by Ævar Arnfjörð Bjarmason
Most of our users are either never going to see this warning because
their OS will skip the whole of steps 2-6, or worse yet their OS
might upgrade Git between steps 2-5 and they'll be stuck watching the
warning it for 1-6 years, or however long their upstream vendor takes
up upgrade.
I think a better strategy would be to just announce that we're going
to change it, and then just change it without any intermediate
steps.

You are only arguing that what we do does not matter much to Distro use=
rs,
and you already read that I agreed with that. It's really up to the dis=
tro
to make sure their release cycle does not harm the users.

But does that mean we won't have to help our own users who do not depen=
d
on distros with a gentler approach? I don't think so.

Just like we say we would want to see Perl 5.8.3 or newer for unicode
purposes, it would be sufficient if our announce says Git 1.8.x and lat=
er
gives an updated default behaviour to help new people by avoiding a har=
der
to understand error modes when used in the simplest workflow.

[Sebastien Douche]

On Mon, Mar 19, 2012 at 01:29, Junio C Hamano <***@pobox.com> wrote=
:

Hi Junio

But does that mean we won't have to help our own users who do not dep=

end

on distros with a gentler approach? =C2=A0I don't think so.

It's here a very particular change: most users don't use / don't like
the default behaviour. Most of them will be happy with this change.


--=20
Sebastien Douche <***@gmail.com>
Twitter: @sdouche / G+: +sdouche

[Andrew Sayers]

Post by Junio C Hamano

Post by Andrew Sayers

Post by Junio C Hamano
If the conclusion of the discussion is that we will change the default,
1. An announcement message to let the user communities know about the
future change will be distributed in a way similar to the previous
request-for-discussion message was distributed.
2. The first version of Git that is released after such an announcement
will start issuing a warning ...
3. We wait for a few release cycles.
4. The default changes. ...
The warning message will be reworded ...
being the 'matching' in the future", it will say "has changed to X".
5. We wait for a few release cycles.
6. The warning is removed.
A typical release cycle lasts for 8-10 weeks.

Unfortunately, "a few release cycles" strikes me as a rather hopeful
description. For example, a user installing the new Ubuntu LTS release
(due out next month) would feel completely justified in not upgrading
until 2017, whereas the rest of us would get rather bored disabling the
same old warning in every new repo we create for the next five years.

There is nothing hopeful about it.
The point of a release like LTS is to shield the users of the distribution
from what happens in upstream, so it is up to the distro to help users. We
do not have a way to help their users in a direct way, other than letting
the distro know about the change, and educate the distros how they help
their users.
If I were a user of such a distro whose sole point is a long term support,
I would expect that a LTS that was originally released before point #2
whose lifespan extends beyond point #6 to backport only the "warning"
changes to such a release between #2 and #6 timespan as a point update to
such a LTS release. Otherwise the distro is actively doing a disservice to
its users. Such a distro can also choose to revert the "warning removal"
change #6 in their binary when they release a new LTS. If they did not
backport "add warning" to their earlier LTS release, that is at least what
they can do to help their users.
But again, that is not something we have direct control over, and it is
not very useful to discuss this on this list. Ubuntu LTS support forum
might be a better place, but in short, it is not a problem we can solve
(nor we should be solving), as long as we have a reasonable migration plan
and if the user is locked out of that migration plan---whoever is doing
the locking-out is taking responsibility for these users who are out of
our reach.
--
To unsubscribe from this list: send the line "unsubscribe git" in
More majordomo info at http://vger.kernel.org/majordomo-info.html

I take the point that distros have their own support infrastructure, so
perhaps this would be a better example:

Many administrators in corporate environments will install git from
source, because they don't trust RPM/need some feature in the latest
version/are just that way inclined. Having installed it, they tend to
sit on that version for a few years until they have to upgrade the
system/need some feature in the new latest version/are still just that
way inclined. Their justification for not upgrading is often that new
versions of software tend to change behaviour in subtle ways that break
the scripts they've bodged together over the years. Trying to argue
that one particular bit of software will only hurt you if you wait for
the wrong amount of time tends to be a losing battle, because
administrators hate special cases just as much as programmers.

Having said all that, here's a slightly different argument for a
slightly better solution:

When a user upgrades to a mid- or post-change version of git, I think
it's a good idea for them to be warned about the change of behaviour.
But new users, and old users with new repositories, gain nothing from
the little history lesson. This should be solved in git itself, because
two users of the same binary might expect different behaviour. An
automatic `git config push.default <whatever>` at repository creation
time would silence the noise without disrupting the signal. As an added
bonus, this approach might take some heat out of the argument when the
umpteenth "is it time to remove the warning yet?" thread kicks off.

- Andrew

[Junio C Hamano]

Post by Andrew Sayers

... but in short, it is not a problem we can solve
(nor we should be solving), as long as we have a reasonable migration plan
and if the user is locked out of that migration plan---whoever is doing
the locking-out is taking responsibility for these users who are out of
our reach.

I take the point that distros have their own support infrastructure, so
Many administrators in corporate environments will install git from
source, because they don't trust RPM/need some feature in the latest
version/are just that way inclined. Having installed it, they tend to
sit on that version for a few years ...

The same response applies. These administrators are taking responsibility
for their users by making them out of our reach.

Post by Andrew Sayers
... a
When a user upgrades to a mid- or post-change version of git, I think
it's a good idea for them to be warned about the change of behaviour.
But new users, and old users with new repositories, gain nothing from
the little history lesson.

You are right for new users, but are wrong for old users who aren't aware
of the switch-over, *and* are harmed by the switch-over.

[demerphq]

... but in short, it is not a problem we can solve
(nor we should be solving), as long as we have a reasonable migrati=

on plan

and if the user is locked out of that migration plan---whoever is d=

oing

the locking-out is taking responsibility for these users who are ou=

t of

our reach.

I take the point that distros have their own support infrastructure,=

so

Many administrators in corporate environments will install git from
source, because they don't trust RPM/need some feature in the latest
version/are just that way inclined. =A0Having installed it, they ten=

d to

sit on that version for a few years ...

The same response applies. These administrators are taking responsibi=

lity

for their users by making them out of our reach.

... a
When a user upgrades to a mid- or post-change version of git, I thin=

k

it's a good idea for them to be warned about the change of behaviour=

=2E

But new users, and old users with new repositories, gain nothing fro=

m

the little history lesson.

You are right for new users, but are wrong for old users who aren't a=

ware

of the switch-over, *and* are harmed by the switch-over.

What is your definition of "harmed" in this case? I do not see how a
change like this could cause harm. I can see how it could cause
disharmony, but that is not the same. I thought the worse case here is
minor inconvenience, not data loss or anything else that is obviously
harmful.

cheers,
Yves

--=20
perl -Mre=3Ddebug -e "/just|another|perl|hacker/"

[Junio C Hamano]

... I thought the worse case here is
minor inconvenience, not data loss or anything else that is obviously
harmful.

If your definition of harm is limited to data loss then we wouldn't be
talking about updating the default from matching to current or upstream.
"If your push failed, pushed what you did not mean to, or did not push
what you meant to, you would correct the mistake" applies equally to a new
person who expected "current" (or "upstream") and got "matching", or an old
person who expected "matching" and got "current".

The purpose of the default change is to reduce surprises to people who
haven't yet learned Git too well. And for them,

I was on master, I said 'git push' without saying what to push to
where, and it resulted in master updated at the central repository.

is the least surprising outcome. Note that a learnt Git user would not
express what he did this way; he will say 'I was on *my* master' and
'the master at the central repository was updated with *my* master', but
the change of the default is to help those who haven't even learned that
your branches and branches at the central server are not always connected.

Choice of "upstream" is more convenient for users who learned Git a bit
more and knows the distinction between branches you have and branches the
central server has. For them, "I was on my 'topic' branch, that was
forked from the 'master' branch at the central repository. I said 'git
push', and I updated the 'master' over there with my 'topic'", is also not
surprising, but it is more advanced audience than those helped by the
default setting to push 'current'.

In either way, once people learn sufficiently to the point that they can
choose their own default that suit them, there is no need for handholding.
They won't be surprised.

But except for one case you should *not* forget about.

The ones who get pulled the old default under their feet while not paying
too much attention to this discussion. The change will hit them with a
surprise, and that is what I am trying to avoid here.

[Andreas Ericsson]

I just realized I've had the proposed behaviour for "upstream" backwards
all along. I thought "upstream" was meant to do what "matching" does
today.

I'd like to change my vote to "upstream" instead, although I think the
name for it is truly horrible. Perhaps that's just me though, since
we're using "upstream" as a remotename for repositories we get from
afar but work on internally as well.

Post by Junio C Hamano

... I thought the worse case here is
minor inconvenience, not data loss or anything else that is obviously
harmful.

If your definition of harm is limited to data loss then we wouldn't be
talking about updating the default from matching to current or upstream.
"If your push failed, pushed what you did not mean to, or did not push
what you meant to, you would correct the mistake" applies equally to a new
person who expected "current" (or "upstream") and got "matching", or an old
person who expected "matching" and got "current".
The purpose of the default change is to reduce surprises to people who
haven't yet learned Git too well. And for them,
I was on master, I said 'git push' without saying what to push to
where, and it resulted in master updated at the central repository.
is the least surprising outcome. Note that a learnt Git user would not
express what he did this way; he will say 'I was on *my* master' and
'the master at the central repository was updated with *my* master', but
the change of the default is to help those who haven't even learned that
your branches and branches at the central server are not always connected.
Choice of "upstream" is more convenient for users who learned Git a bit
more and knows the distinction between branches you have and branches the
central server has. For them, "I was on my 'topic' branch, that was
forked from the 'master' branch at the central repository. I said 'git
push', and I updated the 'master' over there with my 'topic'", is also not
surprising, but it is more advanced audience than those helped by the
default setting to push 'current'.
In either way, once people learn sufficiently to the point that they can
choose their own default that suit them, there is no need for handholding.
They won't be surprised.
But except for one case you should *not* forget about.
The ones who get pulled the old default under their feet while not paying
too much attention to this discussion. The change will hit them with a
surprise, and that is what I am trying to avoid here.
--
To unsubscribe from this list: send the line "unsubscribe git" in
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Andrew Sayers]

Post by Junio C Hamano

Post by Andrew Sayers

... but in short, it is not a problem we can solve
(nor we should be solving), as long as we have a reasonable migration plan
and if the user is locked out of that migration plan---whoever is doing
the locking-out is taking responsibility for these users who are out of
our reach.

I take the point that distros have their own support infrastructure, so
Many administrators in corporate environments will install git from
source, because they don't trust RPM/need some feature in the latest
version/are just that way inclined. Having installed it, they tend to
sit on that version for a few years ...

The same response applies. These administrators are taking responsibility
for their users by making them out of our reach.

I'm not sure I follow. It sounds like you're saying we should avoid
helping anyone that doesn't stick to our upgrade schedule, but that
would mean it's redundant to add code at all - all the publicity this
change has got means everyone close enough to the process has heard
about it already.

Post by Junio C Hamano

Post by Andrew Sayers
... a
When a user upgrades to a mid- or post-change version of git, I think
it's a good idea for them to be warned about the change of behaviour.
But new users, and old users with new repositories, gain nothing from
the little history lesson.

You are right for new users, but are wrong for old users who aren't aware
of the switch-over, *and* are harmed by the switch-over.

You're right that the solution I suggested would harm people who
regularly create new repositories, but have written scripts that expect
the old behaviour in those new repositories. The only solution that
would completely avoid harming that small group would be to permanently
make the default push.default "print a warning and give up" - otherwise
you're just harming people with long schedules instead of those with
short ones.

- Andrew

[Junio C Hamano]

Post by Andrew Sayers

Post by Junio C Hamano
The same response applies. These administrators are taking responsibility
for their users by making them out of our reach.

I'm not sure I follow. It sounds like you're saying we should avoid
helping anyone that doesn't stick to our upgrade schedule,...

I am not saying "should avoid". I am saying it is not much use.

All we can do is to inform, educate and help those who are taking
responsibility, be it LTS distro or these administrators, to help their
users. I've already outlined what LTS distros could do with backporting
and reverting in the previous message.

We can make sure that the "default flip" and "stop warn" patches can be
easily cherry-picked by them, even though we cannot force them to do so.

[Andrew Sayers]

Post by Junio C Hamano

Post by Andrew Sayers

Post by Junio C Hamano
The same response applies. These administrators are taking responsibility
for their users by making them out of our reach.

I'm not sure I follow. It sounds like you're saying we should avoid
helping anyone that doesn't stick to our upgrade schedule,...

I am not saying "should avoid". I am saying it is not much use.
All we can do is to inform, educate and help those who are taking
responsibility, be it LTS distro or these administrators, to help their
users. I've already outlined what LTS distros could do with backporting
and reverting in the previous message.
We can make sure that the "default flip" and "stop warn" patches can be
easily cherry-picked by them, even though we cannot force them to do so.

So we've identified the following groups:

1. People who can't be harmed by this change (e.g. new users and people
that would only ever use the new default behaviour)

2. People who are harmed by this change, and get information from this
list via some direct or indirect means (e.g. kernel devs or people using
a well-behaved distro)

3. People who are harmed by this change, are impervious to information
from this list, but update at sensible intervals and pay attention to
warning messages (e.g. corporate environments with frequent upgrade cycles)

4. People who are harmed by this change, are impervious to information
from this list, update at long intervals and pay attention to warning
messages (e.g. corporate environments with infrequent upgrade cycles)

5. People who are harmed by this change, upgrade their system
occasionally, but don't want to hear about behaviour changing from what
it has always been (Slackware users ;)

I guess we can agree that group 1 is already well cared for by recent
publicity, and group 5 is beyond our ability to handle.

Easy-to-cherry-pick patches are a good solution for group 2 - how about
also making a second "default flip" patch available earlier, for people
that want to go ahead of the main repo? For example, Debian might want
to put this patch in before a feature freeze hits so that their build of
git behaves the same as everyone else once they've finished the
extensive QA process for the distro.

Warning messages as you've described them are a good solution for group
3. I think we disagree about the size of this group, but I've only got
anecdotal evidence so what do I know.

People in group 4 aren't served well by any solution that involves some
day removing the warning altogether, because there will always be
someone that upgrades the day after we remove the warning and says "why
wasn't I informed?".

I assume the reason for removing the warning altogether is that some day
the signal:noise ratio will just get too bad. Improving the S:N ratio
strikes me as useful even ignoring group 4, but anything that increases
the amount of time we can warn means that more of them will be informed.

This might have been implicit all along, but one easy way to improve the
S:N ratio would be to have the warning message tell people to use `git
config --global`. Then people only ever need to see the message once
each, no matter how many repos they create.

We could also try to measure the S:N ratio by having a period where the
message says "... please e-mail ***@vger.kernel.org if you found this
message useful, otherwise we'll assume nobody cares and delete it".
Then when somebody comes along and asks why they weren't informed, we at
least have a good answer.

Finally, as a modification to my previous suggestion, we could `git
config push.default <whatever>` when new repos are created and no
global/system push.default is found, *instead* of removing the warning
altogether at the end of the process. This would mean that everyone in
group 3 is informed, as are the vast majority of group 4. The only
people that can then be harmed are those that do an exceptionally good
job of disguising themselves as new users (e.g. scripts that regularly
create throw-away repositories without ever looking at old ones).

- Andrew

[Junio C Hamano]

Post by Andrew Sayers
I assume the reason for removing the warning altogether is that some day
the signal:noise ratio will just get too bad.

The reasoning is a lot simpler than that.

If the end game is not remove the warning, then we would be switching to a
new default that is "give loud warning until the user configures her own
default, but push upstream/current anyway" mode. We do not want such a
stupid mode as the default---we want the default to be either upstream or
current at the end, when nobody remembers what the ancient default was.

The "warn loud but do it anyway" is a very good interim step during the
migration, but is never a good default. If we are going to stop there,
"give loud warning until the user chooses and configures the default, and
push nothing" mode would be a LOT safer and saner default, as it would
really force people to configure the default. Obviously we do not want to
go there, so...

[Andrew Sayers]

Post by Junio C Hamano

Post by Andrew Sayers
I assume the reason for removing the warning altogether is that some day
the signal:noise ratio will just get too bad.

The reasoning is a lot simpler than that.
If the end game is not remove the warning, then we would be switching to a
new default that is "give loud warning until the user configures her own
default, but push upstream/current anyway" mode. We do not want such a
stupid mode as the default---we want the default to be either upstream or
current at the end, when nobody remembers what the ancient default was.
The "warn loud but do it anyway" is a very good interim step during the
migration, but is never a good default. If we are going to stop there,
"give loud warning until the user chooses and configures the default, and
push nothing" mode would be a LOT safer and saner default, as it would
really force people to configure the default. Obviously we do not want to
go there, so...

It sounds like we're disagreeing, but I can't tell what about. I agree
that "warn loud but do it anyway" is a bad default in the long term. I
propose implementing the behaviour you want by adding a push.default
setting to the .git/config file for all new repositories, so that users
with a longer-than-expected short term still get the warning. That
should warn 99% of the people who need it without bothering anyone that
doesn't. What am I missing?

- Andrew

[Junio C Hamano]

Post by Andrew Sayers
It sounds like we're disagreeing, but I can't tell what about.

You are trying to read me too deeply, when there is nothing that deep to
read, by for example assuming the s/n ratio is why we want to keep the
warning only for a while and then eventually removing.

[Martin Langhoff]

If the conclusion of the discussion is that we will change the defaul=

t,
I am in general agreement with the course of action outlined. There is
one little thing I had expected in addition, that is not discussed:

--force should change behaviour, immediately, to "current" or even
none (forcing the user to name the remote and branch explicitly).

The potential for messups with --force combined with "matching" and a
repo that allows it is considerable. And I cannot imagine any
mainstream use cases for --force defaulting to matching; at least none
important enough to counterbalance the damage.

cheers,


m
--=20
=***@gmail.com
=***@laptop.org -- Software Architect - OLPC
=A0- ask interesting questions
=A0- don't get distracted with shiny stuff=A0 - working code first
=A0- http://wiki.laptop.org/go/User:Martinlanghoff

[Junio C Hamano]

--force should change behaviour, immediately, to "current" or even none
(forcing the user to name the remote and branch explicitly).

Any "immediately" change is never going to happen merely based on "I
cannot imagine in what use case it is useful".

As many people already said in the discussion before the RFD message that
is at the root of this thread, the name of the option --force alone
already signals it is something you use after thinking twice.

[Martin Langhoff]

As many people already said in the discussion before the RFD message =

that

is at the root of this thread, the name of the option --force alone
already signals it is something you use after thinking twice.

Definitely. You may think twice about the branch you' re planning to
force-update. "Do I really want to force-update <this>?". But it
doesn't mean you know and fully understand the "push default" rules of
git.

With "immediately" I mean "sooner than several releases away".

In any case, seems I missed the train and the discussion is closed;
I'll head back to my cave.

cheers,



m
--=20
=***@gmail.com
=***@laptop.org -- Software Architect - OLPC
=A0- ask interesting questions
=A0- don't get distracted with shiny stuff=A0 - working code first
=A0- http://wiki.laptop.org/go/User:Martinlanghoff

[Jakub Narebski]

Post by Martin Langhoff

Post by Junio C Hamano
If the conclusion of the discussion is that we will change the default,

I am in general agreement with the course of action outlined. There is
--force should change behaviour, immediately, to "current" or even
none (forcing the user to name the remote and branch explicitly).
The potential for messups with --force combined with "matching" and a
repo that allows it is considerable. And I cannot imagine any
mainstream use cases for --force defaulting to matching; at least none
important enough to counterbalance the damage.

Well, one can always use

git push <remote> +:

instead of

git push --force

for "matching" push... but I think you would have to provide name of
repository.

[Junio C Hamano]

By now it should be obvious that most people would prefer to see the
default behaviour for 'git push' to be something other than matching, even
if you did not read each and every "me too" message.

Actually, we've known it from the beginning. Otherwise, we wouldn't have
made noises about it in the first place ;-). It was not the primary
objective of the discussion thread to decide if we are going to switch
away from 'matching' by voting (waking up those who are sleeping, so that
they do not have to be surprised with "I didn't know that was happening!"
was).

The new default we are switching to is not about how many people prefer it
for their own use. It is about what default is the least confusing to the
new users. A default whose behaviour is easy to explain, easy to follow
and easy to understand is the goal. Once people understand what they want
and realize they fall into a minority, it is easy for them to configure
their push.default to something else, like 'matching'. And 'matching' was
a bad default for that purpose; it was the hardest to explain and
understand in the context of the workflows of many new people.

Many people said that they like 'upstream' solely based on their personal
preference, but a few people did justify their preference of 'upstream'
over 'current' based on their experience in teaching new people and
observing the sharp edges that hurt them. And they all sounded reasonable.

In order to show how the world after phase #2 of the transition [*1*]
would look like to developers, testers and early adopters, I am planning
merge Matthieu's patch mm/push-default-switch-warning topic [*2*] to
'next', together with Christopher's ct/advise-push-default topic [*3*];
hopefully these topics can be merged to 'master' soon after 1.7.10 final.

Thanks.

To people who helped spreading the initial RFD message: please do feel
free to distribute this message to the same channels, too.


[References]

*1* http://article.gmane.org/gmane.comp.version-control.git/193308

*2* https://github.com/gitster/git/commit/5293b54

*3* https://github.com/gitster/git/commit/f25950f

[Matthieu Moy]

Post by Junio C Hamano
In order to show how the world after phase #2 of the transition [*1*]
would look like to developers, testers and early adopters, I am planning
merge Matthieu's patch mm/push-default-switch-warning topic [*2*]

Great. There was a few nitpick about my version (s/1.8/2.0/, static
variable), but I can see that you have already fixed them.

It may make sense to create a branch like v2.0 in git.git to start
collecting "switch default" kind of patches, to be merged before 2.0 is
released. There were other points in the "1.8.0" discussion that may
still be valid (I'm not sure what the status of "make add -u full tree"
is for example):

http://permalink.gmane.org/gmane.comp.version-control.git/167149

(BTW, does your cristal ball say anything about the release date of
2.0?)

[Joey Hess]

I'd like to point out a use case for the current push behavior
that has probably not been considered. I've written several tools
that store data on subsidiary git branches.

One is pristine-tar, in which information necessarily to reconstruct
bit-identical tarballs containing the source in (say) master is stored
efficiently in the pristine-tar branch. Another is git-annex, in which
bookeeping information about the actual location of large files is
stored in the git-annex branch. These are not unlike git notes, other
than not being built into git. I'm not the only one doing this, other
examples I know of include several bug trackers (git-case, git-issues,
ticgit).

The current push behavior works well for these subsidiary branches.
But if users have to remember to manually push these branches, which they
do not otherwise manually interact with, they'll forget. I know this
will be confusing, because with current git, users have to be instructed
to push these branches *once*, to get the tracking set up.

I feel that this use of subsidiary branches expands the reach of git;
there are reasons that Fossil is pulling other ancillary data
(bugs, wiki, blog etc) into DVCS. But it makes the mistake, IMHO, of
bundling all that together into one peice of software. Git allows doing
the same things, but loosely coupled, so the best implementation of each
can win.

There might be some way to handle such subsidiary branches while
still changing the push default. If git prints a good enough warning
about other, unpushed matching branches, the user only has to do a
little more work to push them. If a hook was available that could
add branches to the set to be pushed, it could automate pushing
such branches. Or git could get a way to mark one branch as a subsidiary
branch of another, and automatically include subsidiaries in pushes.

[Junio C Hamano]

... I know this
will be confusing, because with current git, users have to be instructed
to push these branches *once*, to get the tracking set up.

Well, a tool like git-annex is not the primary audience to choose the
default behaviour for "git push" without configuration. Instead of
instructing "to push *once*", you can easily instruct to install
remote.$name.push that covers the primary and subsidiary branches.

Alternatively "git annex push" could drive the underlying "git push" in
whatever way it wishes. Notice a branch is being pushed, and then add its
subsidiary branch to the set of refs to be pushed (because it, not Git, is
the one who knows the correspondence between the primary branch and the
subsidiary branch).

[fREW Schmidt]

Post by Junio C Hamano
There is a proposal to change the default behaviour of 'git push' on the
Git mailing list. The goal of this message is to encourage you to discuss
it before it happens (or the change is aborted, depending on the outcome
of the discussion).

I personally much prefer the one where it pushes the current branch to
its tracking branch only. That leaves very little room for surprises
and mistakes (the one exception being git push after git checkout -b
new-branch origin/master.)

--
fREW Schmidt
http://blog.afoolishmanifesto.com

[H. Peter Anvin]

Post by fREW Schmidt

Post by Junio C Hamano
There is a proposal to change the default behaviour of 'git push' on the
Git mailing list. The goal of this message is to encourage you to discuss
it before it happens (or the change is aborted, depending on the outcome
of the discussion).

I personally much prefer the one where it pushes the current branch to
its tracking branch only. That leaves very little room for surprises
and mistakes (the one exception being git push after git checkout -b
new-branch origin/master.)

I would agree with this being the least surprising behavior. I believe
this is what push.default = upstream does.

-hpa

[Marcus D. Hanwell]

There is a proposal to change the default behaviour of 'git push' o=

n the

Git mailing list. The goal of this message is to encourage you to d=

iscuss

it before it happens (or the change is aborted, depending on the ou=

tcome

of the discussion).

I personally much prefer the one where it pushes the current branch =

to

its tracking branch only. =A0That leaves very little room for surpri=

ses

and mistakes (the one exception being git push after git checkout -b
new-branch origin/master.)

I would agree with this being the least surprising behavior. =A0I bel=

ieve

this is what push.default =3D upstream does.

I agree that the least surprising default is to push the current
branch to its tracking branch only. It always surprised me that other
branches tried to push too.

Marcus

[Sebastian Schuberth]

Post by fREW Schmidt
its tracking branch only. That leaves very little room for surprises
and mistakes (the one exception being git push after git checkout -b
new-branch origin/master.)

That's exactly why I'd prefer "current" instead of "upstream" as the
default behavior, as it even causes no surprises in the checkout -b
case, IMHO.

I believe the most common workflow for the large number of git users who
are no integrators / maintainers is to start a topic branch from master
and then work on that topic branch until it gets merged. In order to
test the topic branch on other platforms or make it available to others,
it's a common operation to push the topic branch to a branch of the same
name instead of the tracking branch. That's why I believe "current" is
both the setting that matches the workflow of most git users and is the
setting that really causes the least surprises (not least because it's
straight forward what the name of the pushed branch would be, as it's
the current branch's name; if you don't know the upstream branch's name
out of your head, you'd have to look it up to know).

[Peter Krefting]

At $dayjob, our setup instructions for Git do say that everyone setting up a
new machine shall run "git config --global push.default tracking". This is
what suits our workflow where people work on a topic branch, which they will
push to and pull from our central repository (each topic branch is owned by
a team of one or more developers). By using "tracking", they can just do a

git push

and not have to worry about other half-finished or local changes "pollute"
the One True Central Repository<tm>. We have found that this configuration
makes it easier to explain the workflow, especially since it more or less
does make "push" the opposite of "pull" (both of them just updating one
"real" branch on either side).

We also have cases where we work on different repositories, with different
codebases; we have an upstream codebase that is merged into one or more
downstream codebases, and sometimes we have branches that are used with more
than one codebase (pull branch A from upstream repo, merge with downstream
repo and work with it there). Or we work on cross-codebase maintainence
(transplant fix on branch A from codebase B to codebase C). We have
installed hooks on our repositories that try to make sure history does
not get pushed to the wrong repository -- as could sometimes happen if
you had a branch checked out locally from the another codebase and forgot
to configure your push.default.


I have also personally found that this is the setting that I do feel most
comfortable with in more or less every other context where I work with Git,
so I do think this would be a fairly useful default value.


I know the policy in Git is to not allow the remote repository dictate
anything about the configuration in the local repository, but as an
alternative to changing the "push.default" value, perhaps we should allow
setting some configuration option on the remote repository that blocks it
from being the target of a "push.default = matching" push?

[Jonathan Nieder]

Post by Peter Krefting
I know the policy in Git is to not allow the remote repository
dictate anything about the configuration in the local repository,
but as an alternative to changing the "push.default" value, perhaps
we should allow setting some configuration option on the remote
repository that blocks it from being the target of a "push.default =
matching" push?

If I work for your company and always keep all my local topic branches
in good order, I would expect to be permitted to use "push.default =
matching" to easily push them all at once after I have finished
preparing them, provided I have set up my local copy of git that way
explicitly, regardless of what the person setting up the
infrastructure thought.

What would I be missing?

Curious,
Jonathan

[Peter Krefting]

Post by Jonathan Nieder
What would I be missing?

If you can manage to do that and never mis-push, then, yes, that would be
fine. As soon as you have local branches checked out it starts getting
problematic; we also have different servers with different branch namespaces
that we push to, and making sure the wrong branch doesn't get pushed to the
wrong server can sometimes be difficult.

[Michael K. Johnson]

Thank you for the public requests for comment on changing "git push"
semantics. I don't have anything particularly new to say, so TL;DR
is: I think that changing the default value for push.default to
upstream would help advocate corporate Git adoption as potential
users experiment on their own, attracted by the benefits of "branchy"
development. I don't think that my own ability to advocate for Git
is affected by this decision, but wanted to share the observation.

I am encouraging corporate adoption of Git for primary source
code control, and I see two reasons for making relatively centralized
workflows easy.

It is easiest to advocate for this change when more developers are
convinced that the initial adoption process will be relatively easy;
that they can change from existing centralized version control
to Git without synchronized, protracted productivity loss due to
a steep learning curve. Don't get me wrong, they want to make
use of DVCS concepts, and they aren't interested in the change
without expecting benefits from the change, it's just that having a
centralized workflow available makes it easier to contemplate change.
The more developers involved, the harder it would be to try to
synchronize everyone's learning curve and the more value in a
centralized workflow being available.

As has been raised several times already, most corporations are most
comfortable with having one repository that is the official main
repository, a "primus inter pares" of repositories. At least in
my own context, for business continuity we want developers to push
topic branches to the official central repository. In practice, very
little truly disconnected development is done; the benefits of DVCS
in general and Git in particular lie mostly in the version graph, and
secondarily in the scalability derived from repository distribution.

The default setting of push.default=matching is confusing for new
users in practice, at least in centralized workflows. It has been
confusing in practice that they need to synchronize their master
in order to synchronize their topic branch, and in order to find
the solution they need to have some idea what solution they are
looking for -- and expect that there is a solution.

Finally, my reasoning for "upstream" instead of "current" is that
I have heard in practice that quite a few developers who are interested
in Git but not yet familiar with it have heard that branches can have
different names in different repositories, and they like the idea.
They might want to track "origin/bug1234567" in "mybug" that is
shorter and easier to remember... This is a minor point, in my
opinion.

[Kevin Ballard]

I would love to see the default changed to 'upstream'. I've wanted this ever
since the push.default=tracking value was introduced. When introducing new
users to git, one of the first things I always tell them is to run

git config --global push.default tracking

because it's far easier to explain how that behavior works than it is to
explain how the 'matching' behavior works, and it more closely aligns with
the way people (in my experience) typically use git.

-Kevin

Post by Junio C Hamano
There is a proposal to change the default behaviour of 'git push' on the
Git mailing list. The goal of this message is to encourage you to discuss
it before it happens (or the change is aborted, depending on the outcome
of the discussion).
In the current setting (i.e. push.default=matching), 'git push' without
argument will push all branches that exist locally and remotely with the
same name. This is usually appropriate when a developer pushes to his own
public repository, but may be confusing if not dangerous when using a
shared repository. The proposal is to change the default to 'upstream',
i.e. push only the current branch, and push it to the branch 'git pull'
would pull from. Another candidate is 'current'; this pushes only the
current branch to the remote branch of the same name.
For more details on the behavior of Git with these values, read the
documentation about 'push.default' in 'man git-config'
(http://schacon.github.com/git/git-config.html).
You may be negatively affected when such a change happens if you do not
see anything in the output from 'git config push.default' and if you rely
on the default that pushes all your matching branches. On the other hand,
you may want to see the default behaviour to change, especially if you are
using shared repositories. In either case, please join the discussion to
give us more data point and help us decide the future of Git. Also, if
you think your friends and colleagues will be affected by this change,
either positively or negatively, please tell them about this discussion.
http://thread.gmane.org/gmane.comp.version-control.git/192547/focus=192694
http://thread.gmane.org/gmane.comp.version-control.git/123350/focus=123541
http://thread.gmane.org/gmane.comp.version-control.git/166743
The list accepts messages from non-subscribers, and you do not have to ask
"please Cc me, I am not subscribed", as it's customary to Cc: posters when
replying on this list.
--
To unsubscribe from this list: send the line "unsubscribe git" in
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Antony Male]

This is my 2 cents from helping out on #git. I don't consider workflows
at all, only how to minimise confusion for new users when they're trying
to understand how git works.

We occasionally get users who are having trouble understanding why the
argument-less form of 'git pull' is failing, due to lack of tracking
configuration. We explain that the tracking config is git's way of
"connecting" local and remote branches, and how to use 'git push -u' and
'git branch --set-upstream' appropriately.

This is all well and good -- they've discovered that local and remote
branches are separate, that they aren't "magically" joined, that there's
a bit of configuration data which "connects" the two, and how to
manipulate it.

Users then assume that argument-less form of 'git push' uses the same
mechanism. To then discover that it (by default) uses a different way
of "connecting" local and remote branches is often confusing [1]. In
addition, it can't be manipulated in the same way as the tracking config
they learnt about before.

For this reason, I am in favour of push.default = upstream. Although it
requires knowledge about setting up tracking config (in the cases where
tracking config isn't set automatically), this knowledge has to be
gained anyway for the argument-less form of 'git pull' to work.


[1]: Indeed, a lot of users only find out about this difference when it
has bitten them in some way.

Thanks,
Antony

[Jakub Narebski]

Post by Antony Male
This is my 2 cents from helping out on #git. I don't consider
workflows at all, only how to minimise confusion for new users when
they're trying to understand how git works.
We occasionally get users who are having trouble understanding why the
argument-less form of 'git pull' is failing, due to lack of tracking
configuration. We explain that the tracking config is git's way of
"connecting" local and remote branches, and how to use 'git push -u'
and 'git branch --set-upstream' appropriately.
This is all well and good -- they've discovered that local and remote
branches are separate, that they aren't "magically" joined, that
there's a bit of configuration data which "connects" the two, and how
to manipulate it.
Users then assume that argument-less form of 'git push' uses the same
mechanism. To then discover that it (by default) uses a different way
of "connecting" local and remote branches is often confusing [1].

[...]

The "matching" behavior is intende for non-symmetrical situation of a
workflow where each user has its own separate public publishing
repository, but can pull from many repositories from other developers
(but never from one's own).

The situation is assymetrical (even more that "pull" and "push" for
single upstream repository, in a shared central repository case), so
configuration is assymetrical.

[Antony Male]

Post by Jakub Narebski
The "matching" behavior is intende for non-symmetrical situation of a
workflow where each user has its own separate public publishing
repository, but can pull from many repositories from other developers
(but never from one's own).
The situation is assymetrical (even more that "pull" and "push" for
single upstream repository, in a shared central repository case), so
configuration is assymetrical.

Sorry, I wasn't clear enough. I'm well aware of why 'matching' and
'current' exist, and the workflows for which they're suited.

My point is that these bite new users before they've got to the point of
developing workflows involving more than one remote. At that point,
they're not aware of the need for an asymmetric config, so they're not
expecting it to be the default.

To take another angle on it, I'd rather our new users said "Hey, there's
an awesome config option that makes git play nicely with asymmetric
workflows" than "Why on earth do pull and push interact with different
remote branches by default".

Thanks,
Antony

[Nathan Gray]

Post by Junio C Hamano
There is a proposal to change the default behaviour of 'git push' on the
Git mailing list. The goal of this message is to encourage you to discuss
it before it happens (or the change is aborted, depending on the outcome
of the discussion).
In the current setting (i.e. push.default=matching), 'git push' without
argument will push all branches that exist locally and remotely with the
same name. This is usually appropriate when a developer pushes to his own
public repository, but may be confusing if not dangerous when using a
shared repository. The proposal is to change the default to 'upstream',
i.e. push only the current branch, and push it to the branch 'git pull'
would pull from. Another candidate is 'current'; this pushes only the
current branch to the remote branch of the same name.

+1 for 'upstream'. "Push" should mirror "pull" by the principle of
least surprise.

Cheers,
-Nathan

[Ben Tebulin]

Post by Nathan Gray
+1 for 'upstream'. "Push" should mirror "pull" by the principle of
least surprise.

One more +1 for 'upstream'!

After setting up remotes for a branch, 'matching' is convenient, but
simply does not match the expectations of a newbie user.

[Ben Tebulin]

Post by Nathan Gray
+1 for 'upstream'. "Push" should mirror "pull" by the principle of
least surprise.

One more +1 for 'upstream'!

After setting up remotes for a branch, 'matching' is convenient, but
simply does not match the expectations of a newbie user.

[Ben Tebulin]

Post by Nathan Gray
+1 for 'upstream'. "Push" should mirror "pull" by the principle of
least surprise.

One more +1 for 'upstream'!

After setting up remotes for a branch, 'matching' is convenient, but
simply does not match the expectations of a newbie user.

[Ben Tebulin]

Post by Nathan Gray
+1 for 'upstream'. "Push" should mirror "pull" by the principle of
least surprise.

One more +1 for 'upstream'!

After setting up remotes for a branch, 'matching' is convenient, but
simply does not match the expectations of a newbie user.

[Filipe Fernandes]

Post by Junio C Hamano
There is a proposal to change the default behaviour of 'git push' on the
Git mailing list. The goal of this message is to encourage you to discuss
it before it happens (or the change is aborted, depending on the outcome
of the discussion).

+1 on changing the default to 'upstream'.

Having the same branch name on remote vs local repo shouldn't mean
they're necessarily the same branch (as what would be assumed with
'matching'). Also being explicit beforehand what remote branch the
local branch points to removes all doubt as it what 'git push' should
be doing for the owner of the local repo.

regards,
filipe