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

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

From
RDRogan Dawes <rogan@dawes.za.net>
Date
Jan 7, 2008, 07:37 UTC
Message-ID
<4781D6C2.9060305@dawes.za.net>
In-Reply-To
<7v3atb5g5o.fsf@gitster.siamese.dyndns.org>
Signed-off-by: Rogan Dawes <rogan@dawes.za.net>
---
Junio C Hamano wrote:
Show 26 quoted lines
> Rogan Dawes <rogan@dawes.za.net> writes:
> 
>>>> 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'.
Yes, you are right. Maybe setting IFS to the empty string is better?

$ printf " ann 1\n ann 2\n" | while IFS="" read i j k ; do echo "<$i> <$j> <$k>"; done < ann 1> <> <> < ann 2> <> <> $

Admittedly, there are still problems with my version, as you say, backslashes and newlines will not be handled correctly. My Perl-fu is weak, however, and my revised solution (IFS="") works for me :-)

Rogan

P.S. Quoting "$files" stops the spaces from being eaten in the preceding echo line.

diff --git a/git-mergetool.sh b/git-mergetool.sh
index 2f31fa2..facfbc8 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -393,8 +393,8 @@ if test $# -eq 0 ; 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
+       echo Merging the files: "$files"
+       git ls-files -u | sed -e 's/^[^ ]*      //' | sort -u | while 
IFS="" read i
         do
                 printf "\n"
                 merge_file "$i" < /dev/tty > /dev/tty


diff --git a/git-mergetool.sh b/git-mergetool.sh
index 2f31fa2..facfbc8 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -393,8 +393,8 @@ if test $# -eq 0 ; 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
+	echo Merging the files: "$files"
+	git ls-files -u | sed -e 's/^[^	]*	//' | sort -u | while IFS="" read i
 	do
 		printf "\n"
 		merge_file "$i" < /dev/tty > /dev/tty
Previous: Junio C HamanoNext: Junio C Hamano
Message 5 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.