"Stephen Cuppett" <cuppett@xxxxxxxxx> writes: > Sorry, I didn't mean to imply a demand on anybody, or mandate anybody > change their workflow... I have to admit that your "I propose" phrase did raise my eyebrow, but it's not a big deal. I've grown thicker skins ;-) As a general principle, I agree it is a good idea to keep git.git easily accessible by people on different platforms and environments. After all, you would need to get git.git in order to obtain newer repository features, so there is a chicken and egg problem involved that is more severe than other projects. That is exactly the reason why I do not use subprojects to bind gitk and git-gui into git.git. It needs to wait until everybody has 1.5.2 or newer --- otherwise peole cannot clone or fetch from git.git to get the feature that allows such a fetch to begin with. It would have been a different issue if the build procedure depended on having a tracked symlink foo.h pointing at cache.h and some source file included foo.h. You cannot build such a thing on a filesystem without symbolic links. But the RelNotes symlink is there for people to easily find the notes for the latest to be released, and that symlink appears as a text file that records the name of the Documentation file in a checkout with "core.symlinks = false"; I do not think it is such a big show stopper, even for people on a filesystem without symbolic links. - 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
