Charles Bailey <char...@hashpling.org> writes: > I worked on this after discovering that --prune-empty often left some > apparently empty commits that I was wasn't expecting it to leave and > that running filter-branch --prune-empty in a loop would often do many > passes where it was still pruning empty former merge commits.
Good find. > > The test is a simple example of such a case. A non-ff merge of a commit > that only changes a file that is to be pruned gets squashed into an > empty non-merge commit that should be pruned. > > git-filter-branch.sh | 8 +++++++- > t/t7003-filter-branch.sh | 11 +++++++++++ > 2 files changed, 18 insertions(+), 1 deletion(-) > > diff --git a/git-filter-branch.sh b/git-filter-branch.sh > index 86d6994..c5b82a8 100755 > --- a/git-filter-branch.sh > +++ b/git-filter-branch.sh > @@ -332,7 +332,13 @@ while read commit parents; do > parentstr= > for parent in $parents; do > for reparent in $(map "$parent"); do > - parentstr="$parentstr -p $reparent" > + case "$parentstr" in > + *" -p $reparent"*) > + ;; > + *) > + parentstr="$parentstr -p $reparent" > + ;; > + esac The case arms seem to be indented one level too deep; I'll fix it up locally when queuing, so no need to resend. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
