On Wed, Mar 05, 2014 at 11:47:12AM -0500, Phillip Susi wrote:

> > I can't get Chris's script to fail on any version of git. Can you
> > show us an example of a patch that does not behave (or better yet,
> > a reproduction recipe to generate the patch with "format-patch")?
> AHA!  It requires a conflict.  There were simple conflicts in the NEWS
> file so I applied the patch with git am --reject and fixed up the
> NEWS, and ran git am --resolved.  The git am --reject fails to add the
> new directory to the index.

Thanks, I can reproduce here. I do not think it has anything to do with
being in a subdirectory; any new file does not get added to the index.
In fact, I do not think we update the index at all with "--reject". For
example, try this:

    git init repo &&
    cd repo &&

    echo base >conflict &&
    echo base >modified &&
    git add . &&
    git commit -m base &&

    echo master >conflict &&
    git add . &&
    git commit -m master &&

    git checkout -b other HEAD^ &&
    echo other >conflict &&
    echo other >modified &&
    echo other >new &&
    git add . &&
    git commit -m other &&

    git checkout master &&
    git format-patch other -1 --stdout >patch &&
    git am --reject patch

Running "git status -s" shows:

   M modified
   ?? conflict.rej
   ?? new
   ?? patch

We apply the changes to "modified" and "new" to the working tree, but we
do not stage anything in the index. I suspect this is because our
invocation of "apply --index" (which is what is doing the real work with
"--reject" here) bails before touching the index. In theory it should be
able to update the index for files that applied cleanly and leave the
other ones alone.

But I have not thought hard about it, so maybe there is a good reason
not to (it is a little weird just because the resulting index is a
partial application of the patch).  The "am -3" path does what you want
here, but it is much simpler: it knows it can represent the 3-way
conflict in the index. So the index represents the complete state of the
patch application at the end, including conflicts.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to