On Thu, 21 Jun 2007, Junio C Hamano wrote: > I am now getting sort of convinced that the list-features is a > slippery slop towards total suckage, unless managed very > carefully. > > The "auto manage" patch I am responding to would tempt anybody > to extend the mechanism to do something like the attached patch, > because a one-line comment near the code, like: > > /* FEATURE<oneline-first-paragraph> */ > > does not look very useful nor pretty by itself in the source > code. It makes it very tempting to actually describe the > "feature". People with only half a brain would even advocate > updating supported_features[] to a tuple of (name, explanation), > and have "git version --list-features" to spit both out, or > something like that. I really do not think we would want to go > there. > > A few years down the road, do we really care if we did not do > something long time ago, but the code was updated and added as a > new feature? That information belongs to the commit log, not to > in-source comments. This will lead to the same mistake often > made by users of other SCMs, embedding "$Log$" in their sources. Well, just in case my opinion matters... I don't like this feature list idea at all. Not only is it going to grow indefinitely with no possibility for garbage collection because programs will depends on particular features to be listed there, the simple fact that deciding if a particular improvement should be listed is a subjective matter which will make the list grow faster than it absolutely should. Given that this appears to be needed by git-guy, and since git-guy is shipped with main git already, it is a bit odd to have to support code to work with older git versions. Why isn't git-guy simply remaining in synch with the git version it is shipped with? This way cruft won't accumulate forever. And if the tool and git core really have to be decoupled, then the best way to test for a specific feature is actually to get the git version. No silly issues with a feature list to maintain, and no issue with a particular feature that might not have been added to the list. When you need git behavior X and you know that it appeared in version Y then you only need to test for git_version >= Y. Determining that particular Y is much easier after the facts using the commit log than trying to anticipate what item should be added to a feature list for future usage. In fact the same argument as for not explicitly recording renames in commit objects should apply here. Nicolas - 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
