linux@horizon.com writes: > 3) This says that if stage1 and state3 exist, use stage3. > 3-way says if they're equal, delete the file, while if they're > unequal, it's fail. > > Given that it all matches up so nicely, I'd like to honestly ask if > case 3 of the conditions is correct. I'd think that if I deleted > a file form te index, and the file wasn't changed on the head I'm > tracking, the right resolution is to keep it deleted. Why override > my deletion? > > Sorry if this is a dumb question, but it's not obvious to me. Funny that I asked exactly the same question when it was done first: http://marc.theaimsgroup.com/?l=git&m=111804744926989 It was a question about then-current code, so other cases might have been changed/corrected/enhanced since then, but I believe the behaviour for the case in question here stays the same til this day, and the response from Linus to that article still applies. http://marc.theaimsgroup.com/?l=git&m=111807024201485 I'll quote only the punch line here, but the whole thing is worth a read if you want to understand how this evolved and what the design choices and decisions were: Right. We didn't lose anything hugely important. In theory this could be a delete that we've missed, and we could add a flag to actually reject this case. However, it's always easy to "recover" deletes (just delete it again ;), so the loss of information is absolutely minimal, and it allows starting from an empty index file. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Thu Dec 01 07:24:43 2005
This archive was generated by hypermail 2.1.8 : 2005-12-01 07:24:49 EST