{"thread":{"id":"1012","subject":"[RFC] Order of push/pull file transfers","startedAt":"2005-06-23T10:12:55Z","lastAt":"2005-06-24T16:38:43Z","messageCount":2,"participants":["Russell King","Daniel Barkalow"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"5181","messageId":"20050623111255.A1162@flint.arm.linux.org.uk","threadId":"1012","inReplyTo":null,"subject":"[RFC] Order of push/pull file transfers","fromName":"Russell King","fromEmail":"rmk@arm.linux.org.uk","sentAt":"2005-06-23T10:12:55Z","receivedAt":"2005-06-23T10:12:55Z","isPatch":false,"sender":{"key":"rmk@arm.linux.org.uk","avatar":null},"body":"Hi,\n\nI'd like to start a discussion on the ordering of the various git files\nbeing transferred.\n\nLast night, I pulled Linus' kernel tree from k.o, but Linus was in the\nmiddle of pushing an update to it.  The way cogito works, it grabs the\nHEAD first, and then rsyncs the objects.\n\nHowever, this retrieved the updated HEAD, and only some of the objects.\ncogito happily tried to merge the result, and failed.  A later pull\nand git-fsck-cache confirmed everything was fine _in this instance_.\n\nTherefore, may I suggest the following two changes in the way git\nworks:\n\n1. a push updates HEAD only after the rsync/upload of all objects is\n   complete.  This means that any pull will not try to update to the\n   new head with a partial object tree.\n\n2. a pull only tries to fetch objects if HEAD has been updated since\n   the last pull.\n\nThis gives a pull-er an additional safety margin which ensures that\nmerges will not be attempted when a simultaneous pull and push occurs\nat the same time.\n\n-- \nRussell King\n\n"},{"id":"5231","messageId":"Pine.LNX.4.21.0506241219140.30848-100000@iabervon.org","threadId":"1012","inReplyTo":"20050623111255.A1162@flint.arm.linux.org.uk","subject":"Re: [RFC] Order of push/pull file transfers","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-06-24T16:38:43Z","receivedAt":"2005-06-24T16:38:43Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Thu, 23 Jun 2005, Russell King wrote:\n\n> Last night, I pulled Linus' kernel tree from k.o, but Linus was in the\n> middle of pushing an update to it.  The way cogito works, it grabs the\n> HEAD first, and then rsyncs the objects.\n\nIt needs to do this, in case HEAD changes after or during the rsync (to\ninclude objects written after the rsync looked for them).\n\n> However, this retrieved the updated HEAD, and only some of the objects.\n> cogito happily tried to merge the result, and failed.  A later pull\n> and git-fsck-cache confirmed everything was fine _in this instance_.\n\nIt should be fine in all instances; it makes no assuptions about the\npresence or absence of objects in the local database before the pull, so\ndoing a pull after the previous one didn't work right should be just as\nlikely to result in a functional state as any other pull.\n\n> Therefore, may I suggest the following two changes in the way git\n> works:\n> \n> 1. a push updates HEAD only after the rsync/upload of all objects is\n>    complete.  This means that any pull will not try to update to the\n>    new head with a partial object tree.\n\ngit-ssh-push only updates the HEAD (or, rather, the thing the HEAD is a\nsymlink to) afterwards. I'm not sure how Linus was getting things\nthere. It's also possible that the mirroring process is failing to\nmaintain this constraint.\n\n> 2. a pull only tries to fetch objects if HEAD has been updated since\n>    the last pull.\n\nThat's no good; if the only recent change is a new tag, you want to get \nthe tag object. Also, having it not do this is what let it recover in your\ncase on the second try. The only risk is that you'll pick up some objects\nthat you don't need yet (but would need if you pulled again when the push\ncompletes).\n\n\t-Daniel\n*This .sig left intentionally blank*\n\n"}]}