git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] Allow git-mergetool to handle paths with a leading space

From
Junio C Hamano <gitster@pobox.com>
Date
Jan 6, 2008, 11:48 UTC
Message-ID
<7v3atb5g5o.fsf@gitster.siamese.dyndns.org>
In-Reply-To
<4780B2BD.6020109@dawes.za.net>
Rogan Dawes <rogan@dawes.za.net> writes:
Show 9 quoted lines
>>> I am working on a project which has the root directory constructed
>>> with a leading space. i.e. ./ dir/. "read" skips the leading space
>>> char, and ends up with an incorrect filename, which can then not be
>>> found. Setting IFS=\n solves this problem.
>>
>> Does the project have a file that has letter 'n' (en) in its name?
>> Have you tested your patch while having a conflict in that file?
>
> Yes, it works correctly.
I am curious and puzzled...
        $ echo 'ann1' | (IFS=\n read i; echo "<$i>")
        <ann1>
        $ echo 'ann1' | (IFS=\n read i j; echo "<$i>")
	<a>
        $ echo 'n1' | (IFS=\n read i j; echo "<$i>")
	<>

Ok, "\n" is a funny way to say IFS does not matter as long as it is set to a non whitespace letter.

It is VERY misleading as it looks as if the issue is fixed by setting IFS to a single LF alone (excluding SP and HT from the usual set), but that is not the patch is doing. It is setting it to a single 'n'.

I think you still will lose backslash by using read, but I guess you would not care about that too much.

If you really cared, you would do something like this, but you would also need similar surgery in merge_file function itself that parses text form of ls-files output that tries to verify and extract paths, which I did not bother to touch in this demonstration patch.

 git-mergetool.sh |   33 ++++++++++++++++++++++-----------
 1 files changed, 22 insertions(+), 11 deletions(-)
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 2f31fa2..b7c5098 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -388,17 +388,28 @@ fi
 
 
 if test $# -eq 0 ; then
-	files=`git ls-files -u | sed -e 's/^[^	]*	//' | sort -u`
-	if test -z "$files" ; then
-		echo "No files need merging"
-		exit 0
-	fi
-	echo Merging the files: $files
-	git ls-files -u | sed -e 's/^[^	]*	//' | sort -u | while read i
-	do
-		printf "\n"
-		merge_file "$i" < /dev/tty > /dev/tty
-	done
+	doit=$(perl -e '
+		$/ = "\0";
+		my (%seen, @file);
+		my $ls_files;
+		open($ls_files, "-|", qw(git ls-files -u -z));
+		while (<$ls_files>) {
+			chomp;
+			s/^[^	]*	//;
+			$seen{$_}++;
+		}
+		@file = sort keys %seen;
+		if (!@file) {
+			print "echo No files need merging\n";
+			print "exit 0\n";
+		}
+		for (@file) {
+			s|'\''|'\''\\'\'''\''|g;
+			print "echo\n";
+			print "merge_file '\''$_'\'' </dev/tty >/dev/tty\n";
+		}
+	')
+	eval "$doit"
 else
 	while test $# -gt 0; do
 		printf "\n"
Previous: Rogan DawesNext: Rogan Dawes
Message 4 of 7 in “Allow git-mergetool to handle paths with a leading space”
  1. Allow git-mergetool to handle paths with a leading spaceRogan Dawes, Jan 6, 2008
  2. Junio C HamanoJan 6, 2008
  3. Rogan DawesJan 6, 2008
  4. Junio C HamanoJan 6, 2008
  5. Allow git-mergetool to handle paths with a leading spaceRogan Dawes, Jan 7, 2008
  6. Junio C HamanoJan 7, 2008
  7. Theodore TsoJan 8, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.