On 9 Mar 2012, Darrell Anderson spake thusly:
Pushing never does a merge of any kind. You can only push on top of a remote branch containing content you haven't pulled if you do a push -f, and that *deletes* the content you haven't pulled (hence the need for a -f 'force' argument).
What then is the correct way to push patches? Is this correct?
cd [module] git pull merge patches to module git commit -a git push
That's unpleasant to use: if that merge fails, you have no choice but to resolve the conflicts yourself, and you can't tell what sort of mess the system might make doing the working-tree merge. That's the CVS approach, where all pulls are fraught with fear because you don't know what might get dropped on top of your work, but you *do* know you'll have to clean up the mess before you do anything else.
Generally,
git branch working-branch write code commit -a write code commit -a git checkout master git pull git merge working-branch git push git branch -d working-branch # if you're done with this change
is the recommended git workflow for nontrivial changes. This leads to a tree looking like
A -- B -- C -- D -- E -- [merge] \ / --- a -- b -- c -------- (this was 'working-branch')
(where a, b, and c are commits you wrote, and B, C, D, and E are commits written upstream).
This lets you work on multiple changes in parallel, insulated from changes to upstream until *you* decide you want to adapt to them.
But, if you don't want to use a working branch, you can just say
write code commit -a write code commit -a git checkout master git pull # resolve conflicts git push
which has the effect of producing the same shape of tree without needing any sort of branch.
You can even say
git branch working-branch write code commit -a write code commit -a git checkout master git pull git checkout working-branch # more write/commit, more pulls from master # hmm, it's been a while, I've pulled from master several times, I want # to make this branch depend on whatever is master *now* git rebase master # now 'working-branch' is based on the tip of 'master' again, just as # if you branched from master one second ago and then did all your work # with the aid of a time machine. Test it, and then... git checkout master git merge working-branch git push
and now you'll find that there is no merge commit at all: everything is linear again, with the caveat that if there are any conflicts in *any* of your intervening while 'git rebase' is running, you have to fix them up one by one, with 'git rebase --continue' in between. (It warns you if you have to do this, and you can give up with 'git rebase --abort' and undo the whole thing.)
(In recent versions of git, 'git pull --rebase' will give you this workflow whenever you pull, if you don't want to use a branch.)