{"thread":{"id":"28433","subject":"upgrading GIT from version 1.7.0.4 to 1.7.6.1.","startedAt":"2011-09-19T12:30:30Z","lastAt":"2011-09-19T22:44:49Z","messageCount":7,"participants":["Mikaël","Sverre Rabbelier","Andreas Ericsson","Jakub Narebski","Jeff King","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"175782","messageId":"1316435430491-6808156.post@n2.nabble.com","threadId":"28433","inReplyTo":null,"subject":"upgrading GIT from version 1.7.0.4 to 1.7.6.1.","fromName":"Mikaël","fromEmail":"mikael.donini@gmail.com","sentAt":"2011-09-19T12:30:30Z","receivedAt":"2011-09-19T12:30:30Z","isPatch":false,"sender":{"key":"mikael.donini@gmail.com","avatar":null},"body":"Dear All,\n\nI am working for a company where several hundreds of people are working with\nGIT ; in other words, GIT is a central tool for us since our working\nprocesses are based on it.\n\nToday, it is the time for us to upgrade from version 1.7.0.4 to 1.7.6.1 (the\nlatest stable).\nIt is important for us to work with the latest version since it corrects\ndefects that are very impacting for us.\n\nThe difficulty of this migration is that we can't afford migrations problems\n(in order to maintain productivity and work).\n\nThat is the reason why I have a couple of questions:\n\n1- Is it possible to have two GIT installations pointing on the same\nrepositories? \n\nOne of this installation would be GIT 1.7.6.1 used by a restricted number of\npeople (these people could be called 'beta-testers' of the new GIT version).\nThe other installation would be GIT 1.7.0.4 used by the other users (the\nmajority of users) with no impact on their productivity.\n\nOnce the beta-tests will be finished and successful, all the users will move\nto GIT 1.7.6.1.\n\n2- Do you have any suggestions, trips, hints and best practices in order to\nupgrade GIT in such a context?\n\nThanks a lot for your answers.\n\nBest Regards,\n\nMikaël Donini.\n\n--\nView 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\nSent from the git mailing list archive at Nabble.com.\n"},{"id":"175783","messageId":"CAGdFq_hqEtnQvRbzr25yGDjwA6UCGhtofj+io7bX+xAkKqYYmQ@mail.gmail.com","threadId":"28433","inReplyTo":"1316435430491-6808156.post@n2.nabble.com","subject":"Re: upgrading GIT from version 1.7.0.4 to 1.7.6.1.","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2011-09-19T12:43:24Z","receivedAt":"2011-09-19T12:43:24Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Mon, Sep 19, 2011 at 14:30, Mikaël <mikael.donini@gmail.com> wrote:\n> 1- Is it possible to have two GIT installations pointing on the same\n> repositories?\n\nYes, knowing how deeply Junio cares about backwards compatability,\nthere will have been no backwards-incompatible changes to the\nrepository format (none at all actually, IIRC) since 1.7.0 was\nreleased.\n\n> 2- Do you have any suggestions, trips, hints and best practices in order to\n> upgrade GIT in such a context?\n\nYou should read the following documents that are in git.git:\n\nDocumentation/RelNotes/1.7.1.txt\nDocumentation/RelNotes/1.7.2.txt\nDocumentation/RelNotes/1.7.3.txt\nDocumentation/RelNotes/1.7.4.txt\nDocumentation/RelNotes/1.7.5.txt\nDocumentation/RelNotes/1.7.6.txt\n\nAnd make sure that none of the changes mentioned there will affect you\nnegatively.\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"175784","messageId":"4E773A71.6020905@op5.se","threadId":"28433","inReplyTo":"1316435430491-6808156.post@n2.nabble.com","subject":"Re: upgrading GIT from version 1.7.0.4 to 1.7.6.1.","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2011-09-19T12:49:53Z","receivedAt":"2011-09-19T12:49:53Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"On 09/19/2011 02:30 PM, Mikaël wrote:\n> \n> 1- Is it possible to have two GIT installations pointing on the same \n> repositories?\n> \n\nThe core structure and layout of a git repository hasn't changed\nsince may 2005, so it should work just fine provided you use any\ngit version that actually has a version number.\n\nWe've upgraded in a hodge-podge fashion at $dayjob. One of our\nservers is still running 1.4.something. We've never even come close\nto anything resembling a problem. It's actually a bit weird, since\nwe started using git in late 2005 and it's so far been the most\nreliable and backwards-compatible piece of software we have in the\ncompany pretty much ever since.\n\n> \n> 2- Do you have any suggestions, trips, hints and best practices in\n> order to upgrade GIT in such a context?\n> \n\nSince you have such high demands on problem-free migration, I suggest\nsetting up a repo server running the new git (on the server side) and\nhaving some people test against the new git with both old and new git,\nas well as testing new git against the old servers.\n\nJust get a backup first. I'm 99.9999999999999% sure you won't need it\nbecause of anything git does, but better safe than sorry, eh?\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"},{"id":"175785","messageId":"m3d3ewsnei.fsf@localhost.localdomain","threadId":"28433","inReplyTo":"1316435430491-6808156.post@n2.nabble.com","subject":"Re: upgrading GIT from version 1.7.0.4 to 1.7.6.1.","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2011-09-19T12:55:02Z","receivedAt":"2011-09-19T12:55:02Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Mikaël <mikael.donini@gmail.com> writes:\n\n> Today, it is the time for us to upgrade from version 1.7.0.4 to\n> 1.7.6.1 (the latest stable).  It is important for us to work with\n> the latest version since it corrects defects that are very impacting\n> for us.\n> \n> The difficulty of this migration is that we can't afford migrations problems\n> (in order to maintain productivity and work).\n> \n> That is the reason why I have a couple of questions:\n> \n> 1- Is it possible to have two GIT installations pointing on the same\n> repositories? \n> \n> One of this installation would be GIT 1.7.6.1 used by a restricted number of\n> people (these people could be called 'beta-testers' of the new GIT version).\n> The other installation would be GIT 1.7.0.4 used by the other users (the\n> majority of users) with no impact on their productivity.\n> \n> Once the beta-tests will be finished and successful, all the users will move\n> to GIT 1.7.6.1.\n\nGit is forward and backward compatibile, meaning that old clients can\nconnect to new servers (perhaps not using new features), and new\nclients can connect to old servers.\n\nThe exceptions are few (submodules, packed refs), are always announced\nlong in advance, with a long transition period: first a configuration\nvariable is added to switch to new incompatibile behavior defaulting\nto old behavior, only after a time there is switch to new improved\nincompatibile version.\n\n-- \nJakub Narębski\n"},{"id":"175795","messageId":"20110919190023.GC26115@sigill.intra.peff.net","threadId":"28433","inReplyTo":"4E773A71.6020905@op5.se","subject":"Re: upgrading GIT from version 1.7.0.4 to 1.7.6.1.","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-09-19T19:00:23Z","receivedAt":"2011-09-19T19:00:23Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Sep 19, 2011 at 02:49:53PM +0200, Andreas Ericsson wrote:\n\n> On 09/19/2011 02:30 PM, Mikaël wrote:\n> > \n> > 1- Is it possible to have two GIT installations pointing on the same \n> > repositories?\n> > \n> \n> The core structure and layout of a git repository hasn't changed\n> since may 2005, so it should work just fine provided you use any\n> git version that actually has a version number.\n> \n> We've upgraded in a hodge-podge fashion at $dayjob. One of our\n> servers is still running 1.4.something. We've never even come close\n> to anything resembling a problem. It's actually a bit weird, since\n> we started using git in late 2005 and it's so far been the most\n> reliable and backwards-compatible piece of software we have in the\n> company pretty much ever since.\n\nThis is not completely true. Any two versions should be able to\ninteroperate over the network using the git:// protocol. However, the\ndisk format has changed slightly over time.\n\nSince v1.6.0 (August 2008), git defaults to using delta base offsets in\npackfiles and version 2 of the pack index format. These features are not\nunderstood by versions before v1.5.2 (May 2007) or v1.4.4.5 (July 2008).\nA very old git accessing those repositories directly on disk (or by a\ndumb protocol like rsync or non-smart http) would have problems[1].\n\nSo it has happened[2], but it's important to note that:\n\n  1. We waited a year to flip the default for the code supporting it to\n     become more pervasive.\n\n  2. The switch happened on a major version boundary (1.5 -> 1.6),\n     was already supported by versions in the prior major series (1.5),\n     and we released a maintenance version for the series before that\n     (1.4.4.x).\n\n  3. The change, along with the affected versions, was mentioned\n     prominently in the 1.6.0 release notes.\n\nSo no, I wouldn't expect any disk format issues moving from v1.7.0.4 to\nv1.7.6.1. But it never hurts to read the release notes if you're unsure.\n\n-Peff\n\n[1] I do very occasionally run into this while bisecting some ancient\n    code on a modern repository.\n\n[2] I suspect a similar thing happened with turning on packed refs\n    (around the v1.4.4 era?), but I didn't dig around for details.\n"},{"id":"175813","messageId":"7vwrd48bq8.fsf@alter.siamese.dyndns.org","threadId":"28433","inReplyTo":"20110919190023.GC26115@sigill.intra.peff.net","subject":"Re: upgrading GIT from version 1.7.0.4 to 1.7.6.1.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-09-19T21:26:55Z","receivedAt":"2011-09-19T21:26:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> [2] I suspect a similar thing happened with turning on packed refs\n>     (around the v1.4.4 era?), but I didn't dig around for details.\n\nAlso when bisecting down to really ancient versions of git, you may get\ncomplaints from the configuration reader. E.g.\n\n    $ rungit v1.0.0 ls-files\n    fatal: bad config file line 78 in .git/config\n    $ sed -n 78p .git/config\n    [remote \"git-gui\"]\n"},{"id":"175821","messageId":"20110919224449.GC4056@sigill.intra.peff.net","threadId":"28433","inReplyTo":"7vwrd48bq8.fsf@alter.siamese.dyndns.org","subject":"Re: upgrading GIT from version 1.7.0.4 to 1.7.6.1.","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-09-19T22:44:49Z","receivedAt":"2011-09-19T22:44:49Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Sep 19, 2011 at 02:26:55PM -0700, Junio C Hamano wrote:\n\n> Jeff King <peff@peff.net> writes:\n> \n> > [2] I suspect a similar thing happened with turning on packed refs\n> >     (around the v1.4.4 era?), but I didn't dig around for details.\n> \n> Also when bisecting down to really ancient versions of git, you may get\n> complaints from the configuration reader. E.g.\n> \n>     $ rungit v1.0.0 ls-files\n>     fatal: bad config file line 78 in .git/config\n>     $ sed -n 78p .git/config\n>     [remote \"git-gui\"]\n\nUgh, yeah. There are similar problems with some specific config options\n(one I run into a lot these days is that \"pager.foo\" used to complain if\nthe value was non-boolean, but now you can put in an arbitrary command).\nBut those only bite you if you start using the new config options (which\nyou obviously are not doing until after you upgrade).\n\nBut your example will bite anyone because git generates remote config\nlike that by default.\n\nAnyway, most of that is only applicable if you are crossing several\nmajor version boundaries, or are using ancient versions of git. I'm\npretty sure that v1.7.0.x -> v1.7.6.x is pretty safe.\n\n-Peff\n"}]}