From: Jeff King <peff@peff.net>
To: Phillip Susi <psusi@ubuntu.com>
Cc: Chris Packham <judge.packham@gmail.com>,
"git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: New directory lost by git am
Date: Wed, 5 Mar 2014 12:13:34 -0500 [thread overview]
Message-ID: <20140305171334.GA31252@sigill.intra.peff.net> (raw)
In-Reply-To: <53175510.7020000@ubuntu.com>
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.
-Peff
next prev parent reply other threads:[~2014-03-05 17:13 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-05 2:49 New directory lost by git am Phillip Susi
2014-03-05 3:08 ` Chris Packham
2014-03-05 3:22 ` Phillip Susi
2014-03-05 8:10 ` Chris Packham
2014-03-05 14:26 ` Phillip Susi
2014-03-05 16:34 ` Jeff King
2014-03-05 16:47 ` Phillip Susi
2014-03-05 17:13 ` Jeff King [this message]
2014-03-05 18:29 ` Phillip Susi
2014-03-05 19:10 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140305171334.GA31252@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=judge.packham@gmail.com \
--cc=psusi@ubuntu.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).