Erik Faye-Lund wrote: > On Fri, May 9, 2014 at 10:48 AM, Felipe Contreras > <felipe.contreras@xxxxxxxxx> wrote: > > Erik Faye-Lund wrote: > >> On Fri, May 9, 2014 at 10:14 AM, Felipe Contreras > >> <felipe.contreras@xxxxxxxxx> wrote: > >> > If you want this script to remain in contrib, please: > >> > > >> > a) Write at least a few tests > >> > b) Write some documentation > >> > c) Explain why it cannot live outside the git.git repository like other > >> > tools. [1][2][3] > >> > >> (Adding Marius, the original author to the CC-list) > >> > >> Uh, why is such a burden required all of a sudden? contrib/README > >> mentions no such requirements, and the scripts have been accepted (and > >> maintained) since. > > > > contrib/README mentions clearly the expectation that these scripts > > eventually move to the core once they mature. This is never going to > > happen for these. > > Yes, *expectation*. Not requirement. That's right, but these tools fail all expectations. > > It also mentions that inactive ones would be proposed for removal, and > > this one is clearly inactive. It has 9 commits (if you count the one > > that changes the execution bit). > > It mentions that Junio *might* suggest things to be removed, not that > things *should* be removed if left unmaintained. That's right. > And this script is not unmaintained, it's simply just still working. Prove it. Either way, if there was people actively caring about these scripts, there should be cleanups, tests, documentation. But there's nothing. > >> Besides, you say "No activity since 2010" - this is not the case, > >> bc380fc is from November 2013. > > > > You think changing the execution bit of a file is considered "activity"? > > Well, now we're getting into semantics, which I don't care so much > about. Convenient. > It shows some sort of interest in the scripts, at least. Not it doesn't. Jonathan Nieder updated the execution bit on a bunch of scripts in contrib, these being just in the way. It doesn't show interest at all. > >> And there's already *some* documentation in the scripts themselves. > > > > That's nice. So you can just copy that into a README. > > Feel free to scratch that itch yourself, you're the one inventing new > requirements here. If you care about these scripts, you have an interesting way of showing it. > >> Please stop your pointless crusade that'll only break other people's work-flows. > > > > If you care about these scripts, it should be trivial for you to add at > > least a few tests, souldn't it? > > Again, testing this is not my itch. Feel free to scratch that one > yourself, but please don't remove the script. If you don't care that these scripts keep working properly, I don't see why anybody else would. > > Please tell me how exactly will your work-flow be broken. More > > specifically, tell me why your scripts cannot be moved outside of git, > > like git-extras[1], git-deploy[2], git-ftp[3], and countless other > > tools. > > Moving the script out of the repo makes it less convenient to bisect > issues with MSVC, as it depends heavily on the top-level Makefile. > Moving it out would require figuring out what version of the script > matches a given git revision, which is a hassle. The script doesn't depend on the version of the Makefile, and proof of that is that is has *never* been changed even though the Makefile has. If you do: % cd ~/git % ./contrib/buildsystems/generate You can do: % cd ~/git % ~/buildsystems/generate And the result would be *exactly* the same. That is not a reason. -- Felipe Contreras -- 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