ext Junio C Hamano wrote: > Kristian Amlie <kristian.amlie@xxxxxxxxx> writes: > >> ext Junio C Hamano wrote: >> ... >>> For example, you may notice that, after making a clean checkout, one path >>> has a wrong attribute assigned to it, and may try to correct it. But how? >>> >>> $ edit .gitattributes ;# mark foo.dat as binary >>> $ rm foo.dat >>> $ git checkout foo.dat ;# make sure the new settings is correct??? >> As far as I can see, this works without any modifications to the patch. >> Is that maybe because git_attr_set_direction() is not called if you use >> that form of checkout? > > But that in itself can be seen as a bug, right? In another use case, > suppose you botched your .gitattributes in HEAD version and noticed that > foo.dat is checked out with a wrong attribute. You try to fix it like > this: > > $ git reset HEAD^ .gitattributes > $ rm foo.dat > $ git checkout foo.dat > > If you do not flip the direction, the one from the work tree is used which > is not what you want. If you do, then you break the other use case. Right, I didn't even think about that case. My idea of gitattributes was that the working tree copy is always the master version, and takes precedence. The only reason that the index takes precedence in the "git checkout <branch>" case is that there is no other way to get it checked out correctly, so I see this as an implementation detail. I'm sure some people would disagree though. But you're right, there is no way to make both cases correct. From my standpoint I'd say that the behavior of your patch is the most intuitive. I'll follow up with the test case. -- Kristian -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
