Re: [RFC] git-am: handling unborn branches

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 4, 2015, 17:26 UTC
Message-ID: <xmqqpp5bv0z9.fsf@gitster.dls.corp.google.com>
In-Reply-To: <CACRoPnSmF0ym7ONnLAfL=o5ouSrP2Ucxdh40k6Ps-hnTsSUx4w@mail.gmail.com>

Paul Tan <pyokagan@gmail.com> writes:

> git-am generally supports applying patches to unborn branches.
> However, there are 2 cases where git-am does not handle unborn
> branches which I would like to address before the git-am rewrite to C:

Show 14 quoted lines

> 1. am --skip
>
> For git am --skip, git-am.sh does a fast-forward checkout from HEAD to
> HEAD, discarding unmerged entries, and then resets the index to HEAD
> so that the index is not dirty.
>
>         git read-tree --reset -u HEAD HEAD
>         orig_head=$(cat "$GIT_DIR/ORIG_HEAD")
>         git reset HEAD
>         git update-ref ORIG_HEAD $orig_head
>
> This requires a valid HEAD. Since git-am requires an empty index for
> unborn branches in the patch application stage anyway, I think we
> should discard all entires in the index if we are on an unborn branch?

Yes, and it should also remove the new files the failed application brought in to the working tree, if any, to match the "--skip" done in the normal case (i.e. when we already have a history to apply patches to), I would think.

Show 6 quoted lines

> 2. am --abort
>
> For git am --abort, git-am.sh does something similar. It does a
> fast-forward checkout from HEAD to ORIG_HEAD, discarding unmerged
> entries, and then resets the index to ORIG_HEAD so that local changes
> will be unstaged.

In general, the "apply to nothing" is more or less an afterthought and was not done as carefully as the rest of the program, so view whenever you see a strange behaviour as not a "strange spec" but likely to be a bug. You would do OK if you imagine what should happen if you were doing the same operation on top of a commit that records an empty tree and try to match the behaviour to that case.

Thanks.