Junio C Hamano <gitster@xxxxxxxxx> wrote: > Nicolas Pitre <nico@xxxxxxx> 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. - 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
