On Jul 29, 2007, at 6:30 PM, David Kastrup wrote:
a) this required the installation of additional software for a simple task.
I would think it's preferable to have a single piece of software to manage these links than attempt to craft a custom solution for every package you install.
b) if the software worked using symbolic links, it would not know at what level to make the links (namely create /usr/local/share/man/man1 and link every file from /opt/git/share/man/man1, but link the directory /usr/local/share/git-core directly to /opt/git/share/git-core).
What stow does is to create a directory for every level where multiple packages have files or non-stow files exists. It would create a link at /usr/local/share/git-core because nobody else uses that directory. If there are other /usr/local/share/man/man1/* files, it would make a link for every file in the git version.
Since the stuff is strictly an additional convenience not impacting any of the existing targets, I would not have thought it terribly controversial.
It's additional maintenance, mostly. I don't have an objection to it, although I also don't see a reason to include it.
Is there a place other than the git list where one can provide patches that are not likely to end up in git.git?
You could make a repo at repo.or.cz, I think. Have different branches to maintain features and rebase them on top of master periodically. Or just any random web-page to publish raw patches.
My $0.02, ~~ Brian - 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
