Nicolas Pitre <nico@xxxxxxx> writes: > [ resuming an old thread ] > > On Thu, 30 Nov 2006, Junio C Hamano wrote: > >> Nicolas Pitre <nico@xxxxxxx> writes: >> >> > 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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html