"Josh England" <jjengla@xxxxxxxxxx> writes: > On Mon, 2007-09-24 at 14:07 -0700, Junio C Hamano wrote: > ... >> If you want to spacial case >> >> $ git checkout otherbranch path.c >> >> it raises another issue. Which commit should supply the >> "extended attribute description" for path.c? Should it be taken >> from the current commit (aka HEAD), otherbranch, or the index? > > This already is a special case and your question is valid but not one > that git should necessary care about. Since extended attributes are not > built into git the only way to handle them is through hooks. A such, it > is up to the hook to worry about these kinds of issues. The fear I have is that that kind of thinking would necessitate your hook to be called after the user edits paths.c in any other way not to confuse users. What I am questioning is where we should stop, in order to keep things simpler to explain, and I happen to think that it is far easier if we can teach that "git checkout other path.c" is equivalent to "git cat-file blob other:path.c >path.c" followed by "git add path.c", than saying "checkout is magical and if you have external hook it can do far more than editing the file yourself to arrive at the same contents". But I am obviously not the one who is interested in tracking extended attributes attached to git contents, and I do not feel too strongly about one way or the other. I am Ok with it if you think "checkout is magical" is easier to teach [*1*]. I just wanted to make sure we know what semantics this is bringing in, and get it clearly documented. That's all. [Footnote] *1* I actually suspect this might be the case. I consider that per-path checkout from a commit is just a fancy and handy way to edit individual files but that probably comes from knowing how git works too much and I lost my git virginity too long ago. A pure "user" who types "git checkout commit path" may actively expect "checkout" command to do something more magical than simply updating the index and the work tree files to a random state that happens to match the state recorded in one commit. - 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
