{"thread":{"id":"2194","subject":"[PATCH 0/4] Spend more effort in git-fetch-pack finding common revisions","startedAt":"2005-10-23T01:35:26Z","lastAt":"2005-10-23T01:35:26Z","messageCount":1,"participants":["Johannes Schindelin"],"isPatch":true,"patchVersion":1,"patchTotal":4},"messages":[{"id":"10474","messageId":"Pine.LNX.4.63.0510230334410.21239@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"2194","inReplyTo":null,"subject":"[PATCH 0/4] Spend more effort in git-fetch-pack finding common revisions","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-10-23T01:35:26Z","receivedAt":"2005-10-23T01:35:26Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"This series of 4 patches extends the fetch-pack/upload-pack protocol such\nthat more than just one common revision is used to find out which objects\nare needed by the client.\n\nThis means that the client spends more time on enumerating candidates, and\nthe server just acknowledges those it knows about. That is done until the\nclient runs out of candidates, or the server got HAS_MAX common revisions.\n\nWhile it does not make much of a difference when you are tracking one linear\nbranch on one repository, this change should make it more efficient (and\nalso ease the burden on the server) to work with several repositories having\nseveral branches, and intertwined development.\n\nNext thing I'll do is write some nasty test cases.\n\nFlame on,\nDscho\n"}]}