Nicolas Pitre <nico@xxxxxxx> writes:
> On Fri, 14 Dec 2007, Joel Becker wrote:
>
>> > Could you please give me a reference to such message, so to verify that
>> > we're actually talking about the same thing?
>>
>> The relevant message is:
>>
>> Message-ID: <7vveaindgp.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx>
>>
>> See the paragraphs at the bottom. The thread, started by me, begins
>> with:
>>
>> Message-ID: <20070910205429.GE27837@xxxxxxxxxx>
>
> I don't have such emails in my mail folders anymore.
-- >8 --
Date: Mon, 10 Sep 2007 13:54:29 -0700
From: Joel Becker <Joel.Becker@xxxxxxxxxx>
To: git@xxxxxxxxxxxxxxx
Subject: Remote branches and better documentation
Message-ID: <20070910205429.GE27837@xxxxxxxxxx>
Sender: git-owner@xxxxxxxxxxxxxxx
Junio et al,
Git is a fast moving target, so some of this obviously needs a
grain of salt. However, I'd like to make a couple of humble suggestions
and ask one simple question.
First, the question: Is there a syntax to git clone that
creates the old-style branches? That is, you get all the branches
locally, for people that either haven't learned "git branch -r" or have
existing scripts that expect the branch to exist? I can't find anything
in the git clone manpage.
The suggestions are pretty simple. First, when behavior is
changed invisibly (as the remote branch stuff was), can we note it in
the documentation? I don't mean the ChangeLog, I mean the manpage. I
personally already knew about "branch -r" because I read this list. A
coworker of mine, who just uses git, spent an hour trying to find his
branches after a clone with git 1.5. He thought his clone had failed.
He read the manpage, and there was no big "Hey, those of you used to
the old behavior, it changed!". The single sentence about "remote
tracking branches" clearly isn't enough for folks that don't follow the
development side. If we're going to take the liberty of changing
expected behavior silently, we should be giving it its own section in
the manpage.
The second suggestion is related. When an invisible change has
made the repository incompatible with older versions, we should make
sure that things behave. We had some repositories cloned via 1.4.2. Do
some work with 1.5.0.6 (on a different machine), then go back to the
machine with 1.4.2, and 1.4.2 doesn't work. In fact, it can mess things
up. He was doing simple things: pull from Linus, switch branches, etc.
If this is going to be incompatible, then the newer stuff should at
least warn about it, if not outright prevent 1.4 from running.
These sorts of things make fast-moving changes workable.
Joel
-- >8 --
Date: Mon, 10 Sep 2007 19:27:34 -0700
Message-ID: <7vveaindgp.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: git-owner@xxxxxxxxxxxxxxx
Joel Becker <Joel.Becker@xxxxxxxxxx> writes:
> On Tue, Sep 11, 2007 at 02:05:34AM +0200, Wincent Colaiuta wrote:
>> But that's precisely the group release notes are for; existing users who
>> need to be informed of any changes to the way things work.
>
> No one reads the changelogs of 100 packages updated via "yum
> update". Heck, they don't even see the list of packages. They just
> switch to a different desktop while it runs.
Distros are not something under my control, so I cannot help you
much there.
> Then there's the user that doesn't administer the system. They
> don't even know the version changed. It Just Breaks, and they don't
> know why.
That's a valid concern, but I am not sure how you would want to
address that issue. Design constraints are:
- you cannot change the old software that is not updated on the
user's box;
- you cannot afford to write something to the repository to
mark the latest version that mucked with the repository every
time any operation happens;
We _could_ check presence of $HOME/.knows-git-version-X.Y.Z file
every time we run (that's just a single stat(2) call that cannot
be too expensive) and if there isn't one, ask the user if he has
read the release notes and understood the backward compatibility
issues if there is any, and refuse to run until getting a
satisfactory answer.
But I personally do not think that would be an improvement.
After reviewing Release Notes for v1.5.0, I do not think we
could have done much better, unfortunately.
As of git v1.5.0 there are some optional features that changes
the repository to allow data to be stored and transferred more
efficiently. These features are not enabled by default, as they
will make the repository unusable with older versions of git.
Specifically, the available options are:
- There is a configuration variable core.legacyheaders that
changes the format of loose objects so that they are more
efficient to pack and to send out of the repository over git
native protocol, since v1.4.2. However, loose objects
written in the new format cannot be read by git older than
that version; people fetching from your repository using
older clients over dumb transports (e.g. http) using older
versions of git will also be affected.
To let git use the new loose object format, you have to
set core.legacyheaders to false.
- Since v1.4.3, configuration repack.usedeltabaseoffset allows
packfile to be created in more space efficient format, which
cannot be read by git older than that version.
To let git use the new format for packfiles, you have to
set repack.usedeltabaseoffset to true.
The above two new features are not enabled by default and you
have to explicitly ask for them, because they make repositories
unreadable by older versions of git, and in v1.5.0 we still do
not enable them by default for the same reason. We will change
this default probably 1 year after 1.4.2's release, when it is
reasonable to expect everybody to have new enough version of
git.
- 'git pack-refs' appeared in v1.4.4; this command allows tags
to be accessed much more efficiently than the traditional
'one-file-per-tag' format. Older git-native clients can
still fetch from a repository that packed and pruned refs
(the server side needs to run the up-to-date version of git),
but older dumb transports cannot. Packing of refs is done by
an explicit user action, either by use of "git pack-refs
--prune" command or by use of "git gc" command.
So everything was opt in and clearly marked as such. You may
not have read it, distros may not have shown it, but then that
is something we cannot do much about, unfortunately.
I think there was _one_ honest slippage though. Fetching from
1.5.0 peer by 1.5.0 client could (after doing content
negotiation between both ends as a protection measure) create a
packfile that cannot be read by older 1.4 clients. Obviously
you cannot expect that kind of "protection" to work across set
of machines with mixed versions sharing a repository over NFS,
and that probably is a mistake we can learn from.
-
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
