On Mon, 2007-09-24 at 16:54 -0700, Junio C Hamano wrote: > "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. OK. I'll try to come up with some good wording for the documentation. So this leads to my next question: Should the post-merge patch be brought in under this same umbrella to form a single post-checkout hook, or should it stay a separate hook? -JE - 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
