mergetool feature request - select remote or local

> sometimes when merge-ing fast forward doesn't work. but you know what the 
> resolution you want is.
>
> example (current behavior)
> Normal merge conflict for 'css/main.css':
>   {local}: modified
>   {remote}: modified
> Hit return to start merge resolution tool (vimdiff):
>
> but I don't want to. I know the remote updates are right. I could do a git 
> checkout remotebranch filename but when you have 20 files that need updating 
> this is annoying

> my suggestion is this
> Normal merge conflict for 'css/main.css':
>   {local}: modified
>   {remote}: modified
> Use (l)local or (r)remote or (m)anual? 

> This makes me wonder if you are better off not using mergetool in such a
> situation.  Instead, perhaps
> 
> 	$ git ls-files -u --no-stage | xargs git checkout MERGE_HEAD
> 
> might be a better option?  The attached is a completely untested
> weather-baloon patch.
> 
> If this turns out to be a better approach, perhaps we would further want
> to tweak things to make:
> 
> 	$ git checkout --unmerged MERGE_HEAD [--] [<pathspec>...]
> 
> to work (if you want "local", you would use "HEAD" instead of
> "MERGE_HEAD").

> On Wed, 14 May 2008, Junio C Hamano wrote:
> ...
>> If this turns out to be a better approach, perhaps we would further want
>> to tweak things to make:
>> 
>> 	$ git checkout --unmerged MERGE_HEAD [--] [<pathspec>...]
>> 
>> to work (if you want "local", you would use "HEAD" instead of
>> "MERGE_HEAD").
>
> This is "for all (or some, by pathspecs) files currently unmerged in the 
> index, resolve them to the version in MERGE_HEAD", right?

>> I would have done so here if "git checkout" were still a scripted version,
>> but now it is in C, it would take significantly more effort than it is
>> worth just to raise a weatherbaloon.
>
> Like this (also untested)? (This is missing defaulting to a pathspec of 
> '.' if --unmerged is used without any pathspecs)

> diff --git a/builtin-checkout.c b/builtin-checkout.c
> index 10ec137..0bae1d4 100644
> --- a/builtin-checkout.c
> +++ b/builtin-checkout.c
> @@ -42,6 +42,8 @@ static int post_checkout_hook(struct commit *old, struct commit *new,
>  	return run_command(&proc);
>  }
>  
> +static int unmerged;
> +
>  static int update_some(const unsigned char *sha1, const char *base, int baselen,
>  		       const char *pathname, unsigned mode, int stage)
>  {
> @@ -59,6 +61,13 @@ static int update_some(const unsigned char *sha1, const char *base, int baselen,
>  	hashcpy(ce->sha1, sha1);
>  	memcpy(ce->name, base, baselen);
>  	memcpy(ce->name + baselen, pathname, len - baselen);
> +	if (unmerged) {
> +		int pos = cache_name_pos(ce->name, len);
> +		if (!(pos && pos < active_nr && ce_same_name(active_cache[pos], active_cache[pos + 1]))) {
> +			free(ce);
> +			return 0;
> +		}
> +	}
>  	ce->ce_flags = create_ce_flags(len, 0);
>  	ce->ce_mode = create_ce_mode(mode);
>  	add_cache_entry(ce, ADD_CACHE_OK_TO_ADD | ADD_CACHE_OK_TO_REPLACE);
> @@ -508,6 +517,7 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
>  			BRANCH_TRACK_EXPLICIT),
>  		OPT_BOOLEAN('f', NULL, &opts.force, "force"),
>  		OPT_BOOLEAN('m', NULL, &opts.merge, "merge"),
> +		OPT_BOOLEAN( 0 , "unmerged", &unmerged, "check out unmerged paths"),
>  		OPT_END(),
>  	};
>  

> > also in the event of having 20 files with this issue it would be nice to
> > have an option after first starting mergetool for remote all or local
> > all.
>
> This makes me wonder if you are better off not using mergetool in such a
> situation.  Instead, perhaps
>
>         $ git ls-files -u --no-stage | xargs git checkout MERGE_HEAD

> might be a better option?  The attached is a completely untested
> weather-baloon patch.
>
> If this turns out to be a better approach, perhaps we would further want
> to tweak things to make:
>
>         $ git checkout --unmerged MERGE_HEAD [--] [<pathspec>...]
>
> to work (if you want "local", you would use "HEAD" instead of
> "MERGE_HEAD").