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

["Shawn O. Pearce" <spearce@spearce.org>]

Junio C Hamano <gitster@pobox.com> wrote:
> Nicolas Pitre <nico@cam.org> writes:
> > I don't like this feature list idea at all.
> 
> ... and thanks for bringing a bit of sanity to this thread.

Indeed.  I've read Junio's counter proposal (the grep'ed FEATURE<?>
macro) and I'm now convinced you are both right, this feature list
thing is just going to grow out of control or nobody is going to
mark new features.  Either way its useless for its intended purpose.
 
> > 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.

Here's the problem though: `git-blame -w` will be supported
in Git 1.5.3 and later, we all know this.  But Git doesn't.
Ask git-describe what version `master` and `next` are; its
v1.5.2.2-249 and v1.5.2.2-1050.

So tell me, how can git-gui know that Git 1.5.2.2.249 is OK, and
1.5.3 is OK, but 1.5.2.3 isn't?  Actually its 1.5.2.1.160 that is
OK (b82871b introduced the -w option).  Sure Junio won't release
a 1.5.2.1.160 as an actual tagged release (160 patch releases to
1.5.2.1 is nuts).  But what about in the future if a cool feature
3 commits past 1.5.3 appears?  Wouldn't that look like 1.5.3.3,
and isn't that a possibly valid version number?

Besides, I can't say 1.5.2.3 is >= 1.5.2.2.249, because in git.git
it isn't.  Only 1.5.3 will be >= 1.5.2.2.249.


Nico mentioned that git-gui ships with git.git, and therefore should
just rely on exactly whatever that git.git supports at the time of
the merge.  I think that is only partially valid.  git-gui is also
an independent project with a repository and history that exists
outside of git.git.  Users can (and should be able to) mix and
match the version of git-gui with the version of plumbing, to the
maximum extent possible.  I'd like to at least gracefully fail by
disabling an option, or suggesting the user upgrade their plumbing,
if an option isn't supported.

Unlike how we gracefully fail with a useful error message say
when an early 1.4 release that doesn't support offset deltas is
given a packfile with an OFS_DELTA in it (corrupt pack, recently
rediscussed on list).  Or when a 1.5.1 client tries to checkout
a tree that uses the new subproject mode in 1.5.2 (missing blob,
recently discussed on #git).

Maybe I should ask the StGIT folks how they deal with this, or if
they just don't worry about it.  I'm suspecting its the latter...


Hmm.

-- 
Shawn.