From: Junio C Hamano <hidden> Date: 2016-06-15 22:44:56
Nicolas Pitre [off-list ref] writes:
On Mon, 14 Jul 2008, Gerrit Pape wrote:
quoted
On Mon, Jul 14, 2008 at 12:57:56PM +0100, Johannes Schindelin wrote:
quoted
On Mon, 14 Jul 2008, Petr Baudis wrote:
quoted
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.
From: Teemu Likonen <hidden> Date: 2016-06-15 22:44:56
Junio C Hamano wrote (2008-07-14 12:00 -0700):
Nicolas Pitre [off-list ref] writes:
quoted
On Mon, 14 Jul 2008, Gerrit Pape wrote:
quoted
quoted
quoted
On Mon, 14 Jul 2008, Petr Baudis wrote:
quoted
I'm saying this because I believe the best conservative upper
bound for backwards compatibility is Git version in Debian
stable. It gets
quoted
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.
As Debian stable (4.0 "Etch") and its git 1.4.4.4 was mentioned I'd like
to point out that git 1.5.6 is available for Etch users from
kind-of-semi-official <www.backports.org>. So I guess Debian stable
users aren't left completely behind. Git's web page already advertises
backports.org version for Etch.
From: Martin Langhoff <hidden> Date: 2016-06-15 22:44:56
On Tue, Jul 15, 2008 at 7:19 AM, Teemu Likonen [off-list ref] wrote:
quoted
But as the upstream, we have our own deprecation schedule.
As Debian stable (4.0 "Etch") and its git 1.4.4.4 was mentioned I'd like
to point out that git 1.5.6 is available for Etch users from
kind-of-semi-official <www.backports.org>. So I guess Debian stable
users aren't left completely behind. Git's web page already advertises
backports.org version for Etch.
I concur. Users of git on Etch are using backports AFAIK.
We still have the case of the "casual" user, who does not know much
about git, but installs it to clone & review a project's code. There,
if v1.4.4 complains with a useful message, the casual user will swear
a bit and grab a backport. If it dies a horrible uninformative death,
then we will get bogus bug reports, flamage, the works.
cheers,
m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
From: Petr Baudis <hidden> Date: 2016-06-15 22:44:56
On Mon, Jul 14, 2008 at 12:00:54PM -0700, Junio C Hamano wrote:
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.
Really, I think this is should be put into certain perspective:
(i) This change is special since it affects client-server
compatibility in bare repositories. AFAIK, none of the others
you mention does this.
(ii) The CRC checking is perhaps quite an improvement, but I
don't think it is critical-to-have-just-now.
(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/
(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.
--
Petr "Pasky" Baudis
GNU, n. An animal of South Africa, which in its domesticated state
resembles a horse, a buffalo and a stag. In its wild condition it is
something like a thunderbolt, an earthquake and a cyclone. -- A. Pierce
On Tue, Jul 15, 2008 at 11:20:23AM +0200, Petr Baudis wrote:
(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.
(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
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:44:56
Hi,
On Tue, 15 Jul 2008, Dmitry Potapov wrote:
Those repos that think that access for Git 1.4 users is important for
them can set indexformat=1.
Unfortunately, you place quite a high maintenance burden on the repository
maintainers here.
From the time balance sheet, it does not look good at all: a few minutes
for Junio to change and commit, up to a few hours (because they missed it
in the release notes) for probably more than hundred repository
maintainers that are not subscribed to the Git mailing list.
And I absolutely agree with Pasky that this does _nothing_ in the vague
direction of wielding a reputation of being easy to use.
Sure, we can make it easy on ourselves. And it is just as easy to make it
hard on others. If you're okay with that, I am not.
Ciao,
Dscho
On 7/15/08, Johannes Schindelin [off-list ref] wrote:
On Tue, 15 Jul 2008, Dmitry Potapov wrote:
> Those repos that think that access for Git 1.4 users is important for
> them can set indexformat=1.
Unfortunately, you place quite a high maintenance burden on the repository
maintainers here.
From the time balance sheet, it does not look good at all: a few minutes
for Junio to change and commit, up to a few hours (because they missed it
in the release notes) for probably more than hundred repository
maintainers that are not subscribed to the Git mailing list.
To take this in a slightly different direction, what exactly is the
benefit of the new feature? Apparently my git doesn't have it enabled
by default, and git works fine for me. Am I missing out on something
that I should feel inferior about if my non-debian-etch running
friends(*) found out about it? :)
Have fun,
Avery
(*) Actually I compile my own git from source anyway. I never want to
live without "git rebase -i" and "git add -p" ever again. Life is too
short! :)
From: Nicolas Pitre <hidden> Date: 2016-06-15 22:44:57
On Tue, 15 Jul 2008, Johannes Schindelin wrote:
And I absolutely agree with Pasky that this does _nothing_ in the vague
direction of wielding a reputation of being easy to use.
Staying with git versions prior 1.5 isn't either. In fact, git had a
much harder time with its usability reputation in those days. In other
words, if some user of Debian is rebutted by the upgrade path for a later
git version, then the awkwardness of git 1.4.4 UI will be even worse.
Anyway this is all hand waving until someone can come with some evidence
that git 1.4.4 is actually used by a significant amount of people, and
that those people depend on dumb transfer protocols.
Nicolas
On Tue, Jul 15, 2008 at 6:26 PM, Nicolas Pitre [off-list ref] wrote:
Anyway this is all hand waving until someone can come with some evidence
that git 1.4.4 is actually used by a significant amount of people, and
that those people depend on dumb transfer protocols.
Can't we add a msg to 1.4.4.x when it finds pack version 2 to upgrade
to 1.5.x? Gets rid of the problem all together while still giving the
user a reasonable message when it finds a repo version 2.
Hey, here's an idea, can't we have 1.4.4.x just give that msg for everything?
$cat git
#!/bin/sh
echo "Please upgrade to 1.5.x, version 1.4.x is no longer supported
nor should you even want to use it </cluebat>"
--
Cheers,
Sverre Rabbelier
On Tue, Jul 15, 2008 at 04:27:02PM +0100, Johannes Schindelin wrote:
quoted
From the time balance sheet, it does not look good at all: a few minutes
for Junio to change and commit, up to a few hours (because they missed it
in the release notes) for probably more than hundred repository
maintainers that are not subscribed to the Git mailing list.
If you just grab sources and never read release notes, there is nothing
that can help you. If Git 1.6.0 is not the right moment to do these
changes then Git 1.6.1 is neither, regardless whether Debian will
release Lenny by that time or not. People do not upgrade their distro in
the day of release. Some upgraded to Etch not so long ago. So, should we
wait for another year till 1.7.0?
And I absolutely agree with Pasky that this does _nothing_ in the vague
direction of wielding a reputation of being easy to use.
I don't think Git 1.4 is easy to use. If you want Git that is easy to
use install Git 1.5.x. And, it is *much* easier to install Git from
backports then to deal with usability issues of Git 1.4 and the lack
of community support. So, I don't see how this change may hurt.
Sure, we can make it easy on ourselves. And it is just as easy to make it
hard on others. If you're okay with that, I am not.
It has *nothing* to do with making easy on ourselves and hard on others.
The question here is what is the appropriate time to change these default
settings, and I believe that *major* releases are the appropriate time
while minor ones are not.
Dmitry
From: Petr Baudis <hidden> Date: 2016-06-15 22:44:57
On Tue, Jul 15, 2008 at 12:26:48PM -0400, Nicolas Pitre wrote:
Anyway this is all hand waving until someone can come with some evidence
that git 1.4.4 is actually used by a significant amount of people, and
that those people depend on dumb transfer protocols.
That will be hard to produce. :-) _My_ personal story is that I have
Git-1.4.4.4 installed system-wide on repo.or.cz and follow git#next
locally, and quite panicked when I was inspecting some repositories
as root (using the system-wide Git) and these error messages popped up.
This may become a similar experience for others on multi-user systems
where people want to share work but don't realize that one of them has
Git installed locally and the other one doesn't. We can save them the
head-slapping and a bit of wasted life.
Out of interest, I did a simple statistics of HTTP user agents on
repo.or.cz; the dumb access does not seem very widely used overally,
it turns out. The stats begin at 19/May/2008:10:54:32 +0200. Here is the
breakdown, counting unique clients only:
# zgrep '"GET /r/.*/info/packs' /var/log/apache2/repo-access.log* | egrep -v bot\|slurp\|Gecko\|Opera |
cut -d " " -f 1,12- | sed 's/\.g[a-f0-9]*\(\.dirty\)*"/"/' | sort -u |
cut -d ' ' -f 2 | sort | uniq -c | sort -rn | head -n 50
1501 "git/1.5.4.3" <- Ubuntu Hardy (heh.. is just that it?)
278 "git/1.5.5.1" <- RHEL5 (ditto)
151 "git/1.5.2.5" <- Ubuntu Gutsy
133 "git/1.5.5.3" <- ? (maybe Gentoo ~x86 for some time)
125 "git/1.5.4.5" <- OpenSUSE 11.0, FC9, Gentoo x86, Dapper backports
104 "git/1.5.6" <- Debian Lenny
94 "git/1.5.5"
66 "git/1.5.3.7"
63 "git/1.5.5.4"
63 "git/1.5.5.1015"
55 "git/1.5.2.4" <- OpenSUSE 10.3
51 "Mozilla/4.0 (compatible;)" <- huh?
42 "git/1.5.3.8"
37 "git/1.5.5.GIT"
37 "git/1.5.3.5.2229"
34 "git/1.5.6.1"
33 "git/1.5.3.6" <- Feisty backports
31 "git/1.5.4.1"
30 "git/1.5.6.2"
20 "git/1.5.6.GIT"
18 "git/1.5.3"
17 "git/1.5.2.2"
17 "git/1.4.4.4"
15 "git/1.5.6.1.1071"
14 "git/1.5.3.3"
13 "git/1.5.4.4"
13 "git/1.5.4"
11 "git/1.5.6.1062"
11 "git/1.5.5.2"
10 "git/1.5.5.1.316"
(I also got two 1.4.4.2 (feisty?) fetches from one client. No older
Git versions.)
So wrt. keeping backwards compatibility, this is not _very_ convincing,
I admit. ;-)
--
Petr "Pasky" Baudis
GNU, n. An animal of South Africa, which in its domesticated state
resembles a horse, a buffalo and a stag. In its wild condition it is
something like a thunderbolt, an earthquake and a cyclone. -- A. Pierce
From: Junio C Hamano <hidden> Date: 2016-06-15 22:44:57
Johannes Schindelin [off-list ref] writes:
On Tue, 15 Jul 2008, Dmitry Potapov wrote:
quoted
Those repos that think that access for Git 1.4 users is important for
them can set indexformat=1.
Unfortunately, you place quite a high maintenance burden on the repository
maintainers here.
From the time balance sheet, it does not look good at all: a few minutes
for Junio to change and commit, up to a few hours (because they missed it
in the release notes) for probably more than hundred repository
maintainers that are not subscribed to the Git mailing list.
And I absolutely agree with Pasky that this does _nothing_ in the vague
direction of wielding a reputation of being easy to use.
Sure, we can make it easy on ourselves. And it is just as easy to make it
hard on others. If you're okay with that, I am not.
I was not planning to comment on this issue further as the ball is in
Debian's court, but I think you are misguided.
We are not making anything hard on others. Sticking to 1.4.4.4 codebase
is forced by Debian (for its policy) and choice made by its users (for not
knowing or using backports). 1.5.0 and later are vastly better and we
encourage users to update on every occassion we get.
I do not know the extent of the backporting effort necessary, the size of
potentially impacted population if Debian keeps shipping unpatched
1.4.4.4, nor how much Debian cares about supporting their 1.4.4.4 users
i.e. if they are willing and able to carry distro-only forward
compatibility patches, and knowing all of these is necessary before we
declare this is worth handling _ourselves_. That is why I did not want to
take a definitive stance on this issue before hearing from the Debian
maintainer about them -- I said "Debian has to ask with list of items",
didn't I?
What troubles me the most is that you seem to be forgetting that we are
using git to manage our codebase. Even if this turns out to be something
we would want to handle ourselves, it does not have to come from me. If
you care that much, you could backport whatever change is appropriate to
keep 1.4.4.X codebase alive and arrange it to be published as 1.4.4.5.
In any case, it will _definitely_ *NOT* a few minutes of me nor anybody.
Release engineering takes quite a lot of time.
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:44:57
Hi,
On Tue, 15 Jul 2008, Junio C Hamano wrote:
What troubles me the most is that you seem to be forgetting that we are
using git to manage our codebase.
I don't. I have vivid memories of updating an ancient git repository of
Git itself, which had some almost forgotten changes in it. That was in
the bad old days, when the version number did not even have a "1" in it.
It could not even fetch the current git.git.
I do _not_ want that to happen to anybody else, _even if_ we leave 1.4.4.4
Behind as if it was an American Child.
Having said that, I do not have the resources to test and fix everything
that may arise from Debian being seemingly unable to update to Git 1.5.
So I agree completely that the ball is in Debian's half, and if they let
it rot, it is sad, but I cannot help it.
Ciao,
Dscho