Re: [RFC PATCH] push: start warning upcoming default change for push.default
- From
Matthieu Moy <matthieu.moy@grenoble-inp.fr>
- Date
- Mar 12, 2012, 08:47 UTC
- Message-ID
- <vpqzkbmcijl.fsf@bauges.imag.fr>
- In-Reply-To
- <1kgsxjq.jf2f02ib96ufM%lists@haller-berlin.de>
lists@haller-berlin.de (Stefan Haller) writes:
Show 13 quoted lines
> We're a closed-source company that uses git more or less like an > old-style, non-distributed VCS. > [...] > Also, it is very common for two or more developers to collaborate on a > topic branch, > [...] > Topics are never pushed to master; we have a "merge --no-ff" policy for > integration. > [...] > To sum it up, push.default=current is almost perfect for this kind of > workflow; except that you still need to configure your upstream branches > so that pull works, and status (and the shell prompt) displays the right > information.
What do you set "upstream" to in your flow?
I agree that push.default=current is the best setting for you. But I think 'tracking' would not be a silly choice either: if you collaborate on topic branches, it makes sense to set the upstream to the remote topic branch, so that "git pull" gets changes in the same branch (and you may need to "git pull origin master" to sync with the master branch from time to time). If you create a new branch with, say
git checkout -b new-branch
then the new branch has no upstream configured, and the next push without argument will fail, pointing you to the right command for your case:
$ git push
fatal: The current branch new-branch has no upstream branch.
To push the current branch and set the remote as upstream, use
git push --set-upstream origin new-branchIf you do a "git checkout new-branch" when "origin/new-branch" exists and "new-branch" doesn't, the upstream is configured to point to the remote "new-branch".
In both cases, the upstream is configured so that push.default=current do the same thing as push.default=upstream, so you don't really care which value is taken.
-- Matthieu Moy http://www-verimag.imag.fr/~moy/