Re: [PATCH] Make list of features auto-managed.

[Nicolas Pitre <nico@cam.org>]

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