On Mon, Sep 24, 2007 at 02:07:36PM -0700, Junio C Hamano wrote: > "Josh England" <jjengla@xxxxxxxxxx> writes: > > > ... Granted, the > > branch (and HEAD) does not change for this operation, but that shouldn't > > matter. It is somewhat in line with the principle of 'least-surprise': > > if the hook runs for 'git checkout otherbranch', but not 'git checkout > > otherbranch path.c', this could cause confusion and distress to the > > user. IMO, it is a 'checkout' so the post-checkout hook should run. > > Why is that so insane? > > Because I find it would be surprising if the following commands > behave differently: > > $ git cat-file blob otherbranch:path.c >path.c > $ git show otherbranch:path.c >path.c > $ git diff -R otherbranch path.c | git apply > $ git checkout otherbranch path.c Actually, they already act differently even without any hook. If path.c is a symbol link then 1 and 2 will give a different result than commands 3 and 4. On the other hand, while the difference in above commands understandable (in case 1 and 2, the shell creates path.c; and in 3 and 4, git creates it), I really dislike the idea of "checkout is magical." I believe that command 3 and 4 should always give the same result or Git is broken. Another reason, why I dislike the post-checkout hook is that it is prone to abuse like as not so smart user trying to put some content modification here. Moreover, it appears to be excessive to me, because if you want to run something after git-checkout, you can write a simple shell script for that that first runs git-checkout with the given arguments and then run whatever you want. I don't see why we should modify Git for that. Perhaps, it would be better to have a hook on modification, which is invoked every time when Git wants to try to change anything in the working directory. The hook could receives on the input something that looks like 'git-diff --name-status' output and can do any work on creation files, etc. It is much more flexible, because you can do additional stuff here like creating one directory in the path as a symbol link somewhere else or something like that. But what is much more important is that everything work _consistently_ and you get the same results whether you type: git diff -R otherbranch path.c | git apply or git checkout otherbranch path.c If you start with one "magical interface" then eventually you will end up with everything being so magical that no one can make sense of it. Please, stay consistent. Dmitry Potapov - 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
