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

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:

    git@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.

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.

On 17/03/12 05:22, Junio C Hamano wrote:

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

Andrew Sayers <andrew-git@pileofstuff.org> writes:

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.

On Sun, Mar 18, 2012 at 19:50, Junio C Hamano <gitster@pobox.com> wrote:

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.

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

You are only arguing that what we do does not matter much to Distro users, and you already read that I agreed with that. It's really up to the distro 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 depend 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 later gives an updated default behaviour to help new people by avoiding a harder to understand error modes when used in the simplest workflow.

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

Hi Junio

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.

On 18/03/12 18:50, Junio C Hamano wrote:

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

Andrew Sayers <andrew-git@pileofstuff.org> writes:

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

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.

On 19 March 2012 22:43, Junio C Hamano <gitster@pobox.com> wrote:

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

demerphq <demerphq@gmail.com> writes:

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.

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.

On 03/19/2012 11:38 PM, Junio C Hamano wrote:

On 19/03/12 21:43, Junio C Hamano wrote:

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.

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

Andrew Sayers <andrew-git@pileofstuff.org> writes:

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.

On 19/03/12 22:59, Junio C Hamano wrote:

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 git@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

Andrew Sayers <andrew-git@pileofstuff.org> writes:

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...

On 20/03/12 23:09, Junio C Hamano wrote:

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

Andrew Sayers <andrew-git@pileofstuff.org> writes:

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.

On Sat, Mar 17, 2012 at 1:22 AM, Junio C Hamano <gitster@pobox.com> wrote:

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

Martin Langhoff <martin.langhoff@gmail.com> writes:

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.

On Tue, Mar 20, 2012 at 11:28 AM, Junio C Hamano <gitster@pobox.com> wrote:

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

Martin Langhoff <martin.langhoff@gmail.com> writes:

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.

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

Junio C Hamano <gitster@pobox.com> writes:

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?)

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.

Joey Hess <joey@kitenet.net> writes:

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).

On Sat, Mar 17, 2012 at 12:10 AM, Junio C Hamano <gitster@pobox.com> wrote:

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

On 03/17/2012 11:43 AM, fREW Schmidt wrote:

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

	-hpa

On Sun, Mar 18, 2012 at 12:02 AM, H. Peter Anvin <hpa@zytor.com> wrote:

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

On 17.03.2012 19:43, fREW Schmidt wrote:

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).

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?

Peter Krefting wrote:

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

Jonathan Nieder:

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.

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

On Mar 16, 2012, at 10:10 PM, Junio C Hamano wrote:

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

Antony Male <antony.male@gmail.com> writes:

[...]

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.

On 20/03/2012 12:04 pm, Jakub Narebski wrote:

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

On Fri, Mar 16, 2012 at 10:10 PM, Junio C Hamano <gitster@pobox.com> wrote:

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

Cheers, -Nathan

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.

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.

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.

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.

On Sat, Mar 17, 2012 at 1:10 AM, Junio C Hamano <gitster@pobox.com> wrote:

+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