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

From: Junio C Hamano <[email-masked]>
Date: Thu, 04 Jun 2015 10:26:34 -0700

Paul Tan <[email-masked]> 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:

> 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.

> 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.