Nicolas Pitre <nico@xxxxxxx> writes:
> On Mon, 14 Jul 2008, Gerrit Pape wrote:
>
>> On Mon, Jul 14, 2008 at 12:57:56PM +0100, Johannes Schindelin wrote:
>> > On Mon, 14 Jul 2008, Petr Baudis wrote:
>> > > I'm saying this because I believe the best conservative upper bound for
>> > > backwards compatibility is Git version in Debian stable. It gets
>> > > probably the most stale from all the widely used software distributions
>> > > using Git, and it *is* quite widely used. Etch carries v1.4.4.4, which
>> > > fails miserably on the new packs.
>> >
>> > Can't we just hit Debian's Git maintainer with a clue bat or a bus,
>>
>> Please don't. It wouldn't help, rather the opposite I think, espacially
>> the bus. We don't introduce new upstream versions into a Debian stable
>> release, there's a great effort done for each stable release to reach
>> high quality integration of all the software packages available in
>> Debian. Once that status is reached, only security fixes and criticial
>> usability fixes are added.
>
> Please consider it as a critical usability problem.
>
> Maybe we can release 1.4.5 with the ability to read index v2? That
> wouldn't be hard to backport the reading part of it.
I am of two minds here.
On one hand, I am sympathetic to distros that want to give long time
support for ancient versions to keep working in an ever-changing new
world. It is a wonderful thing that there are distros that aim for ultra
conservative stability, and I applaud them.
But as the upstream, we have our own deprecation schedule. We should of
course plan carefully not to harm existing users of our releases, but
frankly speaking, 18 months since 1.4.4.4 was tagged (early January 2007)
is an eternity in git timescale. Maybe we will slow down someday, and
this 18-month is not a set-in-stone rule in any way, but at this point
even without the packfile format issues, I personally think anything
before 1.5.0 is irrelevant --- maybe they are interesting as historical
curiosities, but not more than that.
We could:
$ git checkout -b maint-1.4 v1.4.4.4
$ git merge maint
$ git tag v1.4.4.5
and push the result out. While I would imagine that the end-user
experience after such a maintenance release would be very positive, that
is not something distros who really want to stay with a stale version for
a good reason would want to swallow ;-).
If we _were_ to keep v1.4.4.X series alive, serious backporting efforts
will be necessary. For example, recent 'git-shell' futureproofing was
made not just to 1.5.6.X series but was backported to 1.5.4.X and 1.5.5.X,
and we would probably need to give it to 1.4.4.X as well. What other
things are there that are missing in 1.4.4.X? It would take nontrivial
engineering resource to even list them, let alone assessing how much
effort is required for such backporting and actually doing it.
The remotes/ layout, use of "git-add" for new contents (instead of only
new files), reflogs, detached HEAD, --pretty=format:%<blah>, bundles,
mergetool,... all the things that a modern git workflow revolves around
and are described in the user manuals the users find on the net are not
found in 1.4.4.X series. If a user of such a conservative distro needs to
work with a repository prepared on another platform with newer git,
perhaps crossmounted, should we backport "git branch -r" so that the user
can confortably work with remote tracking branches? Should we backport
reflogs?
If a distro chooses to support its users whom they force to pin at 1.4.4.X
series, it's primarily _their_ choice. I do not mind helping them in such
a backport, but the request has to come from the distro first with a
specific list of items that need to be supported.
--
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
