{"thread":{"id":"22152","subject":"How to check new commit availability without full fetch?","startedAt":"2010-01-10T11:12:09Z","lastAt":"2010-01-11T20:52:04Z","messageCount":20,"participants":["Leo Razoumov","Nicolas Pitre","Junio C Hamano","Tay Ray Chuan","Michael Witten","Dmitry Potapov","Robin Rosenberg","Andreas Schwab"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"131217","messageId":"ee2a733e1001100312j786108fct1b4c8abd0acc5afc@mail.gmail.com","threadId":"22152","inReplyTo":null,"subject":"How to check new commit availability without full fetch?","fromName":"Leo Razoumov","fromEmail":"slonik.az@gmail.com","sentAt":"2010-01-10T11:12:09Z","receivedAt":"2010-01-10T11:12:09Z","isPatch":false,"sender":{"key":"slonik.az@gmail.com","avatar":null},"body":"Hi List,\nI am trying to find a way to check availability of new commits\n*before* doing fetch or pull. Unfortunately, neither fetch nor pull\ntake \"--dry-run\" option (unlike push)\nI am sure I am not the only one with such an itch.\n\nAny help and advice are greatly appreciated.\n\n--Leo--\n"},{"id":"131237","messageId":"alpine.LFD.2.00.1001101501520.10143@xanadu.home","threadId":"22152","inReplyTo":"ee2a733e1001100312j786108fct1b4c8abd0acc5afc@mail.gmail.com","subject":"Re: How to check new commit availability without full fetch?","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2010-01-10T20:13:49Z","receivedAt":"2010-01-10T20:13:49Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Sun, 10 Jan 2010, Leo Razoumov wrote:\n\n> Hi List,\n> I am trying to find a way to check availability of new commits\n> *before* doing fetch or pull. Unfortunately, neither fetch nor pull\n> take \"--dry-run\" option (unlike push)\n\nBut... _Why_ do you want/need to do that?\n\nYou could use ls-remote to see what the remote branch is pointing to, \ne.g.:\n\n\tgit ls-remote origin master\n\nand compare with the local view of that remote branch:\n\n\tgit show-ref origin/master\n\nAnd if both SHA1 strings match then there is nothing new to fetch.\n\n> I am sure I am not the only one with such an itch.\n\nMaybe you are. There is very little point knowing that the remote repo \nhas new commits if you're not going to fetch them, so I don't understand \nwhy you need this.\n\n\nNicolas\n"},{"id":"131239","messageId":"7v8wc5itlc.fsf@alter.siamese.dyndns.org","threadId":"22152","inReplyTo":"alpine.LFD.2.00.1001101501520.10143@xanadu.home","subject":"Re: How to check new commit availability without full fetch?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-01-10T20:38:07Z","receivedAt":"2010-01-10T20:38:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n>> I am sure I am not the only one with such an itch.\n>\n> Maybe you are. There is very little point knowing that the remote repo \n> has new commits if you're not going to fetch them, so I don't understand \n> why you need this.\n\nA feel good factor is in play? IOW, \"I am short of time, so I won't be\nable to really afford to 'git pull' and test the result of re-integrating\nmy changes to what happened on the other end. If I can learn that there\nis nothing happening over there, then I won't have to do anything and know\nthat I am up to date.\"\n"},{"id":"131240","messageId":"alpine.LFD.2.00.1001101556490.10143@xanadu.home","threadId":"22152","inReplyTo":"7v8wc5itlc.fsf@alter.siamese.dyndns.org","subject":"Re: How to check new commit availability without full fetch?","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2010-01-10T21:05:41Z","receivedAt":"2010-01-10T21:05:41Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Sun, 10 Jan 2010, Junio C Hamano wrote:\n\n> Nicolas Pitre writes:\n> \n> >> I am sure I am not the only one with such an itch.\n> >\n> > Maybe you are. There is very little point knowing that the remote repo \n> > has new commits if you're not going to fetch them, so I don't understand \n> > why you need this.\n> \n> A feel good factor is in play? IOW, \"I am short of time, so I won't be\n> able to really afford to 'git pull' and test the result of re-integrating\n> my changes to what happened on the other end. If I can learn that there\n> is nothing happening over there, then I won't have to do anything and know\n> that I am up to date.\"\n\nJust do a fetch then. If the fetch progress display looks like if it is \ngoing to take a while then just interrupt it and go home. If the fetch \nlooks trivial then just merge it. In any case, the \"feel good\" factor \ncan't be that great by only knowing if the remote has changed or not. \n\nWell maybe if it hasn't changed then you know right away how to feel \nabout it (equally with a fetch in that case), and if the remote is \nindeed different then you can't tell whether the changes are trivial or \nnot without actually fetching them.\n\n\nNicolas\n"},{"id":"131244","messageId":"ee2a733e1001101736p2f395de6ka05044fe7cca624d@mail.gmail.com","threadId":"22152","inReplyTo":"alpine.LFD.2.00.1001101556490.10143@xanadu.home","subject":"Re: How to check new commit availability without full fetch?","fromName":"Leo Razoumov","fromEmail":"slonik.az@gmail.com","sentAt":"2010-01-11T01:36:44Z","receivedAt":"2010-01-11T01:36:44Z","isPatch":false,"sender":{"key":"slonik.az@gmail.com","avatar":null},"body":"On 2010-01-10, Nicolas Pitre wrote:\n> On Sun, 10 Jan 2010, Junio C Hamano wrote:\n> >\n> > A feel good factor is in play? IOW, \"I am short of time, so I won't be\n> > able to really afford to 'git pull' and test the result of re-integrating\n> > my changes to what happened on the other end. If I can learn that there\n> > is nothing happening over there, then I won't have to do anything and know\n> > that I am up to date.\"\n>\n>\n> Just do a fetch then. If the fetch progress display looks like if it is\n> going to take a while then just interrupt it and go home. If the fetch\n> looks trivial then just merge it. In any case, the \"feel good\" factor\n> can't be that great by only knowing if the remote has changed or not.\n>\n\nForced interruption is not such a good idea. I would favor a\nnon-destructive way to monitor availability of remote commits.\n\nBTW, pull and push are in a way symmetric operations. Is there any\ndeep reason why push supports --dry-run but pull/fetch does not??\n\n--Leo--\n"},{"id":"131245","messageId":"be6fef0d1001101757w7f54c9b2ye58c66179137efb1@mail.gmail.com","threadId":"22152","inReplyTo":"ee2a733e1001101736p2f395de6ka05044fe7cca624d@mail.gmail.com","subject":"Re: How to check new commit availability without full fetch?","fromName":"Tay Ray Chuan","fromEmail":"rctay89@gmail.com","sentAt":"2010-01-11T01:57:51Z","receivedAt":"2010-01-11T01:57:51Z","isPatch":false,"sender":{"key":"rctay89@gmail.com","avatar":"https://avatars.githubusercontent.com/u/61553?v=4"},"body":"Hi,\n\nOn Mon, Jan 11, 2010 at 9:36 AM, Leo Razoumov wrote:\n> On 2010-01-10, Nicolas Pitre wrote:\n>> On Sun, 10 Jan 2010, Junio C Hamano wrote:\n>>  >\n>>  > A feel good factor is in play?  IOW, \"I am short of time, so I won't be\n>>  > able to really afford to 'git pull' and test the result of re-integrating\n>>  > my changes to what happened on the other end.  If I can learn that there\n>>  > is nothing happening over there, then I won't have to do anything and know\n>>  > that I am up to date.\"\n>>\n>>\n>> Just do a fetch then.  If the fetch progress display looks like if it is\n>>  going to take a while then just interrupt it and go home.  If the fetch\n>>  looks trivial then just merge it.  In any case, the \"feel good\" factor\n>>  can't be that great by only knowing if the remote has changed or not.\n>>\n>\n> Forced interruption is not such a good idea. I would favor a\n> non-destructive way to monitor availability of remote commits.\n\nBy default, when you add a remote (with git remote add), git sets up\nthe fetch refspec in your config that looks like\n\n [remote \"foo\"]\n url = git://foo.com/git/foo.git\n fetch = refs/heads/*:refs/remotes/foo/*\n\nThat is to say, branches on the remote repo will be fetched into a\n\"safe\" area, refs/remotes/foo/, away from the branches that you\nnormally work with in refs/heads/.\n\nHowever, if you have a different config and you're fetching directly\ninto refs/heads/, then I can see why you would want to \"peek\" first\nwith --dry-run before fetching. Are you doing this?\n\n> BTW, pull and push are in a way symmetric operations. Is there any\n> deep reason why push supports --dry-run but pull/fetch does not??\n\nIt's more accurate to say that push and fetch are symmetric, because\npull is fetch with merge or rebase tacked on.\n\nEven then, push and fetch are not _that_ symmetric...\n\n-- \nCheers,\nRay Chuan\n"},{"id":"131247","messageId":"alpine.LFD.2.00.1001102055070.10143@xanadu.home","threadId":"22152","inReplyTo":"ee2a733e1001101736p2f395de6ka05044fe7cca624d@mail.gmail.com","subject":"Re: How to check new commit availability without full fetch?","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2010-01-11T02:01:14Z","receivedAt":"2010-01-11T02:01:14Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Sun, 10 Jan 2010, Leo Razoumov wrote:\n\n> On 2010-01-10, Nicolas Pitre wrote:\n> > On Sun, 10 Jan 2010, Junio C Hamano wrote:\n> > >\n> > > A feel good factor is in play? IOW, \"I am short of time, so I won't be\n> > > able to really afford to 'git pull' and test the result of re-integrating\n> > > my changes to what happened on the other end. If I can learn that there\n> > > is nothing happening over there, then I won't have to do anything and know\n> > > that I am up to date.\"\n> >\n> >\n> > Just do a fetch then. If the fetch progress display looks like if it is\n> > going to take a while then just interrupt it and go home. If the fetch\n> > looks trivial then just merge it. In any case, the \"feel good\" factor\n> > can't be that great by only knowing if the remote has changed or not.\n> >\n> \n> Forced interruption is not such a good idea. I would favor a\n> non-destructive way to monitor availability of remote commits.\n\nYou still don't answer my question though. Again, _why_ do you need to \nknow about remote commit availability without fetching them?\n\n> BTW, pull and push are in a way symmetric operations. Is there any\n> deep reason why push supports --dry-run but pull/fetch does not??\n\nPushing involves resource usage on your own machine while \npulling/fetching involves the remote machine. Your choice to \"waste\" \nCPU cycles on your own machine is not the same as having anybody do the \nsame on a central server.\n\n\nNicolas\n"},{"id":"131248","messageId":"7vk4vpcs1q.fsf@alter.siamese.dyndns.org","threadId":"22152","inReplyTo":"be6fef0d1001101757w7f54c9b2ye58c66179137efb1@mail.gmail.com","subject":"Re: How to check new commit availability without full fetch?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-01-11T02:08:01Z","receivedAt":"2010-01-11T02:08:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Tay Ray Chuan writes:\n\n> By default, when you add a remote (with git remote add), git sets up\n> the fetch refspec in your config that looks like\n>\n> [remote \"foo\"]\n> url = git://foo.com/git/foo.git\n> fetch = refs/heads/*:refs/remotes/foo/*\n>\n> That is to say, branches on the remote repo will be fetched into a\n> \"safe\" area, refs/remotes/foo/, away from the branches that you\n> normally work with in refs/heads/.\n>\n> However, if you have a different config and you're fetching directly\n> into refs/heads/, then I can see why you would want to \"peek\" first\n> with --dry-run before fetching.\n\nI don't. Until all the objects are safely transferred, none of the refs\nare updated, whether they are directly slurped into local branch namespace\nor remote tracking branch namespace. So no matter what the configuration\nis, interrupted transfer, forced or otherwise, is safe.\n"},{"id":"131255","messageId":"b4087cc51001102129n5d5ac022s4f6f3ee9512eefd2@mail.gmail.com","threadId":"22152","inReplyTo":"7vk4vpcs1q.fsf@alter.siamese.dyndns.org","subject":"Re: How to check new commit availability without full fetch?","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2010-01-11T05:29:52Z","receivedAt":"2010-01-11T05:29:52Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Sun, Jan 10, 2010 at 8:08 PM, Junio C Hamano wrote:\n> Until all the objects are safely transferred, none of the refs\n> are updated, whether they are directly slurped into local branch namespace\n> or remote tracking branch namespace.  So no matter what the configuration\n> is, interrupted transfer, forced or otherwise, is safe.\n\nI suggest adding this kind of information to the fetch/pull (and I\nsuppose push) documentation.\n"},{"id":"131256","messageId":"20100111053815.GB10586@dpotapov.dyndns.org","threadId":"22152","inReplyTo":"ee2a733e1001101736p2f395de6ka05044fe7cca624d@mail.gmail.com","subject":"Re: How to check new commit availability without full fetch?","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2010-01-11T05:38:15Z","receivedAt":"2010-01-11T05:38:15Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Sun, Jan 10, 2010 at 08:36:44PM -0500, Leo Razoumov wrote:\n> \n> BTW, pull and push are in a way symmetric operations.\n\nNot really... 'pull' = 'fetch' + 'merge', while 'push' only propagates\nchanges without any merging. You can say 'fetch' and 'push' are in a way\nsymmetric operations, but this symmetry is limited due to difference in\nusage between local and remote branches.\n\n> Is there any\n> deep reason why push supports --dry-run but pull/fetch does not??\n\nI guess it is because no one needs it. 'push' has --dry-run, because\nit updates local references in a remote repository. So, you may want\nto be sure that you are pushing the right thing. On the other hand,\nI see no reason to have --dry-run for 'fetch', because it updates only\nremote references, making them to point to the current state of the\ncorresponding branches. 'fetch' does not change any local branch, so\nI see no reason for --dry-run.\n\nWhat use case do you have in mind that needs --dry-run for 'fetch'?\n\n\nDmitry\n"},{"id":"131259","messageId":"7vd41hxggd.fsf@alter.siamese.dyndns.org","threadId":"22152","inReplyTo":"b4087cc51001102129n5d5ac022s4f6f3ee9512eefd2@mail.gmail.com","subject":"Re: How to check new commit availability without full fetch?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-01-11T07:12:50Z","receivedAt":"2010-01-11T07:12:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Witten writes:\n\n> I suggest adding this kind of information to the fetch/pull (and I\n> suppose push) documentation.\n\nSounds good. Pleaes make it so.\n"},{"id":"131266","messageId":"201001110831.28278.robin.rosenberg@dewire.com","threadId":"22152","inReplyTo":"ee2a733e1001100312j786108fct1b4c8abd0acc5afc@mail.gmail.com","subject":"Re: How to check new commit availability without full fetch?","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg@dewire.com","sentAt":"2010-01-11T07:31:28Z","receivedAt":"2010-01-11T07:31:28Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"söndagen den 10 januari 2010 12.12.09 skrev Leo Razoumov:\n> Hi List,\n> I am trying to find a way to check availability of new commits\n> *before* doing fetch or pull. Unfortunately, neither fetch nor pull\n> take \"--dry-run\" option (unlike push)\n\nFetch has --dry-run. It's a fairly new option. The drawback is that it\nstill does the fetch, but it does not update the refs. If you re.run it\nagain it'll be quicker.\n\nA faster option is to use ls-remote, but you'll have to parse the data\nyourself and compare with your remote refs to see what refs has changed,\nand that will not tell you /what/ the changes are.\n\n-- robin\n"},{"id":"131267","messageId":"7vljg5ukol.fsf@alter.siamese.dyndns.org","threadId":"22152","inReplyTo":"201001110831.28278.robin.rosenberg@dewire.com","subject":"Re: How to check new commit availability without full fetch?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-01-11T08:09:46Z","receivedAt":"2010-01-11T08:09:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Robin Rosenberg writes:\n\n> söndagen den 10 januari 2010 12.12.09 skrev Leo Razoumov:\n>> Hi List,\n>> I am trying to find a way to check availability of new commits\n>> *before* doing fetch or pull. Unfortunately, neither fetch nor pull\n>> take \"--dry-run\" option (unlike push)\n>\n> Fetch has --dry-run. It's a fairly new option. The drawback is that it\n> still does the fetch, but it does not update the refs. If you re.run it\n> again it'll be quicker.\n\nDoesn't that worry us if it really is quicker?\n\nIf --dry-run doesn't update the refs, why do the objects that were\ntransferred by them not get asked the next time? There must be a bug\nsomewhere, but it is getting late already, so I'll leave it to experts in\nthe transfer area to figure it out...\n"},{"id":"131290","messageId":"ee2a733e1001110822t1b04c1ccg9b6eb5489b69783d@mail.gmail.com","threadId":"22152","inReplyTo":"alpine.LFD.2.00.1001102055070.10143@xanadu.home","subject":"Re: How to check new commit availability without full fetch?","fromName":"Leo Razoumov","fromEmail":"slonik.az@gmail.com","sentAt":"2010-01-11T16:22:21Z","receivedAt":"2010-01-11T16:22:21Z","isPatch":false,"sender":{"key":"slonik.az@gmail.com","avatar":null},"body":"On 2010-01-10, Nicolas Pitre wrote:\n>\n> You still don't answer my question though. Again, _why_ do you need to\n> know about remote commit availability without fetching them?\n>\n\nI use git to track almost all my data (code and otherwise) and spread\nit between several computers. I end up with several local repos having\nthe same local branches. It happens once in a while that I fetch into\na given remote/foo from several local foo branches from different\nmachines and the operation fails. It happens because the commits have\nnot been yet consistently distributed among the repos. To do the\nforensics and figure out who should update whom first I need a quick\nand non-destructive way to fetch dry-run.\n\n--Leo--\n"},{"id":"131295","messageId":"alpine.LFD.2.00.1001111149150.10143@xanadu.home","threadId":"22152","inReplyTo":"ee2a733e1001110822t1b04c1ccg9b6eb5489b69783d@mail.gmail.com","subject":"Re: How to check new commit availability without full fetch?","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2010-01-11T17:04:25Z","receivedAt":"2010-01-11T17:04:25Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 11 Jan 2010, Leo Razoumov wrote:\n\n> On 2010-01-10, Nicolas Pitre wrote:\n> >\n> > You still don't answer my question though. Again, _why_ do you need to\n> > know about remote commit availability without fetching them?\n> >\n> \n> I use git to track almost all my data (code and otherwise) and spread\n> it between several computers. I end up with several local repos having\n> the same local branches. It happens once in a while that I fetch into\n> a given remote/foo from several local foo branches from different\n> machines and the operation fails. It happens because the commits have\n> not been yet consistently distributed among the repos. To do the\n> forensics and figure out who should update whom first I need a quick\n> and non-destructive way to fetch dry-run.\n\nThere is probably something awkward about your setup then.\n\nNormally you should have a remote description for any of the remote \nrepositories you fetch from. So if you have, say, remote machine_a with \nrepo foo, machine_b with repo bar, and machine_c with repo baz, then \nfetching any of those will _only_ mirror locally the state of those \nremote repositories. There is no ordering required as there can't be \nany conflicts in the mere fact of mirroring what the other guys have. \nThat's what remote tracking branches are for: they follow the state of a \nremote repository and are never altered by local changes. And you can \nhave as many of those as you wish and they will never conflict with each \nother as each remote description is independent. And this is true \nwhether or not the remote repository lives on the same machine (that \nwould be a remote directory in that case).\n\nAnd even if most if not all those remotes are actually copies of each \nothers, then the first fetch to occur will transfer the new objects \nwhile fetching the other ones will simply notice that the required \nobjects are already available locally and only the ref will be updated.\n\nThe ordering comes into play when it is time to _merge_ those remote \nbranches into, say, the local master branch. That's why it is probably \na good thing to use fetch+merge instead of pull in this case. But this \nis then a local matter and nothing that depends on the fetch ordering.\n\n\nNicolas\n"},{"id":"131297","messageId":"ee2a733e1001110935h101e7ec9l1b4fcf2bf210f53f@mail.gmail.com","threadId":"22152","inReplyTo":"alpine.LFD.2.00.1001111149150.10143@xanadu.home","subject":"Re: How to check new commit availability without full fetch?","fromName":"Leo Razoumov","fromEmail":"slonik.az@gmail.com","sentAt":"2010-01-11T17:35:35Z","receivedAt":"2010-01-11T17:35:35Z","isPatch":false,"sender":{"key":"slonik.az@gmail.com","avatar":null},"body":"On 2010-01-11, Nicolas Pitre wrote:\n> On Mon, 11 Jan 2010, Leo Razoumov wrote:\n>\n> > On 2010-01-10, Nicolas Pitre wrote:\n> > >\n> > > You still don't answer my question though. Again, _why_ do you need to\n> > > know about remote commit availability without fetching them?\n> > >\n> >\n> > I use git to track almost all my data (code and otherwise) and spread\n> > it between several computers. I end up with several local repos having\n> > the same local branches. It happens once in a while that I fetch into\n> > a given remote/foo from several local foo branches from different\n> > machines and the operation fails. It happens because the commits have\n> > not been yet consistently distributed among the repos. To do the\n> > forensics and figure out who should update whom first I need a quick\n> > and non-destructive way to fetch dry-run.\n>\n>\n> There is probably something awkward about your setup then.\n>\n> Normally you should have a remote description for any of the remote\n> repositories you fetch from. So if you have, say, remote machine_a with\n> repo foo, machine_b with repo bar, and machine_c with repo baz, then\n> fetching any of those will _only_ mirror locally the state of those\n> remote repositories. There is no ordering required as there can't be\n> any conflicts in the mere fact of mirroring what the other guys have.\n> That's what remote tracking branches are for: they follow the state of a\n> remote repository and are never altered by local changes. And you can\n> have as many of those as you wish and they will never conflict with each\n> other as each remote description is independent. And this is true\n> whether or not the remote repository lives on the same machine (that\n> would be a remote directory in that case).\n>\n\nSetup might be, indeed, awkward but it handles very diverse tasks.\nAs I said in my earlier emails different repos fetch into the *same* remote/foo.\nSo there could be conflicts and using fetch -f could cause loss of data.\n\nBefore switching to git I used mercurial for the same purpose and it\nhas command that are equivalent to fetch --dry-run.\n\n--Leo--\n"},{"id":"131299","messageId":"alpine.LFD.2.00.1001111257300.10143@xanadu.home","threadId":"22152","inReplyTo":"7vljg5ukol.fsf@alter.siamese.dyndns.org","subject":"Re: How to check new commit availability without full fetch?","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2010-01-11T17:59:24Z","receivedAt":"2010-01-11T17:59:24Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 11 Jan 2010, Junio C Hamano wrote:\n\n> Robin Rosenberg writes:\n> \n> > söndagen den 10 januari 2010 12.12.09 skrev Leo Razoumov:\n> >> Hi List,\n> >> I am trying to find a way to check availability of new commits\n> >> *before* doing fetch or pull. Unfortunately, neither fetch nor pull\n> >> take \"--dry-run\" option (unlike push)\n> >\n> > Fetch has --dry-run. It's a fairly new option. The drawback is that it\n> > still does the fetch, but it does not update the refs. If you re.run it\n> > again it'll be quicker.\n> \n> Doesn't that worry us if it really is quicker?\n> \n> If --dry-run doesn't update the refs, why do the objects that were\n> transferred by them not get asked the next time? There must be a bug\n> somewhere, but it is getting late already, so I'll leave it to experts in\n> the transfer area to figure it out...\n\nWhat about builtin-fetch.c:quickfetch() ?\n\n\nNicolas\n"},{"id":"131305","messageId":"7vmy0kjvms.fsf@alter.siamese.dyndns.org","threadId":"22152","inReplyTo":"alpine.LFD.2.00.1001111257300.10143@xanadu.home","subject":"Re: How to check new commit availability without full fetch?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-01-11T19:20:59Z","receivedAt":"2010-01-11T19:20:59Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n> On Mon, 11 Jan 2010, Junio C Hamano wrote:\n>\n>> Robin Rosenberg writes:\n>> \n>> > söndagen den 10 januari 2010 12.12.09 skrev Leo Razoumov:\n>> >> Hi List,\n>> >> I am trying to find a way to check availability of new commits\n>> >> *before* doing fetch or pull. Unfortunately, neither fetch nor pull\n>> >> take \"--dry-run\" option (unlike push)\n>> >\n>> > Fetch has --dry-run. It's a fairly new option. The drawback is that it\n>> > still does the fetch, but it does not update the refs. If you re.run it\n>> > again it'll be quicker.\n>> \n>> Doesn't that worry us if it really is quicker?\n>> \n>> If --dry-run doesn't update the refs, why do the objects that were\n>> transferred by them not get asked the next time? There must be a bug\n>> somewhere, but it is getting late already, so I'll leave it to experts in\n>> the transfer area to figure it out...\n>\n> What about builtin-fetch.c:quickfetch() ?\n\nAhh, you are right. It walks from objects the remote side told us are at\nthe tip, and stops at what we know are complete (i.e. reachable from our\ntip of objects); immediately after --dry-run slurped objects, the next\nfetch will prove everything is locally available and complete before going\nover the network.\n\nBut either I am very confused or the use of fields from \"struct ref\" is\nunintuitive in this codepath.\n\nWhy does it feed ref->old_sha1? We are feeding _their_ tip commits to:\n\n rev-list --objects --stdin --not --all\n\nand expecting it to report failure when some of their tip commits lead to\nwhat we don't have yet. The reason why we have old_sha1[] vs new_sha1[]\nis because we want to report what changed from what, and also to protect\nus from simultaneous updates by doing compare-and-swap using the value we\nread from our refs when we started in old_sha1[], so I would have expected\nthat ref_map elements would have _their_ commits on the new_sha1[] side,\nbut apparently that is not what is happening, and it has been this way for\na long time. The use of old_sha1[] came from 4191c35 (git-fetch: avoid\nlocal fetching from alternate (again), 2007-11-11), so it is a lot more\nlikely that I am confused than the code is wrong and nobody noticed so\nfar.\n\nWhat am I missing?\n"},{"id":"131312","messageId":"m2iqb8xv7r.fsf@igel.home","threadId":"22152","inReplyTo":"ee2a733e1001100312j786108fct1b4c8abd0acc5afc@mail.gmail.com","subject":"Re: How to check new commit availability without full fetch?","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2010-01-11T20:06:16Z","receivedAt":"2010-01-11T20:06:16Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Leo Razoumov writes:\n\n> Hi List,\n> I am trying to find a way to check availability of new commits\n> *before* doing fetch or pull. Unfortunately, neither fetch nor pull\n> take \"--dry-run\" option (unlike push)\n\nTry git remote show origin.\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"},{"id":"131314","messageId":"alpine.LFD.2.00.1001111501360.10143@xanadu.home","threadId":"22152","inReplyTo":"7vmy0kjvms.fsf@alter.siamese.dyndns.org","subject":"Re: How to check new commit availability without full fetch?","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2010-01-11T20:52:04Z","receivedAt":"2010-01-11T20:52:04Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 11 Jan 2010, Junio C Hamano wrote:\n\n> Ahh, you are right. It walks from objects the remote side told us are at\n> the tip, and stops at what we know are complete (i.e. reachable from our\n> tip of objects); immediately after --dry-run slurped objects, the next\n> fetch will prove everything is locally available and complete before going\n> over the network.\n> \n> But either I am very confused or the use of fields from \"struct ref\" is\n> unintuitive in this codepath.\n> \n> Why does it feed ref->old_sha1? We are feeding _their_ tip commits to:\n> \n> rev-list --objects --stdin --not --all\n> \n> and expecting it to report failure when some of their tip commits lead to\n> what we don't have yet. The reason why we have old_sha1[] vs new_sha1[]\n> is because we want to report what changed from what, and also to protect\n> us from simultaneous updates by doing compare-and-swap using the value we\n> read from our refs when we started in old_sha1[], so I would have expected\n> that ref_map elements would have _their_ commits on the new_sha1[] side,\n> but apparently that is not what is happening, and it has been this way for\n> a long time. The use of old_sha1[] came from 4191c35 (git-fetch: avoid\n> local fetching from alternate (again), 2007-11-11), so it is a lot more\n> likely that I am confused than the code is wrong and nobody noticed so\n> far.\n\nVery confusing indeed. I first discovered about quickfetch() myself \nwhen I fixed shallow clone leading to commit 86386829.\n\nIf old_sha1[] was our refs then quickfetch() would always succeed and \nwe'd never fetch anything.\n\n> What am I missing?\n\nDigging a bit, it looks like get_remote_heads() is storing the remote's \nheads into old_sha1. And so is performed in get_refs_from_bundle(), and \nin insert_packed_refs() from get_refs_via_rsync(), etc.\n\nLooking at the struct ref definition, we can see:\n\nstruct ref {\n struct ref *next;\n unsigned char old_sha1[20];\n unsigned char new_sha1[20];\n [...]\n struct ref *peer_ref; /* when renaming */\n [...]\n};\n\n\n\nAnd apparently store_updated_refs() ends up using that peer_ref like \nthis:\n\n for (rm = ref_map; rm; rm = rm->next) {\n struct ref *ref = NULL;\n\n if (rm->peer_ref) {\n ref = xcalloc(1, sizeof(*ref) + strlen(rm->peer_ref->name) + 1);\n strcpy(ref->name, rm->peer_ref->name);\n hashcpy(ref->old_sha1, rm->peer_ref->old_sha1);\n hashcpy(ref->new_sha1, rm->old_sha1);\n ref->force = rm->peer_ref->force;\n }\n\nSo.... Doesn't this all look like a total mess of needless (and even \nleaked in this case) allocations and duplications, besides being \ncompletely unintuitive? Both hashcpy() above certainly throw my sense \nof logic aside...\n\n\nNicolas\n"}]}