Jeff King <peff@xxxxxxxx> writes: > I can, of course, always make my own hardlinks (which is really the same > thing, except the "trick" is slightly harder to perform and perhaps less > socially acceptable; OTOH, if such a trick is common, perhaps it means > taking away the dash forms wasn't such a good idea after all). > >> Newbie: Stupid inconsistency. Who suggested that? > > Jeff [runs git-blame]: It must have been Junio! :) You found a bug in git-blame, then ;-). I think it should report Jeff. As Windows ports need to have their own difference _anyway_, I personally do not think it is a big deal if the Makefile I ship continues to install the dashed form in gitexecdir, and Windows ports omit the hardlinks if they feel copies are wasteful. However, that would introduce hard-to-track platform dependent bugs (e.g. "git-receive-pack" is asked for by "git-send-pack", but the other side does not have such a program anywhere). So my preference at this point is to move things out of PATH first (without removing the hardlinks), deal with possible fallout from that move. And after things stablize, discuss to either remove the hardlinks from all installations, or to keep them in all installations. I do not think "it's this way here but that way there" is a good thing in general. We do have "git-foo.exe" vs "git-foo" difference and there are some existing code (most notably, help.c::list_commands_in_dir()) that need to be aware of it. Let's try not to make things any worse. - 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
