ext Junio C Hamano wrote: > In a well structured git program, we always read from the work tree and > the index (to see if there is something changed---you need to be able to > apply convert_to_git when you do this), internally compute what should > happen (e.g. decide that the new result needs to be checked out for a > path), and then write it out (you apply convert_to_working_tree while you > do this). So how about doing something like the attached patch? > > The patch allows the caller to tell the usual "read from the working tree, > if not use the version from the index as the fallback" logic to be swapped > around, and take the index version. It may or may not pass your new tests > (I haven't even compile tested it), but I think the damage is minimized > compared to your version. You're right, that's a much cleaner approach. The patch is really good as far as I can see. It fixes both my test cases (including the one I wasn't able to fix), and there are no additional failures when running the autotests. Do you have second thoughts about it, or is it good enough to apply? If it is, I'll move the test case into t0021-conversion.sh like you said and give you a new patch for that. > It is great that you are trying to fix this issue for the most obvious > "switching between two branches while not having a local change" case, but > frankly, I do not think this is solvable in more general cases, and that > is why it was kept "known to be broken, not worth fixing" state. > > 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? -- 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
