[ 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.
> That suggests that we need to come up with a way to clean up
> these .keep files some other way than just being one of the
> command near the end. As to the mysterious "echo e <empty>"
> I will not have chance to look at it myself until later today
> (I'm at work now and it is not my git day today).
I hope you (or anyone else) will be able to have a look at this. My
shell programming skills are simply not up to it.
Nicolas
-
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