On Wed, Mar 05, 2014 at 09:26:43AM -0500, Phillip Susi wrote:

> Hash: SHA1
> On 3/5/2014 3:10 AM, Chris Packham wrote:
> > My example is creating a commit on the "temp" branch then applying
> > it to the "master" branch using git am.
> > 
> >> Do a reset HEAD~1 --hard, and git clean -x -f -d before git am.
> >> I didn't notice the missing file myself for some time because it
> >> is left in the working tree, just not added to the index and
> >> included in the commit.
> >> 
> Right... so the file is left in the directory, even though it is not
> checked in.  A git status should show it is an unknown file, and a
> clean should remove it.

I don't think those steps are necessary for Chris's example. When he
switches back to the master branch, git removes the subdirectory (the
file is tracked in "temp" but not "master", so we remove it when
switching branches, and then the directory is empty, so we clean it up,
too). You can verify with an extra "ls" after the checkout but before
the "am".

> > * "git apply" parsed patches that add new files, generated by
> > programs other than Git, incorrectly.  This is an old breakage in
> > v1.7.11.
> > 
> > Does that sound like your problem? If you can I'd suggest
> > updating, ideally to the recent 1.9.0 release but if you're feeling
> > conservative try
> Vaguely, except for the "other than git" part.  This patch was
> generated by git-format-patch ( I didn't think apply handled patches
> that weren't ).

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")?

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