Re: [PATCHv2 0/3] Fix unnecessary (mtime) updates of files during merge
- From
Elijah Newren <newren@gmail.com>
- Date
- Mar 2, 2011, 23:11 UTC
- Message-ID
- <AANLkTinuK=VbNVNraBnxoMHrDvSh-W7+QBEbOJWQaC=y@mail.gmail.com>
- In-Reply-To
- <20110301193142.GA10082@sigill.intra.peff.net>
Hi,
Thanks for all the feedback.
On Tue, Mar 1, 2011 at 12:31 PM, Jeff King <peff@peff.net> wrote: ...
> As you mention, this second testcase is not a regression at all, and > while it would be great if we could avoid touching those files at all, I > don't think anybody will be too upset at files being rewritten that were > actually involved in the conflict.
Well, technically they weren't involved in a conflict. One side had an unmodified directory of files, the other side removed that directory and just put a file there. Someone starts the merge on the side that only has a file there. There's no conflict, but we update the file.
Still, it's a lot better than erroring out and claiming there was a conflict, so it's still an improvement over what we had.
Show 6 quoted lines
> I think the fix you have for the first testcase is reasonable. It feels > a little like a band-aid, as we are throwing away stat information early > on and then pulling it again from the filesyste at the end. But from > your description, the real fix to that would probably involve some > changes to the way unpack_trees works, and that's probably complex > enough that the band-aid is a good fix for now.
I agree, it does seem like a bit of a band-aid, but as you say I was worried about the complexity of changing unpack_trees and wanted a good interim fix. Of course, Junio's point about deleted-as-unmodified files might be sticky enough that we have to start looking at such alternatives or do something more. We'll have to see what he says.