Re: [RFC/PATCH 2/2] stash: drop dirty worktree check on apply

From: Jeff King <peff@github.com>
Date: Apr 5, 2011, 22:50 UTC
Message-ID: <20110405225038.GB7358@sigill.intra.peff.net>
In-Reply-To: <20110405221827.GA4123@sigill.intra.peff.net>

On Tue, Apr 05, 2011 at 06:18:28PM -0400, Jeff King wrote:

Show 14 quoted lines

> > I _think_ the reason we originally insisted on clean working tree was that
> > while merge-resolve has always had an acurate check, merge-recursive's
> > check was not very good, especially when renames are involved.  So
> > probably this part of your comment ...
> > 
> > > I'm not sure if the check was perhaps even required when git-stash was
> > > written, and has simply since become useless as merge-recursive became
> > > more careful.
> > 
> > ... may need to be used to rewrite bullet 2. above.
> 
> That makes sense to me. I'd be a lot more comfortable if I could find
> the actual place where merge-recursive got more accurate. I'll see if
> it's simple to bisect.

Hmm, no such luck. In v1.5.0, before stash even existed, "git merge" will properly fail on this case (though the error message isn't as pretty):

-- >8 -- #!/bin/sh

rm -rf repo

mkdir repo && cd repo && git init-db && echo base >file && git add file && git commit -m base && echo master >>file && git commit -a -m master && git checkout -b other HEAD^ echo other >>file && git commit -a -m other && echo more >>file && git merge master -- 8< --

which leads me to believe there is a more complex case that merge-recursive wasn't handling at the time, and which may or may not be handled better today. What that case would be, I have no clue.

-Peff