On Mon, Dec 01, 2008 at 09:38:07PM -0500, Caleb Cushing wrote:
> conflict: when auto-merging isn't merging the way you want it too, but
> you still want to see the diffs and handle them by hand. no commit
> won't do this, it just doesn't commit. I've had 2 situations now where
> git's fast-forward has overwritten changes in a branch I didn't want
> it to, it would have been better if I could handle them by hand
> without having to have 1 terminal open to the diff and the other open
> to the editor to fix it. and yes git was right by it's perspective,
> but the code it created was wrong by what I wanted and needed. I'm not
> really sure what more of a use case is needed for this.
It's not clear to me exactly what you want. Let's say I have a file
'foo' with changes from my merged branches in two different spots.
For example:
merge base branch A branch B
1 2 1
2 3 2
3 4 3
4 5 4
5
Did you want conflict markers in the resulting file? If so, what should
the conflict markers look like, since there isn't actually a conflict?
Alternatively, you could have git leave the file in an unmerged state,
and then access the base, ours, and theirs version from the index (or
even use git mergetool). Then you would get your desired versions into
the merging tool of your choice.
Of course, you could also just use a custom merge driver to accomplish
the same thing:
git config merge.xxdiff.driver 'xxdiff %A %O %B'
echo '* merge=xxdiff' >.gitattributes
git merge your-branch
and of course you can specify whatever subset of files you want to
actually do this for instead of '*'.
-Peff
--
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
