Jonathan Nieder <jrnieder@xxxxxxxxx> writes: > Junio C Hamano wrote: >> Anders Kaseorg <andersk@xxxxxxx> writes: > >>> The executable bit on gitk-git/gitk was lost (accidentally it seems) by >>> commit 62ba5143ec2ab9d4083669b1b1679355e7639cd5. Put it back, so that >>> gitk can be run directly from a git.git checkout. >>> >>> Note that the script is already executable in gitk.git, just not in >>> git.git. >> >> It did not lose the bit by accident but 62ba5143 pretty much was a >> deliberate fix. "gitk" is a source file, and its build product, >> gitk-wish, is what is eventually installed with executable bit on. > > How does this case differ from other executable source files like > git-am.sh? Ok, strike that. In the old days, some of us (but not me) used to value somewhat to be able to run git-$frotz.sh from the build directory before installing, and having the executable bit was in line with that philosophy. I don't know if it still hold today, though. For one thing, our Makefile replace a lot more than it used to when building $(SCRIPTS) out of the source files and git-$frotz.sh may not run in place as easily as before anymore. So it doesn't matter too much either way (and of course you can always say "sh ./git-$frotz.sh" when it is not executable and the functioning of the script does not depend on replacement done by the Makefile). It seems that the majority is marked with executable bit, so just for the sake of uniformity it probably is Ok to make it executable. From a purist's point of view, I'd rather see them uniformly marked as non-executable, but as I said, it doesn't matter much to me (iow, meh). The change needs to come from gitk repository, so I'll leave it up to Paul ;-) Thanks for a sanity, Jonathan. -- 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