threads / discuss / 29998

2 cents regarding push.default change

Subject: 2 cents regarding push.default change

## tl;dr

One message between Mar 19, 2012 and Mar 19, 2012.

replies: 0people: 1as markdown or json

George King· Mar 19, 2012, 21:17 UTC · lore
Hello list,

I saw a post on hacker news soliciting feedback for the patch to default to push.default=upstream, I would like to relate my own experience using git at work. In short, I support the change.

One of the more embarrassing things I have done here was 'push --force' all branches to origin because of the current default, 'push.default=current'. The mistake would have been avoided with the proposed change. The scenario was as follows:

- Our git server has master and main dev branches, as well as a number
of 'private' branches. The distinction between public / shared
branches and private / personal branches is informal within my team
(which is perfectly reasonable I think).
- I rebased a private branch locally, and wanted to save my day's work
to the server. because of the rebase, when I ran 'git push' the server
rejected it.
- Because I was working in a private branch,  I thought it reasonable
to run 'git push --force'.
- Because I had not pulled recently, my history for branch 'master' was behind.
- The result was that in addition to forcing my private branch to the
new state (as desired), master was rewound to an old state,
effectively discarding the work of all my coworkers for the day.
- Luckily they still had their recent commits locally, so they were
able to push again and restore origin/master.

When this happened, my immediate reaction was 'git should not allow that!' I immediately did some reading, discovered 'push.default=upstream', and my team made that setting part our policy on the spot.

Aside from this particular problem, I also find the 'upstream' setting more convenient, because I do not have to bring all branches up to date before issuing 'git push'.

Hope that helps,
George King

← back to recent threads