Re: [BUG] git-fetch -k is broken

Nicolas Pitre [off-list ref] writes:

[ resuming an old thread ]

On Thu, 30 Nov 2006, Junio C Hamano wrote:

quoted

Nicolas Pitre [off-list ref] writes:

quoted

Actually, the .keep file is simply not removed as it should.

But first it appears that commit f64d7fd2 added an && on line 431 of 
git-fetch.sh and that cannot be right.  There is simply no condition for 
not removing the lock file.  It must be removed regardless if the 
previous command succeeded or not.  Junio?

True, but your "echo" patch breaks things even more -- when fast
forward check fails, it should cause the entire command should
report that with the exit status.

This "echo" patch was not a fix.  It was only an expeditive hack to 
demonstrate the problem.  Please consider this stripped down test case 
instead:

-------- >8
#!/bin/sh
#

LF='
'
IFS="$LF"

    ( : subshell because we muck with IFS
      pack_lockfile=
      IFS=" 	$LF"
      (
	  echo "keep	123456789abcdef0123456789abcdef012345678"
      ) |
      while read sha1 remote_name
      do
	  case "$sha1" in
	  # special line coming from index-pack with the pack name
	  keep)
		  pack_lockfile="$GIT_OBJECT_DIRECTORY/pack/pack-$remote_name.keep"
		  echo "pack_lockfile set to $pack_lockfile"
		  continue ;;
	  esac
      done &&
      if [ "$pack_lockfile" ]; then echo "rm -f $pack_lockfile"; fi
      echo "pack_lockfile=$pack_lockfile"
    )
-------- >8

The output I get is:

pack_lockfile set to /pack/pack-123456789abcdef0123456789abcdef012345678.keep
pack_lockfile=

In other words the line with the echo "rm -f ..." never shows up and I 
don't know why.

The whole while loop is run in a subshell and the process runs
the last echo "pack_lockfile=$pack_lockfile" is a process
different from the one that did the other echo in the while
loop.