upgrading GIT from version 1.7.0.4 to 1.7.6.1.

Dear All,

I am working for a company where several hundreds of people are working with GIT ; in other words, GIT is a central tool for us since our working processes are based on it.

Today, it is the time for us to upgrade from version 1.7.0.4 to 1.7.6.1 (the latest stable). It is important for us to work with the latest version since it corrects defects that are very impacting for us.

The difficulty of this migration is that we can't afford migrations problems (in order to maintain productivity and work).

That is the reason why I have a couple of questions:

1- Is it possible to have two GIT installations pointing on the same repositories?

One of this installation would be GIT 1.7.6.1 used by a restricted number of people (these people could be called 'beta-testers' of the new GIT version). The other installation would be GIT 1.7.0.4 used by the other users (the majority of users) with no impact on their productivity.

Once the beta-tests will be finished and successful, all the users will move to GIT 1.7.6.1.

2- Do you have any suggestions, trips, hints and best practices in order to upgrade GIT in such a context?

Thanks a lot for your answers.

Best Regards,

Mikaël Donini.

-- View this message in context: http://git.661346.n2.nabble.com/upgrading-GIT-from-version-1-7-0-4-to-1-7-6-1-tp6808156p6808156.html Sent from the git mailing list archive at Nabble.com.

Heya,

On Mon, Sep 19, 2011 at 14:30, Mikaël <mikael.donini@gmail.com> wrote:

Yes, knowing how deeply Junio cares about backwards compatability, there will have been no backwards-incompatible changes to the repository format (none at all actually, IIRC) since 1.7.0 was released.

You should read the following documents that are in git.git:

Documentation/RelNotes/1.7.1.txt Documentation/RelNotes/1.7.2.txt Documentation/RelNotes/1.7.3.txt Documentation/RelNotes/1.7.4.txt Documentation/RelNotes/1.7.5.txt Documentation/RelNotes/1.7.6.txt

And make sure that none of the changes mentioned there will affect you negatively.

On 09/19/2011 02:30 PM, Mikaël wrote:

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.

Since you have such high demands on problem-free migration, I suggest setting up a repo server running the new git (on the server side) and having some people test against the new git with both old and new git, as well as testing new git against the old servers.

Just get a backup first. I'm 99.9999999999999% sure you won't need it because of anything git does, but better safe than sorry, eh?

On Mon, Sep 19, 2011 at 02:49:53PM +0200, Andreas Ericsson wrote:

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.

Jeff King <peff@peff.net> writes:

Also when bisecting down to really ancient versions of git, you may get complaints from the configuration reader. E.g.

    $ rungit v1.0.0 ls-files
    fatal: bad config file line 78 in .git/config
    $ sed -n 78p .git/config
    [remote "git-gui"]

On Mon, Sep 19, 2011 at 02:26:55PM -0700, Junio C Hamano wrote:

Ugh, yeah. There are similar problems with some specific config options (one I run into a lot these days is that "pager.foo" used to complain if the value was non-boolean, but now you can put in an arbitrary command). But those only bite you if you start using the new config options (which you obviously are not doing until after you upgrade).

But your example will bite anyone because git generates remote config like that by default.

Anyway, most of that is only applicable if you are crossing several major version boundaries, or are using ancient versions of git. I'm pretty sure that v1.7.0.x -> v1.7.6.x is pretty safe.

-Peff

Mikaël <mikael.donini@gmail.com> writes:

Git is forward and backward compatibile, meaning that old clients can connect to new servers (perhaps not using new features), and new clients can connect to old servers.

The exceptions are few (submodules, packed refs), are always announced long in advance, with a long transition period: first a configuration variable is added to switch to new incompatibile behavior defaulting to old behavior, only after a time there is switch to new improved incompatibile version.