From: Brandon Casey <casey@xxxxxxxxxxxxxxx>
One of the first things filter-branch does is to create a temporary
directory. This directory is eventually removed by the script during
normal operation, but is not removed if the script encounters an error.
Set a trap to remove it when the script terminates for any reason.
Signed-off-by: Brandon Casey <casey@xxxxxxxxxxxxxxx>
---
Even though this directory may be useful for debugging when you encounter
a problem, I wonder if the normal "error" will be _user_ error. In which
case the user will adjust the command line parameters and try to rerun.
Currently the user would then receive the message
"$tempdir already exists, please remove it"
Then, rm -rf the tempdir, then rerun.
Is this necessary? Maybe anyone with the know-how to debug would also have the
know-how to comment out the 'trap' in the script (or direct someone asking for
help on the mailing list to do so).
If we really want to leave this temporary directory around on failure, maybe
we can at least remove it for some simple errors like:
line 198: die "Namespace $orig_namespace not empty"
line 217: die "Which ref do you want to rewrite?"
etc.
by moving the 'trap - 0' higher up.
-brandon
git-filter-branch.sh | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index ebf05ca..75970a9 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -189,6 +189,9 @@ cd "$tempdir/t" &&
workdir="$(pwd)" ||
die ""
+# Remove tempdir on exit
+trap 'cd ../..; rm -rf "$tempdir"' 0
+
# Make sure refs/original is empty
git for-each-ref > "$tempdir"/backup-refs
while read sha1 type name
@@ -406,6 +409,8 @@ fi
cd ../..
rm -rf "$tempdir"
+trap - 0
+
unset GIT_DIR GIT_WORK_TREE GIT_INDEX_FILE
test -z "$ORIG_GIT_DIR" || GIT_DIR="$ORIG_GIT_DIR" && export GIT_DIR
test -z "$ORIG_GIT_WORK_TREE" || GIT_WORK_TREE="$ORIG_GIT_WORK_TREE" &&
--
1.5.4.rc5.2.g9a6d-dirty
-
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
