Re: [PATCH 3/3] Add -k/--keep-going option to mergetool

From: Charles Bailey <charles@hashpling.org>
Date: Nov 24, 2008, 21:59 UTC
Message-ID: <20081124215927.GA5293@hashpling.org>
In-Reply-To: <7vy6zl7drn.fsf@gitster.siamese.dyndns.org>

On Fri, Nov 14, 2008 at 09:35:08PM -0800, Junio C Hamano wrote:

Show 15 quoted lines

> Charles Bailey <charles@hashpling.org> 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?
>

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.