{"thread":{"id":"3743","subject":"git pull fails","startedAt":"2006-03-28T13:28:31Z","lastAt":"2006-03-29T00:57:00Z","messageCount":10,"participants":["Timo Hirvonen","Ralf Baechle","Radoslaw Szkodzinski","Petr Baudis","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"18071","messageId":"20060328162831.af1bd4c0.tihirvon@gmail.com","threadId":"3743","inReplyTo":null,"subject":"git pull fails","fromName":"Timo Hirvonen","fromEmail":"tihirvon@gmail.com","sentAt":"2006-03-28T13:28:31Z","receivedAt":"2006-03-28T13:28:31Z","isPatch":false,"sender":{"key":"tihirvon@gmail.com","avatar":null},"body":"I think fast-forward check in git-fetch is too strict:\n\n28 16:13 /usr/src/git: git pull\nUnpacking 33 objects\n 100% (33/33) done\n* refs/heads/todo: same as branch 'todo' of git://git.kernel.org/pub/scm/git/git\n* refs/heads/maint: same as branch 'maint' of git://git.kernel.org/pub/scm/git/git\n* refs/heads/origin: same as branch 'master' of git://git.kernel.org/pub/scm/git/git\n* refs/heads/pu: does not fast forward to branch 'pu' of git://git.kernel.org/pub/scm/git/git;\n not updating.\n\nAfter removing \"exit 1\" added by a9698bb22fb7b66e5882c3a5e7b2b8b53ea03f90 from\ngit-fetch \"git pull\" worked again.\n\n-- \nhttp://onion.dynserv.net/~timo/\n"},{"id":"18072","messageId":"20060328141140.GC3113@linux-mips.org","threadId":"3743","inReplyTo":"20060328162831.af1bd4c0.tihirvon@gmail.com","subject":"Re: git pull fails","fromName":"Ralf Baechle","fromEmail":"ralf@linux-mips.org","sentAt":"2006-03-28T14:11:40Z","receivedAt":"2006-03-28T14:11:40Z","isPatch":false,"sender":{"key":"ralf@linux-mips.org","avatar":null},"body":"On Tue, Mar 28, 2006 at 04:28:31PM +0300, Timo Hirvonen wrote:\n\n> I think fast-forward check in git-fetch is too strict:\n> \n> 28 16:13 /usr/src/git: git pull\n> Unpacking 33 objects\n> 100% (33/33) done\n> * refs/heads/todo: same as branch 'todo' of git://git.kernel.org/pub/scm/git/git\n> * refs/heads/maint: same as branch 'maint' of git://git.kernel.org/pub/scm/git/git\n> * refs/heads/origin: same as branch 'master' of git://git.kernel.org/pub/scm/git/git\n> * refs/heads/pu: does not fast forward to branch 'pu' of git://git.kernel.org/pub/scm/git/git;\n> not updating.\n> \n> After removing \"exit 1\" added by a9698bb22fb7b66e5882c3a5e7b2b8b53ea03f90 from\n> git-fetch \"git pull\" worked again.\n\nContinuing to walk after breaking a leg isn't a good idea, but that's\nbasically what your change did. What has happened to you is the normal\nthing with branches that have been re-based or otherwise re-created.\nThe better way to handle this kind of branches is to add a `+´ sign to\nthe refspec for the pu branc in .git/remote/origin like:\n\n[ralf@blah git]$ cat .git/remotes/origin\nURL: git://www.kernel.org/pub/scm/git/git.git\nPull: master:master\nPull: todo:todo\nPull: +next:next\nPull: maint:maint\nPull: +pu:pu\nPull: html:html\nPull: man:man\n[ralf@blah git]$\n\nThe next branch is handled the same way, so another `+´ sign.\n\n Ralf\n"},{"id":"18073","messageId":"20060328173827.3d64d91e.tihirvon@gmail.com","threadId":"3743","inReplyTo":"20060328141140.GC3113@linux-mips.org","subject":"Re: git pull fails","fromName":"Timo Hirvonen","fromEmail":"tihirvon@gmail.com","sentAt":"2006-03-28T14:38:27Z","receivedAt":"2006-03-28T14:38:27Z","isPatch":false,"sender":{"key":"tihirvon@gmail.com","avatar":null},"body":"Ralf Baechle wrote:\n\n> Continuing to walk after breaking a leg isn't a good idea, but that's\n> basically what your change did. What has happened to you is the normal\n> thing with branches that have been re-based or otherwise re-created.\n> The better way to handle this kind of branches is to add a `+´ sign to\n> the refspec for the pu branc in .git/remote/origin like:\n> \n> [ralf@blah git]$ cat .git/remotes/origin\n> URL: git://www.kernel.org/pub/scm/git/git.git\n> Pull: master:master\n> Pull: todo:todo\n> Pull: +next:next\n> Pull: maint:maint\n> Pull: +pu:pu\n> Pull: html:html\n> Pull: man:man\n> [ralf@blah git]$\n> \n> The next branch is handled the same way, so another `+´ sign.\n\nThanks, but forcing everyone to edit their git/remotes/origin file\nis not very nice solution. I think git-fetch should update refs for the\nother non-'broken' branches and leave \"pu\" and \"next\" refs untouched.\n\n-- \nhttp://onion.dynserv.net/~timo/\n"},{"id":"18075","messageId":"200603281700.17233.astralstorm@o2.pl","threadId":"3743","inReplyTo":"20060328173827.3d64d91e.tihirvon@gmail.com","subject":"Re: git pull fails","fromName":"Radoslaw Szkodzinski","fromEmail":"astralstorm@o2.pl","sentAt":"2006-03-28T15:00:11Z","receivedAt":"2006-03-28T15:00:11Z","isPatch":false,"sender":{"key":"astralstorm@o2.pl","avatar":null},"body":"On Tuesday 28 March 2006 16:38, Timo Hirvonen wrote yet:\n> Thanks, but forcing everyone to edit their git/remotes/origin file\n> is not very nice solution. I think git-fetch should update refs for the\n> other non-'broken' branches and leave \"pu\" and \"next\" refs untouched.\n\nHow do you know a non-broken branch from something weird?\nAll git knows is that the history is non-linear. You can do at least three \nthings:\n- discard older history\n- merge older history with newer\n- add another branch\n\nOr instead provide a more useful error message, like what is attached.\n(I hope kmail doesn't mangle the tabs.)\n\ndiff --git a/git-fetch.sh b/git-fetch.sh\nindex 0346d4a..88df7f4 100755\n--- a/git-fetch.sh\n+++ b/git-fetch.sh\n@@ -172,13 +172,15 @@ fast_forward_local () {\n \t\t;;\n \t esac || {\n \t\techo >&2 \"* $1: does not fast forward to $3;\"\n+\t\techo >&2 \" If the branch is known to roll back often,\"\n+\t\techo >&2 \" add + before the branch name in $GIT_DIR/$1.\"\n \t\tcase \",$force,$single_force,\" in\n \t\t*,t,*)\n-\t\t\techo >&2 \" forcing update.\"\n+\t\t\techo >&2 \" Forcing update.\"\n \t\t\tgit-update-ref \"$1\" \"$2\" \"$local\"\n \t\t\t;;\n \t\t*)\n-\t\t\techo >&2 \" not updating.\"\n+\t\t\techo >&2 \" Not updating.\"\n \t\t\t;;\n \t\tesac\n \t }\n\n-- \nGPG Key id: 0xD1F10BA2\nFingerprint: 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2\n\nAstralStorm\n"},{"id":"18085","messageId":"20060328224807.GC27689@pasky.or.cz","threadId":"3743","inReplyTo":"200603281700.17233.astralstorm@o2.pl","subject":"Re: git pull fails","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-03-28T22:48:07Z","receivedAt":"2006-03-28T22:48:07Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Mar 28, 2006 at 05:00:11PM CEST, I got a letter\nwhere Radoslaw Szkodzinski said that...\n> On Tuesday 28 March 2006 16:38, Timo Hirvonen wrote yet:\n> > Thanks, but forcing everyone to edit their git/remotes/origin file\n> > is not very nice solution. I think git-fetch should update refs for the\n> > other non-'broken' branches and leave \"pu\" and \"next\" refs untouched.\n> \n> How do you know a non-broken branch from something weird?\n\nIf I understand it right, Timo complains that git-fetch got\nnon-fastforward commits for \"pu\" and \"next\" and a good fastforward\ncommit for \"master\", but it didn't update the ref for ANY head, not even\nthe \"master\".\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nRight now I am having amnesia and deja-vu at the same time. I think\nI have forgotten this before.\n"},{"id":"18096","messageId":"20060329031136.e0389c00.tihirvon@gmail.com","threadId":"3743","inReplyTo":"20060328224807.GC27689@pasky.or.cz","subject":"Re: git pull fails","fromName":"Timo Hirvonen","fromEmail":"tihirvon@gmail.com","sentAt":"2006-03-29T00:11:36Z","receivedAt":"2006-03-29T00:11:36Z","isPatch":false,"sender":{"key":"tihirvon@gmail.com","avatar":null},"body":"Petr Baudis wrote:\n\n> If I understand it right, Timo complains that git-fetch got\n> non-fastforward commits for \"pu\" and \"next\" and a good fastforward\n> commit for \"master\", but it didn't update the ref for ANY head, not even\n> the \"master\".\n\nExactly. Maybe git-fetch should abort only if it could not update the\ncurrently checked out branch?\n\n-- \nhttp://onion.dynserv.net/~timo/\n"},{"id":"18099","messageId":"7vzmjagkvv.fsf@assigned-by-dhcp.cox.net","threadId":"3743","inReplyTo":"20060329031136.e0389c00.tihirvon@gmail.com","subject":"Re: git pull fails","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-29T00:22:28Z","receivedAt":"2006-03-29T00:22:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Timo Hirvonen writes:\n\n> Petr Baudis wrote:\n>\n>> If I understand it right, Timo complains that git-fetch got\n>> non-fastforward commits for \"pu\" and \"next\" and a good fastforward\n>> commit for \"master\", but it didn't update the ref for ANY head, not even\n>> the \"master\".\n>\n> Exactly. Maybe git-fetch should abort only if it could not update the\n> currently checked out branch?\n\nThe erroring-out is there so that the user can take notice.\n"},{"id":"18100","messageId":"20060329002415.GG27689@pasky.or.cz","threadId":"3743","inReplyTo":"20060329031136.e0389c00.tihirvon@gmail.com","subject":"Re: git pull fails","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-03-29T00:24:15Z","receivedAt":"2006-03-29T00:24:15Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Wed, Mar 29, 2006 at 02:11:36AM CEST, I got a letter\nwhere Timo Hirvonen said that...\n> Exactly. Maybe git-fetch should abort only if it could not update the\n> currently checked out branch?\n\nThat should _never_ be the case. Any modern porcelain shouldn't let you\nswitch your current branch to a remote one, hopefully. It's just wrong.\nThe supported setup is that you have a remote branch reflecting where\nthe upstream is and a local branch reflecting where your current tree\nis, and you update your local branch by git-pull (or git-merge if you\nwant to avoid fetching).\n\nIf your current branch would really be a remote branch and you simply\ngit-fetched, your HEAD would change but not your working tree, and at\nthat moment things would become very confusing. Cogito would start\nshowing nonsensical stuff for cg-status and cg-diff (as well as\ngit-diff-tree HEAD output), but your index would at least still be\ncorrect so I'm not sure how much attention do tools like git-diff pay to\nit, the level of messup would be proportional to that.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nRight now I am having amnesia and deja-vu at the same time. I think\nI have forgotten this before.\n"},{"id":"18101","messageId":"7vu09igk1t.fsf@assigned-by-dhcp.cox.net","threadId":"3743","inReplyTo":"20060329002415.GG27689@pasky.or.cz","subject":"Re: git pull fails","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-29T00:40:30Z","receivedAt":"2006-03-29T00:40:30Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis writes:\n\n> If your current branch would really be a remote branch and you simply\n> git-fetched, your HEAD would change but not your working tree, and at\n> that moment things would become very confusing. Cogito would start\n> showing nonsensical stuff for cg-status and cg-diff (as well as\n> git-diff-tree HEAD output), but your index would at least still be\n> correct so I'm not sure how much attention do tools like git-diff pay to\n> it, the level of messup would be proportional to that.\n\nPeople want to leave tracking branches checked out, especially\nwhen they are not developers but are \"update to the latest and\ncompile the bleeding edge\" types. Support for that mode of\noperation was invented long time ago and git-pull knows about\nit, and the idea was ported to git-cvsimport recently.\n"},{"id":"18103","messageId":"20060329005700.GC27631@pasky.or.cz","threadId":"3743","inReplyTo":"7vu09igk1t.fsf@assigned-by-dhcp.cox.net","subject":"Re: git pull fails","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-03-29T00:57:00Z","receivedAt":"2006-03-29T00:57:00Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Wed, Mar 29, 2006 at 02:40:30AM CEST, I got a letter\nwhere Junio C Hamano said that...\n> Petr Baudis writes:\n> \n> > If your current branch would really be a remote branch and you simply\n> > git-fetched, your HEAD would change but not your working tree, and at\n> > that moment things would become very confusing. Cogito would start\n> > showing nonsensical stuff for cg-status and cg-diff (as well as\n> > git-diff-tree HEAD output), but your index would at least still be\n> > correct so I'm not sure how much attention do tools like git-diff pay to\n> > it, the level of messup would be proportional to that.\n> \n> People want to leave tracking branches checked out, especially\n> when they are not developers but are \"update to the latest and\n> compile the bleeding edge\" types. Support for that mode of\n> operation was invented long time ago and git-pull knows about\n> it, and the idea was ported to git-cvsimport recently.\n\nWhy can't such people just have two branches, _especially_ if they are\nthe \"update to the latest and compile the bleeding edge\" types?\n(Therefore well not likely to be familiar with the Git branching model\nat all.)\n\nI mean, sure, it's Core Git so the extra flexibility is nice. But I now\nwonder, can you think of any plausible workflow where having one branch\ninstead of two would be an advantage?\n\nWaah, cg-log git-fetch.sh, /update-head just showed me the change in\ngit-fetch-script from last August, with no extra work for me. The big\nrename barrier annoyances finally gone forever!\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nRight now I am having amnesia and deja-vu at the same time. I think\nI have forgotten this before.\n"}]}