Re: [PATCH] pull: fix 'git pull --all' when current branch is tracking remote that is not last in the list of remotes

Michael Lukashov [off-list ref] writes:

On Wed, Feb 24, 2010 at 2:02 AM, Junio C Hamano [off-list ref] wrote:

quoted

Michael Lukashov [off-list ref] writes:

quoted

diff --git a/git-pull.sh b/git-pull.sh
index 38331a8..fcde096 100755
--- a/git-pull.sh
+++ b/git-pull.sh

@@ -214,7 +214,11 @@ test true = "$rebase" && {

      done
 }
 orig_head=$(git rev-parse -q --verify HEAD)
-git fetch $verbosity --update-head-ok "$@" || exit 1
+if test -e "$GIT_DIR"/FETCH_HEAD
+then
+     rm "$GIT_DIR"/FETCH_HEAD 2>/dev/null
+fi

When is it sane to ignore an error from this "rm", especially after you
made sure that it exists?

The file "$GIT_DIR"/FETCH_HEAD is rewritten
in subsequent call to 'git fetch', thus it is safe to ignore all errors.

You are not answering my question.

You found out that the thing exists, and you want to overwrite it later.
You _need_ that file to either not exist, or at least be empty, because
you will be _appending_ to it, unlike the earlier code.

Now, you expected you would be able to remove it, and that is why you
called "rm".  Suppose that removal has failed for some reason.  The file
stays.  It is not emptied, either.

Why is it sane to ignore that error and let fetch --append to run, as if
it is starting from either non-existing file or an empty one?  You already
diagnosed that the file is in some _funny_ state.  It is not sensible to
continue further at that point, knowing that there is something wrong.

If the new code you introduced were

	rm -f "$GIT_DIR/FETCH_HEAD" || exit

then I would understand it.  But your patch doesn't make sense to me;
neither your "thus it is safe".