lists@xxxxxxxxxxxxxxxx (Stefan Haller) writes:
> 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-branch
If 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/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html