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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

> 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@xxxxxxxxx>
> > ---
> 
> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]