On Fri, Jun 5, 2015 at 1:26 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Paul Tan <pyokagan@xxxxxxxxx> 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. Hmm, actually git-am.sh doesn't seem to do that even when we have a history to apply patches to. This is okay in the non-3way case, as git-apply will check to see if the patch applies before it modifies the index, but if we fall back on 3-way merge, any new files the failed merge added will not be deleted in the "git read-tree --reset -u HEAD HEAD". Should we do that? I dunno, but if we want to introduce this feature, I think a "git read-tree --reset HEAD HEAD && git read-tree -m -u $(git write-tree) HEAD" will do the trick? (We discard all unmerged entries, then fast-forward from the tree the failed merged left us with back to HEAD). Clearing the index in the unborn branch case seems to be the most consistent thing to do for now (for the purpose of the git-am rewrite). 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