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

-- 
NULL && (void)