Junio C Hamano wrote:
"Josh England" <jjengla@xxxxxxxxxx> writes: 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*]. [Footnote] *1* I actually suspect this might be the case.
I think so too, if nothing else than for the simple reason than that the hook is called 'post-checkout', so the explanation is likely to go something like 'the checkout program activates it after having updated the worktree'.
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.
Like, run the post-checkout hook? I should think it wouldn't be too hard to believe it will. I imagine the people using this feature will be either git-fanatics that use it for everything and only in their own environment, or sysadmins that get a handy tool for managing config in a corporate environment. I wouldn't be surprised if those sysadmins weren't all too keen on learning the 1001 ways there is to create a file from a special revision in git (and personally I only knew about 2 of the 4 you listed), so for them there'll most likely *only* be git-checkout to edit the work-tree. -- Andreas Ericsson andreas.ericsson@xxxxxx OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 - 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
