Charles Bailey [off-list ref] writes:
This option stops git mergetool from aborting at the first failed merge.
This allows some additional use patterns. Merge conflicts can now be
previewed one at time and merges can also be skipped so that they can be
performed in a later pass.
Hmm, with this command line:
-'git mergetool' [--tool=<tool>] [-y|--no-prompt|--prompt] [<file>]...
I wonder why this even needs to be an option. If you do not want to
resolve all of them, you can limit the amount of work you would do by
giving list of paths to work on, can't you?
On Fri, Nov 14, 2008 at 09:35:08PM -0800, Junio C Hamano wrote:
quoted
-'git mergetool' [--tool=<tool>] [-y|--no-prompt|--prompt] [<file>]...
I wonder why this even needs to be an option. If you do not want to
resolve all of them, you can limit the amount of work you would do by
giving list of paths to work on, can't you?
I don't know about Charles, but I often don't know that I don't want to
merge a file using the graphical tool until I see it in the graphical
tool. IOW, I start trying to merge it there and realize the conflict is
such that I am better off doing it in my editor with conflict markers.
-Peff
On Fri, Nov 14, 2008 at 09:35:08PM -0800, Junio C Hamano wrote:
Charles Bailey [off-list ref] writes:
quoted
This option stops git mergetool from aborting at the first failed merge.
This allows some additional use patterns. Merge conflicts can now be
previewed one at time and merges can also be skipped so that they can be
performed in a later pass.
Hmm, with this command line:
quoted
-'git mergetool' [--tool=<tool>] [-y|--no-prompt|--prompt] [<file>]...
I wonder why this even needs to be an option. If you do not want to
resolve all of them, you can limit the amount of work you would do by
giving list of paths to work on, can't you?
I have to say that since having this in my tree I've benefitted hugely
from using a visual diff tool as a merge preview tool. I'm working on
a (far from ideal) project where two branches are diverging fast due
to differing goals, yet there is a need for an end product with the
functionality of both branches in it.
This means that I often end up needing to do frequent large merges.
Often it is not until I have the merge open in front of me that it
becomes obvious that while a particular file needs merging, the best
merge strategy will only be obvious after resolving the conflicts in
other parts of the system.
Often several hours of work will just be four or five invocations of
git mergetool until something which compiles emerges. Stopping to view
what the next unmerged file path is and pasting it into another
mergetool command line seems like an unnecessary distraction.
Charles.