Re: [PATCH/RFC 04/20] rebase: remove unused rebase state 'prev_head'

From: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Date: Nov 26, 2010, 18:45 UTC
Message-ID: <alpine.DEB.1.10.1011261919540.17721@debian>
In-Reply-To: <4CEF67AB.6050700@drmicha.warpmail.net>

On Fri, 26 Nov 2010, Michael J Gruber wrote:

Show 9 quoted lines

> Martin von Zweigbergk venit, vidit, dixit 25.11.2010 20:57:
> > The rebase state 'prev_head' is not used. Remove it.
> > 
> > Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
> > ---
> 
> The actual value of prev_head was never used. But the check for its
> non-nullness made sure that git-rev-parse HEAD^0 succeeded when
> $merge_dir was created. Have you made sure that we don't need that check?

In continue_merge, the value written to prev_head is the output from `git rev-parse HEAD^0`. The value written to prev_head when the rebase is initiated seems to be `git rev-parse -q --verify` for some reference. In the latter case, the rebase is aborted if the exit code from rev-parse is non-zero. The prev_head file is only deleted when the whole $merge_dir is deleted.

Unless I'm mistaken, the above taken together seems to mean that $prev_head can only be empty if the output of rev-parse is empty. I'm still way to unfamiliar with the Git C code to be able to figure out if and when that may happen, but I'm sure you guys can help. The most likely candidate I could think of was an orphan branch (same thing as an unborn branch?), but even in that case was the output non-empty (`git rev-parse HEAD^0` simply resulted in 'HEAD^0').

Do you see any case where we do need the check?

/Martin