Re: Bug: stash staged file move loses original file deletion

From: Jeff King <peff@peff.net>
Date: Dec 6, 2016, 15:25 UTC
Message-ID: <20161206152530.snccf7buiosst3e4@sigill.intra.peff.net>
In-Reply-To: <CAFQpxx+PJ3FSoH9DFWyEw+ZLagji9Qou+aY9EB8A+=t+QX0o2A@mail.gmail.com>

On Tue, Dec 06, 2016 at 02:45:05PM +0000, Matthew Patey wrote:

Show 6 quoted lines

> Thanks for the reply! I agree that it is weird that applying a stash with a
> move only puts the addition back in the index, and thanks for the tip on
> "index" to properly apply that. For this case I was focusing on the
> behavior of the second stash/apply, with the first stash/apply as an
> example of how to get into a weird state that triggers the odd behavior of
> the second.

Oh, heh, I totally missed that.

I agree that the second stash not saving the deletion seems like a bug. Oddly, just stashing a deletion, like:

  rm a
  git stash
  git stash apply

does store it. So it's not like we can't represent the deletion. Somehow the presence of "b" in the index matters.

It looks like the culprit may be this part of create_stash():

  git diff --name-only -z HEAD -- >"$TMP-stagenames"

That is using the "git diff" porcelain, which will respect renames, and the --name-only bit mentions only "b".

If you run:

  git -c diff.renames=false stash

then it works.

-Peff