10 Mar
2012
10 Mar
'12
3:40 a.m.
On 9 Mar 2012, Darrell Anderson spake thusly:
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)
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