[RFC] git-am: handling unborn branches

Hi,

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?

Or, the current behavior of git-am.sh will print some scary errors about the missing HEAD, but will then continue on to the next patch. If the index is not clean, it will then error out. Should we preserve this behavior? (without the errors about the missing HEAD)

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.

        if safe_to_abort
        then
            git read-tree --reset -u HEAD ORIG_HEAD
            git reset ORIG_HEAD
        fi
        rm -fr "$dotest"

This, however, requires a valid HEAD and ORIG_HEAD. If we don't have a HEAD or ORIG_HEAD (because we were on an unborn branch when we started git am), what should we do? (Note: safe_to_abort returns true if we git am with no HEAD because $dotest/abort-safety will not exist) Should we discard all entires in the index as well? (Since we might think of the "original HEAD" as an empty tree?)

Or, the current behavior of git-am.sh will print some scary errors about the missing HEAD and ORIG_HEAD, but will not touch the index at all, and still delete the rebase-apply directory. Should we preserve this behavior (without the errors)?

Thanks, Paul