Re: [PATCH 6/6] am --abort: keep unrelated commits on unborn branch

From: Paul Tan <pyokagan@gmail.com>
Date: Jun 9, 2015, 08:54 UTC
Message-ID: <CACRoPnT4CcJxQtTCzbOVRhHmN4MvzBx1S6x53CRuwFF9e+N4SQ@mail.gmail.com>
In-Reply-To: <xmqq4mmi9cwb.fsf@gitster.dls.corp.google.com>

On Tue, Jun 9, 2015 at 4:13 AM, Junio C Hamano <gitster@pobox.com> wrote:

Show 15 quoted lines

> Paul Tan <pyokagan@gmail.com> writes:
>
>> Since 7b3b7e3 (am --abort: keep unrelated commits since the last failure
>> and warn, 2010-12-21), git-am would refuse to rewind HEAD if commits
>> were made since the last git-am failure. This check was implemented in
>> safe_to_abort(), which checked to see if HEAD's hash matched the
>> abort-safety file.
>>
>> However, this check was skipped if the abort-safety file was empty,
>> which can happen if git-am failed while on an unborn branch.
>
> Shouldn't we then be checking that the HEAD is still unborn if this
> file is found and says that there was no history in the beginning,
> in order to give the "am on top of unborn" workflow the same degree
> of safety?

We do already check to see if the HEAD is still unborn:

        abort_safety=$(cat "$dotest/abort-safety")
        if test "z$(git rev-parse --verify -q HEAD)" = "z$abort_safety"
        then
            return 0
        fi
        gettextln "You seem to have moved HEAD since the last 'am' failure.
    Not rewinding to ORIG_HEAD" >&2

If HEAD is unborn, then git rev-parse will not print anything, so we would be comparing an empty string to an empty string.

Thanks, Paul