On Thu, Jun 4, 2015 at 3:34 AM, Paul Tan <pyokagan@xxxxxxxxx> wrote:
> 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?
That makes sense.
>
> 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)?
I guess so, looking at the documentation
--abort
Restore the original branch and abort the patching operation.
a user may want to not go to the unborn branch, but rather to the previous
HEAD?
>
> Thanks,
> Paul
--
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