From 83bd7437ca6acbee0db431fc8ec7cf823d9459ec Mon Sep 17 00:00:00 2001 From: Jeff King Date: Tue, 27 Aug 2013 16:41:12 -0400 Subject: write_index: optionally allow broken null sha1s Commit 4337b58 (do not write null sha1s to on-disk index, 2012-07-28) added a safety check preventing git from writing null sha1s into the index. The intent was to catch errors in other parts of the code that might let such an entry slip into the index (or worse, a tree). Some existing repositories may have invalid trees that contain null sha1s already, though. Until 4337b58, a common way to clean this up would be to use git-filter-branch's index-filter to repair such broken entries. That now fails when filter-branch tries to write out the index. Introduce a GIT_ALLOW_NULL_SHA1 environment variable to relax this check and make it easier to recover from such a history. It is tempting to not involve filter-branch in this commit at all, and instead require the user to manually invoke GIT_ALLOW_NULL_SHA1=1 git filter-branch ... to perform an index-filter on a history with trees with null sha1s. That would be slightly safer, but requires some specialized knowledge from the user. So let's set the GIT_ALLOW_NULL_SHA1 variable automatically when checking out the to-be-filtered trees. Advice on using filter-branch to remove such entries already exists on places like stackoverflow, and this patch makes it Just Work again on recent versions of git. Further commands that touch the index will still notice and fail, unless they actually remove the broken entries. A filter-branch whose filters do not touch the index at all will not error out (since we complain of the null sha1 only on writing, not when making a tree out of the index), but this is acceptable, as we still print a loud warning, so the problem is unlikely to go unnoticed. Signed-off-by: Jeff King Reviewed-by: Jonathan Nieder Signed-off-by: Junio C Hamano --- git-filter-branch.sh | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) (limited to 'git-filter-branch.sh') diff --git a/git-filter-branch.sh b/git-filter-branch.sh index ac2a005fdb..98e8fe43d2 100755 --- a/git-filter-branch.sh +++ b/git-filter-branch.sh @@ -283,11 +283,12 @@ while read commit parents; do case "$filter_subdir" in "") - git read-tree -i -m $commit + GIT_ALLOW_NULL_SHA1=1 git read-tree -i -m $commit ;; *) # The commit may not have the subdirectory at all - err=$(git read-tree -i -m $commit:"$filter_subdir" 2>&1) || { + err=$(GIT_ALLOW_NULL_SHA1=1 \ + git read-tree -i -m $commit:"$filter_subdir" 2>&1) || { if ! git rev-parse -q --verify $commit:"$filter_subdir" then rm -f "$GIT_INDEX_FILE" -- cgit v1.2.1 From 3361a548dbedde96d75bd4134e9ab9e6d82774dd Mon Sep 17 00:00:00 2001 From: Lee Carver Date: Tue, 10 Sep 2013 22:55:35 +0000 Subject: Allow git-filter-branch to process large repositories with lots of branches. A recommended way to move trees between repositories is to use git-filter-branch to revise the history for a single tree: However, this can lead to "argument list too long" errors when the original repository has many retained branches (>6k) /usr/local/git/libexec/git-core/git-filter-branch: line 270: /usr/local/git/libexec/git-core/git: Argument list too long Could not get the commits Saving the output from rev-parse and feeding it into rev-list from its standard input avoids this problem, since the rev-parse output is not processed as a command line argument. Signed-off-by: Lee Carver Signed-off-by: Junio C Hamano --- git-filter-branch.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'git-filter-branch.sh') diff --git a/git-filter-branch.sh b/git-filter-branch.sh index ac2a005fdb..ca3d53919a 100755 --- a/git-filter-branch.sh +++ b/git-filter-branch.sh @@ -255,7 +255,7 @@ else remap_to_ancestor=t fi -rev_args=$(git rev-parse --revs-only "$@") +git rev-parse --revs-only "$@" >../parse case "$filter_subdir" in "") @@ -268,7 +268,7 @@ case "$filter_subdir" in esac git rev-list --reverse --topo-order --default HEAD \ - --parents --simplify-merges $rev_args "$@" > ../revs || + --parents --simplify-merges --stdin "$@" <../parse >../revs || die "Could not get the commits" commits=$(wc -l <../revs | tr -d " ") -- cgit v1.2.1