{"thread":{"id":"18079","subject":"\"warning: no common commits\" triggered due to change of remote's IP address?","startedAt":"2009-03-01T18:01:47Z","lastAt":"2009-03-02T16:43:24Z","messageCount":6,"participants":["Brent Goodrick","Thomas Rast"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"106629","messageId":"e38bce640903011001p2d705707o9f7145ab5ab68929@mail.gmail.com","threadId":"18079","inReplyTo":null,"subject":"\"warning: no common commits\" triggered due to change of remote's IP address?","fromName":"Brent Goodrick","fromEmail":"bgoodr@gmail.com","sentAt":"2009-03-01T18:01:47Z","receivedAt":"2009-03-01T18:01:47Z","isPatch":false,"sender":{"key":"bgoodr@gmail.com","avatar":"https://gravatar.com/avatar/2399bf5a3468b3516a892183edfd43a7fa0300a2e9d5072189020186961150bc?d=mp&s=160"},"body":"Hi,\n\nI had this setup in my .git/config on my satellite machine:\n\n[remote \"origin\"]\n\turl = 192.168.2.3:git.repos/environ.git\n\tfetch = +refs/heads/home:refs/remotes/origin/home\n\n192.168.2.3 is the IP address of the main machine and repo, and is\ninternal to my LAN at home. My workflow is fairly simple: At home, on\nmy internal LAN, I usually update via these commands:\n\n git fetch\n git branch # <-- verify I am on the \"home\" branch\n git merge origin/home # <-- merge origin/home into home and fix conflicts\n\nI needed to do a git fetch of that same repository while out at an\nInternet cafe (via ssh). I know ahead of time that I might have had a\ncouple of files out of date between my satellite machines repo and my\norigin repo, but certainly not megabytes of data in difference. I want\nto pull those differences to the satellite machines repo to continue\nto work.\n\nOn the satellite machine, I simply did the fetch manually by changing\nthe IP address to be the WAN internet IP address of my ssh daemon I'm\nrunning at home:\n\n gitw fetch 88.99.100.101:git.repos/environ.git\n+refs/heads/home:refs/remotes/origin/home\n\nMy expectation at this point is that, since I've changed only the IP\naddress, and kept everything else the same, git should be smart enough\nto compare SHA1 values only and not download the entire remote repo\njust to do that comparison.\n\nBut I was quite surprised to find that it was pulling down tons of data:\n\n warning: no common commits\n remote: Counting objects: 2473, done.\n remote: Compressing objects: 100% (2199/2199), done.\n Receiving objects: 83% (2077/2473), 66.58 MiB | 67 KiB/s C-c C-c\n\nAt this point, for some reason I can't explain, the network got very\nslow (network bandwidth limiting?). So, I terminated the git fetch\n(the C-c C-c above), thinking that I can repair this when I get back\nto my LAN.\n\nSo my questions are:\n\n 1. Will terminating the git fetch like I did leave the satellite repo\n in an inconsistent state? If so, is my only choice to start\n a new repo from scratch on the satellite machine, or is there some\n repair mechanism?\n\n 2. Why did git conclude that there was no common commits?\n\nThanks,\nBrent\n"},{"id":"106635","messageId":"200903012221.03662.trast@student.ethz.ch","threadId":"18079","inReplyTo":"e38bce640903011001p2d705707o9f7145ab5ab68929@mail.gmail.com","subject":"Re: \"warning: no common commits\" triggered due to change of remote's IP address?","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2009-03-01T21:20:56Z","receivedAt":"2009-03-01T21:20:56Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Brent Goodrick wrote:\n> My expectation at this point is that, since I've changed only the IP\n> address, and kept everything else the same, git should be smart enough\n> to compare SHA1 values only and not download the entire remote repo\n> just to do that comparison.\n> \n> But I was quite surprised to find that it was pulling down tons of data:\n\nGit doesn't care about the details of the transport; during its\nhandshake, lists of the available refs are exchanged, and then used to\ndetermine the common commits. So I'm also rather surprised.\n\nHowever, your use of + refspecs in\n\n> gitw fetch 88.99.100.101:git.repos/environ.git\n> +refs/heads/home:refs/remotes/origin/home\n\nmakes me wonder: have you rewritten the repo hosting 'home' between\ntwo fetches? Using (especially, but not only) git-filter-branch can\neasily render your history disjoint from the pre-filtering state.\n\n> warning: no common commits\n\nEither your history is very short and really has no common commits\nwhatsoever, or it gave up because of the 256 revision limit during\nfind_common().\n\nIIRC it walks by date, so it is enough to make 256 local commits with\na new timestamp to hit that limit. I posted some experimental code\ntwo months ago that would use a bisection algorithm, so that it is\nharder to hit the limit and faster at detecting disjoint history, but\nnobody had the time to review it.\n\nI'll follow up with the patch if you want to try it. The problem is\nit's quite large _and_ I don't run any git servers where I could give\nit a good testing. You'll have to apply it to both sides.\n\n(It does have the nice side-effect of saving the uploading side a bit\nof work.)\n\n> 1. Will terminating the git fetch like I did leave the satellite repo\n> in an inconsistent state? If so, is my only choice to start\n> a new repo from scratch on the satellite machine, or is there some\n> repair mechanism?\n\nIt will just leave a temporary pack file that git-gc will eventually\nremove. You can just try another fetch later.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"106658","messageId":"e38bce640903011501t2c7a134dp887f5a96db3db0f4@mail.gmail.com","threadId":"18079","inReplyTo":"200903012221.03662.trast@student.ethz.ch","subject":"Re: \"warning: no common commits\" triggered due to change of remote's IP address?","fromName":"Brent Goodrick","fromEmail":"bgoodr@gmail.com","sentAt":"2009-03-01T23:01:20Z","receivedAt":"2009-03-01T23:01:20Z","isPatch":false,"sender":{"key":"bgoodr@gmail.com","avatar":"https://gravatar.com/avatar/2399bf5a3468b3516a892183edfd43a7fa0300a2e9d5072189020186961150bc?d=mp&s=160"},"body":"On Sun, Mar 1, 2009 at 1:20 PM, Thomas Rast wrote:\n> However, your use of + refspecs in\n>\n>> gitw fetch 88.99.100.101:git.repos/environ.git\n>> +refs/heads/home:refs/remotes/origin/home\n>\n> makes me wonder: have you rewritten the repo hosting 'home' between\n> two fetches? Using (especially, but not only) git-filter-branch can\n> easily render your history disjoint from the pre-filtering state.\n>\n>> warning: no common commits\n>\n> Either your history is very short and really has no common commits\n> whatsoever, or it gave up because of the 256 revision limit during\n> find_common().\n\nHmmm, maybe, without knowing it. Originally, that section of the\n.git/config file had \"*\"'s where \"home\" was. To clarify, the original\nwas:\n\n[remote \"origin\"]\n\turl = :git.repos/environ.git\n\tfetch = +refs/heads/*:refs/remotes/origin/*\n\nand the current one is now:\n\n[remote \"origin\"]\n\turl = :git.repos/environ.git\n\tfetch = +refs/heads/home:refs/remotes/origin/home\n\nMaybe I had made that change and this is the first time I am doing a\nfetch to using that change. I thinking that was the cause of this,\nbecause I retried doing a fetch into a separate throw-away repo with\njust the change of IP address, and it did not need to fetch anything\nmore. I had not executed git-filter-branch at all.\n\n>> 1. Will terminating the git fetch like I did leave the satellite repo\n>> in an inconsistent state? If so, is my only choice to start\n>> a new repo from scratch on the satellite machine, or is there some\n>> repair mechanism?\n>\n> It will just leave a temporary pack file that git-gc will eventually\n> remove. You can just try another fetch later.\n\nGood, that is what I would have expected.\n\nBrent\n"},{"id":"106681","messageId":"200903020940.24813.trast@student.ethz.ch","threadId":"18079","inReplyTo":"e38bce640903011501t2c7a134dp887f5a96db3db0f4@mail.gmail.com","subject":"Re: \"warning: no common commits\" triggered due to change of remote's IP address?","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2009-03-02T08:40:21Z","receivedAt":"2009-03-02T08:40:21Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Brent Goodrick wrote:\n> On Sun, Mar 1, 2009 at 1:20 PM, Thomas Rast wrote:\n> > [...] have you rewritten the repo hosting 'home' between\n> > two fetches? Using (especially, but not only) git-filter-branch can\n> > easily render your history disjoint from the pre-filtering state.\n> \n> Hmmm, maybe, without knowing it.\n\nIt's rather hard to rewrite history without knowing it, there are big\nwarnings all over the relevant tools' manpages...\n\n> Originally, that section of the\n> .git/config file had \"*\"'s where \"home\" was. To clarify, the original\n> was:\n> \n> [remote \"origin\"]\n> \turl = :git.repos/environ.git\n> \tfetch = +refs/heads/*:refs/remotes/origin/*\n> \n> and the current one is now:\n> \n> [remote \"origin\"]\n> \turl = :git.repos/environ.git\n> \tfetch = +refs/heads/home:refs/remotes/origin/home\n> \n> Maybe I had made that change and this is the first time I am doing a\n> fetch to using that change. I thinking that was the cause of this,\n> because I retried doing a fetch into a separate throw-away repo with\n> just the change of IP address, and it did not need to fetch anything\n> more. I had not executed git-filter-branch at all.\n\nIronically I cannot reproduce this except with my \"own\" version that\nincludes the patch I posted yesterday. I'll have to look into why it\nfails to list any refs to the remote. In the meantime please\ndisregard that patch.\n\nIf you still have a repo that can reproduce the problem, please keep a\ncopy for future investigation, and then try\n\n git fetch-pack -v $url refs/remotes/origin/home 2>&1 \\\n | git name-rev --stdin\n\nThe -v will dump a lot of output about the common commit search. The\nmessage \"giving up\" indicates that you hit the 256 commit limit; if\nthat doesn't appear, please include the full output so that we can see\nwhere it stops.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"106682","messageId":"200903020956.45975.trast@student.ethz.ch","threadId":"18079","inReplyTo":"200903020940.24813.trast@student.ethz.ch","subject":"Re: \"warning: no common commits\" triggered due to change of remote's IP address?","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2009-03-02T08:56:42Z","receivedAt":"2009-03-02T08:56:42Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Thomas Rast wrote:\n> If you still have a repo that can reproduce the problem, please keep a\n> copy for future investigation, and then try\n> \n> git fetch-pack -v $url refs/remotes/origin/home 2>&1 \\\n> | git name-rev --stdin\n\nActually this should name the remote's idea of the ref, i.e.,\n\n git fetch-pack -v $url refs/heads/home 2>&1 \\\n | git name-rev --stdin\n\nSorry.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"106711","messageId":"e38bce640903020843p4d7e20f8lbdfe980b34661bce@mail.gmail.com","threadId":"18079","inReplyTo":"200903020956.45975.trast@student.ethz.ch","subject":"Re: \"warning: no common commits\" triggered due to change of remote's IP address?","fromName":"Brent Goodrick","fromEmail":"bgoodr@gmail.com","sentAt":"2009-03-02T16:43:24Z","receivedAt":"2009-03-02T16:43:24Z","isPatch":false,"sender":{"key":"bgoodr@gmail.com","avatar":"https://gravatar.com/avatar/2399bf5a3468b3516a892183edfd43a7fa0300a2e9d5072189020186961150bc?d=mp&s=160"},"body":"On Mon, Mar 2, 2009 at 12:56 AM, Thomas Rast wrote:\n> Actually this should name the remote's idea of the ref, i.e.,\n>\n> git fetch-pack -v $url refs/heads/home 2>&1 \\\n> | git name-rev --stdin\n\nSorry, but I had since done a git fetch from home using the local IP\naddress before I realized that you would want to try more\nexperiments on it. But that \"local\" git-fetch did not emit the\n\"warning: no common commits\" message and was fast. Maybe the majority\nof the fetch I had started at the Internet cafe but terminated had\ndone a lion share of the work already, and the speedy local fetch\nfinished up the leftovers.\n\nBut for completeness sake, I did as you said on the now (mostly) up to\ndate repo:\n\n git fetch-pack -v :git.repos/environ.git\nrefs/heads/home 2>&1 \\\n | git name-rev --stdin\n Server supports multi_ack\n Server supports side-band-64k\n Marking 67cb0521a93778a9d9c4d8f4608f2c6c796a7558 (home) as complete\n already have 67cb0521a93778a9d9c4d8f4608f2c6c796a7558 (home) (refs/heads/home)\n 67cb0521a93778a9d9c4d8f4608f2c6c796a7558 (home) refs/heads/home\n\nwhere is the remote IP address, and not the usual\nlocal IP address that is referenced in .git/config.\n\nWhat does \"Marking ... as complete\" mean?\n\nIs the git-fetch-pack method shown above the only way to get a report\nof what git finds out of date? Seems that git-fetch-pack actually\ndownloads objects, instead of just reporting what it would do without\nactually doing it.\n\nBrent\n"}]}