Re: Closing the merge window for 1.6.0

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 15 Jul 2008, Shawn O. Pearce wrote:

> Nicolas Pitre <nico@xxxxxxx> wrote:
> > 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.
> > 
> > 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.
> 
> If we consider that supporting 1.4.4.4 clients is still a priority,
> due to the widespread distribution of that version in a popular
> version of Debian, we shouldn't be rushing the index v2 or OFS_DELTA
> functionality on by default in 1.6.0.  

OFS_DELTA is supported by 1.4.4.4 so that's a non issue.

> Instead we would wait until Debian stable (and most other widely 
> popular distributions) are on a modern enough version of Git to 
> understand this format.

I don't think we should have git development be dictated by some 
discutable policy from one distribution.

IMHO git prior 1.5.0 is so horrible as general usability goes, and so 
different from what everybody is discussing on the net, that no one sane 
should still be using it. Even ourselves (i.e. the git community) are 
not supporting git 1.4.4 anymore so this hardly can be a priority.

As far as I know, there is no other widely popular distribution other 
than Debian using git prior 1.5.0 in their latest release. If Debian 
people want to support git 1.4.4 although we called thatversion obsolete 
_long_ ago then that's their problem.  We should not be bound by that 
external policy to which we never agreed with.

Now I proposed a compromise which consists of making 1.4.4.4+1 able to 
cope with index v2.  That should fall into Debian's "major usability 
fix" category.  I think that is a far better compromize than delaying 
index v2 even further.

> Really.  As much as I'd love to see the switch to v2 made by default
> I don't think we can/should do it unless the majority of the user
> base will be able to grok it.  And Debian etch sounds like it won't.

I truly hope the majority of the user is _not_ using 1.4.4.4.  Otherwise 
I may only have pity for them.


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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux