Re: [PATCH] rebase -p: seed first commit in case it's before the merge bases.

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jan 17, 2009, 23:51 UTC
Message-ID: <alpine.DEB.1.00.0901180041540.3586@pacific.mpi-cbg.de>
In-Reply-To: <a524993b13ee586cf0e8fbd3b6459ccd6767c6d8.1232233454.git.stephen@exigencecorp.com>

Hi,

On Sat, 17 Jan 2009, Stephen Haberman wrote:

Show 16 quoted lines

> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> index c8b0861..e800e07 100755
> --- a/git-rebase--interactive.sh
> +++ b/git-rebase--interactive.sh
> @@ -604,11 +604,18 @@ first and then run 'git rebase --continue' again."
>  				echo $ONTO > "$REWRITTEN"/$c ||
>  					die "Could not init rewritten commits"
>  			done
> +			# Along with the merge bases, look at the first commit's
> +			# parent (which may be before the merge base) and mark it
> +			# as rewritten to ONTO
> +			FIRST="$(git rev-list --reverse --first-parent $UPSTREAM..$HEAD | head -n 1)"
> +			for p in $(git rev-list --parents -1 $FIRST | cut -d' ' -f2)
> +			do
> +				echo $ONTO > "$REWRITTEN/$p"
> +			done

AFAICT this is wrong.  You have no guarantee whatsoever that the output of

	$ git rev-list --reverse --first-parent $UPSTREAM..$HEAD | head -n 1

has any parents at all. Take for example a coolest-merge-ever, i.e. a merge of an independent project.

Instead, what you _actually_ are looking for are the boundary objects of $UPSTREAM..$HEAD, which would be easy to get at.

However, I have a strong feeling that just piling onto the current code will not fix the underlying issues.

Ciao, Dscho