Satish Balay <[email protected]> writes: > But spliting up the merge as 'merge sf-sfbasics to barry/saws' and then > 'merge barry/saws to next' should be avoided.
It depends on what kind of conflicts arise. It's easier and topologically-cleaner history to just resolve conflicts in the eventual merge (to 'next'/'master'), but if that is untenable, especially if it requires functional changes in your branch (as opposed to syntactic), then merging in their branch is sensible. > BTW: in the normal workflow - a similar merge would be needed when > 'barry/saws' gets merged to 'master' - but I think form what Jed said > - git tracks this merge resolution in next - and reuses that for > future merges [aka merge into master] - so that step should be > seamless? Git has a mechanism called REuse REcorded REsolution (rerere). It is off by default, but you can turn it on globally with git config --global rerere.enabled true This is a set-and-forget option, and using it involves no special commands. When you commit a merge, the conflicted and resolved state is cached privately. If you later try to merge and get the same conflicts (possibly going to different branches), Git will auto-resolve using the recorded resolution. It still marks the files as dirty so you have to "approve" the resolution (git add). It's good to build and run relevant tests if there is any doubt that the resolution is correct, but that's the same as any merge. https://www.kernel.org/pub/software/scm/git/docs/git-rerere.html http://gitster.livejournal.com/41795.html http://stackoverflow.com/questions/3072155/git-workflow-throwaway-merges-and-git-rerere-whats-the-point
pgpafrPPE0AMw.pgp
Description: PGP signature
