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.
> 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
> 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.
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