On Tue, Jul 15, 2008 at 11:20:23AM +0200, Petr Baudis wrote:
quoted text
> 
> 	(iii) Most importantly, this is not about waiting another few
> 	years for Debian to catch up, since the next stable release
> 	should really be upcoming rather soon:
> 
> 		http://debian-community.org/LennyReleaseSchedule/

Even if Lenny will be released right on the scheduler (which I seriously
doubt), Etch will be around for another year. In fact, the last release
of oldstable (sarge) happened on April 12 this year.  Thus delaying of
indexversion=2 does not help much here. Anyone who is more or less
seriously about using Git grabs it from backports. The downside of
delaying is that any incompatible changes are much less welcome by users
during minor releases than major ones. People tend to read release notes
during major releases more carefully and think whether they prefer new
features or backward compatibility. This choice will not be the same for
anyone, but changing default settings on the major release is much more
appropriate than during minor ones.

quoted text
> 
> 	(iv) These problems do not concern people who are currently
> 	_actively_ _working_ with Git; these people hopefully do not
> 	use 1.4 willingly and already use Git from backports.org.
> 	This is about user experience for casual users who are quite
> 	possibly interested only in read-only tracking of upstream
> 	using Git - these people will likely use default Debian Git
> 	version and that is okay, because frankly, for them, the
> 	1.5 improvements do not really matter much. This is also
> 	large class of prospective future real Git users and we might
> 	not want to ruin Git's reputation in their eyes.

I disagree. It is not Git does not support the old format, but it
switches on the new one as default on the next major release, which
is a sensible thing to do. Those repos that think that access for
Git 1.4 users is important for them can set indexformat=1. As to
prospective future real Git users, anyone who is trying to use Git
1.4 is going to hit by many usability issues that were resolved in
1.5; and there is no community support for Git 1.4 either -- you can
ask about any problem with Git 1.4 on this list, and the only answer
you'll get is that you should upgrade your Git. So, there is no way
for newcommers to start using Git 1.4 and be satisfied with it.

Finally, 18 months since 1.4.4 may not appear as a long time ago for
other projects that are being developed for many years, but for Git,
which was only 21 months when Git 1.4.4 was released, 18 months is
really very *long* time ago.

Dmitry
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html