Re: mergetool feature request - select remote or local

From: Junio C Hamano <gitster@pobox.com>
Date: May 14, 2008, 17:47 UTC
Message-ID: <7vzlqsok0y.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <200805140721.13719.xenoterracide@gmail.com>

Caleb Cushing <xenoterracide@gmail.com> writes:

Show 12 quoted lines

> 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

I never understood why people are using git and not ftp when they say the other side is always right, but I see this comes up every once in a while, so it would probably be a good thing to support.

Show 5 quoted lines

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

The above "(l)local" and "(m)anual" look inconsistent, and the wording should be more like "local, remote or merge".

> 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").

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.

 builtin-ls-files.c |   22 ++++++++++++++++++++++
 1 files changed, 22 insertions(+), 0 deletions(-)

diff --git a/builtin-ls-files.c b/builtin-ls-files.c
index dc7eab8..36b2875 100644
--- a/builtin-ls-files.c
+++ b/builtin-ls-files.c
@@ -181,6 +181,8 @@ static void show_ce_entry(const char *tag, struct cache_entry *ce)
 {
 	int len = prefix_len;
 	int offset = prefix_offset;
+	static const char *last_tag_shown;
+	static struct cache_entry *last_ce_shown;
 
 	if (len >= ce_namelen(ce))
 		die("git-ls-files: internal error - cache entry not superset of prefix");
@@ -206,7 +208,18 @@ static void show_ce_entry(const char *tag, struct cache_entry *ce)
 	}
 
 	if (!show_stage) {
+		/*
+		 * Even when not showing stage information, we will call this
+		 * function for each stage.  Omit duplicate output.
+		 */
+		if ((!tag ||
+		     (last_tag_shown && !strcmp(last_tag_shown, tag))) &&
+		    (last_ce_shown &&
+		     !strcmp(last_ce_shown->name, ce->name)))
+			return;
 		fputs(tag, stdout);
+		last_tag_shown = tag;
+		last_ce_shown = ce;
 	} else {
 		printf("%s%06o %s %d\t",
 		       tag,
@@ -509,6 +522,15 @@ int cmd_ls_files(int argc, const char **argv, const char *prefix)
 			show_unmerged = 1;
 			continue;
 		}
+		if (!strcmp(arg, "--no-stage")) {
+			/*
+			 * ... Not really.
+			 * Sometimes we would want a list of unmerged paths.
+			 */
+			show_stage = 0;
+			show_cached = 1;
+			continue;
+		}
 		if (!strcmp(arg, "-x") && i+1 < argc) {
 			exc_given = 1;
 			add_exclude(argv[++i], "", 0, &dir.exclude_list[EXC_CMDL]);