From: Jeff King <peff@peff.net>
To: Andreas Ericsson <ae@op5.se>
Cc: Mikaël <mikael.donini@gmail.com>, git@vger.kernel.org
Subject: Re: upgrading GIT from version 1.7.0.4 to 1.7.6.1.
Date: Mon, 19 Sep 2011 15:00:23 -0400 [thread overview]
Message-ID: <20110919190023.GC26115@sigill.intra.peff.net> (raw)
In-Reply-To: <4E773A71.6020905@op5.se>
On Mon, Sep 19, 2011 at 02:49:53PM +0200, Andreas Ericsson wrote:
> On 09/19/2011 02:30 PM, Mikaël wrote:
> >
> > 1- Is it possible to have two GIT installations pointing on the same
> > repositories?
> >
>
> The core structure and layout of a git repository hasn't changed
> since may 2005, so it should work just fine provided you use any
> git version that actually has a version number.
>
> We've upgraded in a hodge-podge fashion at $dayjob. One of our
> servers is still running 1.4.something. We've never even come close
> to anything resembling a problem. It's actually a bit weird, since
> we started using git in late 2005 and it's so far been the most
> reliable and backwards-compatible piece of software we have in the
> company pretty much ever since.
This is not completely true. Any two versions should be able to
interoperate over the network using the git:// protocol. However, the
disk format has changed slightly over time.
Since v1.6.0 (August 2008), git defaults to using delta base offsets in
packfiles and version 2 of the pack index format. These features are not
understood by versions before v1.5.2 (May 2007) or v1.4.4.5 (July 2008).
A very old git accessing those repositories directly on disk (or by a
dumb protocol like rsync or non-smart http) would have problems[1].
So it has happened[2], but it's important to note that:
1. We waited a year to flip the default for the code supporting it to
become more pervasive.
2. The switch happened on a major version boundary (1.5 -> 1.6),
was already supported by versions in the prior major series (1.5),
and we released a maintenance version for the series before that
(1.4.4.x).
3. The change, along with the affected versions, was mentioned
prominently in the 1.6.0 release notes.
So no, I wouldn't expect any disk format issues moving from v1.7.0.4 to
v1.7.6.1. But it never hurts to read the release notes if you're unsure.
-Peff
[1] I do very occasionally run into this while bisecting some ancient
code on a modern repository.
[2] I suspect a similar thing happened with turning on packed refs
(around the v1.4.4 era?), but I didn't dig around for details.
next prev parent reply other threads:[~2011-09-19 19:00 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-19 12:30 upgrading GIT from version 1.7.0.4 to 1.7.6.1 Mikaël
2011-09-19 12:43 ` Sverre Rabbelier
2011-09-19 12:49 ` Andreas Ericsson
2011-09-19 19:00 ` Jeff King [this message]
2011-09-19 21:26 ` Junio C Hamano
2011-09-19 22:44 ` Jeff King
2011-09-19 12:55 ` Jakub Narebski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110919190023.GC26115@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=ae@op5.se \
--cc=git@vger.kernel.org \
--cc=mikael.donini@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).