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

[Nicolas Pitre <nico@cam.org>]

On Thu, 21 Jun 2007, Shawn O. Pearce wrote:

> > Nicolas Pitre <nico@cam.org> writes:
> > > 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.

First of all, I mentioned at the time that using a . for separator 
between the tagged version and the number of commits since then in the 
git-describe output was a bad idea.  You just made the perfect 
demonstration of that.  If it was just me I'd change that . for a + or a 
: like the original patch did.

Now to your issue.  I think that if you must rely upon a particular 
version then it's best if it is a released version.  Intermediate 
versions as provided by git-describe aren't reliable enough to provide 
a proper number to test against, especially in the presence of 
concurrent branches.  The 1.6.0+38 (let me use a saner output) from the 
master branch is totally different from 1.6.0+38 from the 'next' branch.  
So only released versions should be used to compare against.

Now you say that you don't want to wait for the release to happen before 
using this cool new feature.  Well, I'd reply that life is tough.  
Either you 
trick Junio into making a release sooner because the feature is just too 
valuable to wait.  Or you try the feature (git-blame -w) and hope for 
the best.  Certainly in that case you can predict the behavior of 
older git-blame versions if you pass it -w which they don't understand?

> 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.  

Fair enough.

> 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.

Well you should be able to just try the option and detect it when it 
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).

Those are different as you have an older version that couldn't 
anticipate the future.  In your case you can "anticipate the past".


Nicolas