{"thread":{"id":"3654","subject":"git-reset and clones","startedAt":"2006-03-16T14:34:42Z","lastAt":"2006-03-19T21:40:38Z","messageCount":12,"participants":["Paul Jakma","Andreas Ericsson","sean","Junio C Hamano","Jon Loeliger","Petr Baudis"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"17590","messageId":"Pine.LNX.4.64.0603161424310.5276@sheen.jakma.org","threadId":"3654","inReplyTo":null,"subject":"git-reset and clones","fromName":"Paul Jakma","fromEmail":"paul@clubi.ie","sentAt":"2006-03-16T14:34:42Z","receivedAt":"2006-03-16T14:34:42Z","isPatch":false,"sender":{"key":"paul@clubi.ie","avatar":null},"body":"Hi,\n\nNext dumb question:\n\nIf a git repository has a reset HEAD~X done, then any later pulls in \nclone repositories get /really/ upset, with:\n\n$ git pull\n* refs/heads/origin: does not fast forward to branch 'master' of \n/home/paul/foo-git/;\n\nType of thing. This seems to be a similar issue to:\n\n \thttp://www.gelato.unsw.edu.au/archives/git/0510/10767.html\n\nThe question is has this improved at all since last year? Is there \nanything the origin repository maintainer (the one who did reset) can \ndo to recover from this?\n\nI'm guessing the answer is:\n\nYes:\n\n1. where git-reset has already been done, manually update the\n   refs back to the previous HEAD\n2. then use git-revert, and continue to use git-revert only.\n\nMy question then would be, presuming some innocent repository \nmaintainer has already done 1, what's the easiest way to accomplish \n1?\n\n(they shouldn't have done it obviously, but assume they're git \nnewbies, made an honest mistake and now need to recover, preferably \nwithout having to involve those who pull).\n\nregards,\n-- \nPaul Jakma\tpaul@clubi.ie\tpaul@jakma.org\tKey ID: 64A2FF6A\nFortune:\nBe cautious in your daily affairs.\n"},{"id":"17593","messageId":"BAYC1-PASMTP09E59C4F23C4CDF45B1C42AEE70@CEZ.ICE","threadId":"3654","inReplyTo":"Pine.LNX.4.64.0603161424310.5276@sheen.jakma.org","subject":"Re: git-reset and clones","fromName":"sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-03-16T14:52:13Z","receivedAt":"2006-03-16T14:52:13Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Thu, 16 Mar 2006 14:34:42 +0000 (GMT)\nPaul Jakma <paul@clubi.ie> wrote:\n\n> If a git repository has a reset HEAD~X done, then any later pulls in \n> clone repositories get /really/ upset, with:\n> \n> $ git pull\n> * refs/heads/origin: does not fast forward to branch 'master' of \n> /home/paul/foo-git/;\n> \n> Type of thing. This seems to be a similar issue to:\n> \n>  \thttp://www.gelato.unsw.edu.au/archives/git/0510/10767.html\n> \n> The question is has this improved at all since last year? Is there \n> anything the origin repository maintainer (the one who did reset) can \n> do to recover from this?\n\nIt's still not a recommended operation on a repository that is pulled \nby others.  If you realize you made a mistake by resetting the head, \nyou can undo the operation afterward with:\n\n$ git reset ORIG_HEAD\n\nSean\n"},{"id":"17592","messageId":"44197C04.5080400@op5.se","threadId":"3654","inReplyTo":"Pine.LNX.4.64.0603161424310.5276@sheen.jakma.org","subject":"Re: git-reset and clones","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-03-16T14:53:56Z","receivedAt":"2006-03-16T14:53:56Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Paul Jakma wrote:\n> Hi,\n> \n> Next dumb question:\n> \n> If a git repository has a reset HEAD~X done, then any later pulls in \n> clone repositories get /really/ upset, with:\n> \n> $ git pull\n> * refs/heads/origin: does not fast forward to branch 'master' of \n> /home/paul/foo-git/;\n> \n> Type of thing. This seems to be a similar issue to:\n> \n>     http://www.gelato.unsw.edu.au/archives/git/0510/10767.html\n> \n> The question is has this improved at all since last year? Is there \n> anything the origin repository maintainer (the one who did reset) can do \n> to recover from this?\n> \n> I'm guessing the answer is:\n> \n> Yes:\n> \n> 1. where git-reset has already been done, manually update the\n>   refs back to the previous HEAD\n> 2. then use git-revert, and continue to use git-revert only.\n> \n> My question then would be, presuming some innocent repository maintainer \n> has already done 1, what's the easiest way to accomplish 1?\n> \n> (they shouldn't have done it obviously, but assume they're git newbies, \n> made an honest mistake and now need to recover, preferably without \n> having to involve those who pull).\n> \n\nI *think* this should work. Get a backup before trying. Note that I'm \nassuming \"git reset\" hasn't been run several times, or you'll have to \nreplace ORIGIN with whatever HEAD pointed to before the first reset.\n\nIn mothership-repo:\n\tgit checkout master\n\tgit branch next-master ORIGIN\n\tgit rebase next-master; # fix conflicts and commit\n\tgit branch -d master\n\tgit checkout -b master next-master\n\tgit -d next-master\n\tgit revert (the bad commits)\n\nSome shortcuts can be taken if we're not to use git commands the entire \nway, but this is easier to explain to those newbie-ish people you mentioned.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"17594","messageId":"44197D5F.4030808@op5.se","threadId":"3654","inReplyTo":"44197C04.5080400@op5.se","subject":"Re: git-reset and clones","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-03-16T14:59:43Z","receivedAt":"2006-03-16T14:59:43Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Andreas Ericsson wrote:\n> \n>     git branch next-master ORIGIN\n\ns/ORIGIN/ORIG_HEAD/\n\notherwise the advice still applies.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"17595","messageId":"BAYC1-PASMTP0354DF2E1D7C62E86C43D9AEE70@CEZ.ICE","threadId":"3654","inReplyTo":"44197C04.5080400@op5.se","subject":"Re: git-reset and clones","fromName":"sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-03-16T15:21:45Z","receivedAt":"2006-03-16T15:21:45Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Thu, 16 Mar 2006 15:53:56 +0100\nAndreas Ericsson <ae@op5.se> wrote:\n\n> In mothership-repo:\n> \tgit checkout master\n> \tgit branch next-master ORIGIN\n> \tgit rebase next-master; # fix conflicts and commit\n> \tgit branch -d master\n> \tgit checkout -b master next-master\n> \tgit -d next-master\n> \tgit revert (the bad commits)\n\nDownstream repos may still be broken afterward though; not much \nyou can do about that unfortunately.\n\nSean\n"},{"id":"17596","messageId":"Pine.LNX.4.64.0603161547540.5276@sheen.jakma.org","threadId":"3654","inReplyTo":"BAYC1-PASMTP09E59C4F23C4CDF45B1C42AEE70@CEZ.ICE","subject":"Re: git-reset and clones","fromName":"Paul Jakma","fromEmail":"paul@clubi.ie","sentAt":"2006-03-16T15:48:13Z","receivedAt":"2006-03-16T15:48:13Z","isPatch":false,"sender":{"key":"paul@clubi.ie","avatar":null},"body":"On Thu, 16 Mar 2006, sean wrote:\n\n> $ git reset ORIG_HEAD\n\nAh, of course :).\n\nThanks.\n\nregards,\n-- \nPaul Jakma\tpaul@clubi.ie\tpaul@jakma.org\tKey ID: 64A2FF6A\nFortune:\nThere's no such thing as pure pleasure; some anxiety always goes with it.\n"},{"id":"17603","messageId":"7v4q1x95yo.fsf@assigned-by-dhcp.cox.net","threadId":"3654","inReplyTo":"Pine.LNX.4.64.0603161424310.5276@sheen.jakma.org","subject":"Re: git-reset and clones","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-17T02:10:23Z","receivedAt":"2006-03-17T02:10:23Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Paul Jakma <paul@clubi.ie> writes:\n\n> If a git repository has a reset HEAD~X done, then any later pulls in\n> clone repositories get /really/ upset, with:\n>\n> $ git pull\n> * refs/heads/origin: does not fast forward to branch 'master' of\n> /home/paul/foo-git/;\n>\n> Type of thing. This seems to be a similar issue to:\n>\n> \thttp://www.gelato.unsw.edu.au/archives/git/0510/10767.html\n>\n> The question is has this improved at all since last year? Is there\n> anything the origin repository maintainer (the one who did reset) can\n> do to recover from this?\n\nYou used to have something like this:\n\n\n                 o---o---o---A\n                /            ^ your HEAD used to point at here\n    ---o---o---o\n\nand you forgot other people already have the commit chain up to\ncommit A.   But you rewound and did cleanups:\n\n                 o---o---o---A\n                /\n    ---o---o---o---o---o---B\n                           ^ your HEAD now points at here\n\nPeople who track your HEAD have A and your updated head B does\nnot fast forward.  Oops.\n\nThe recovery consists of two steps.  The first step is more\nimportant.  To find what commits you lost that others already\nmay have.  You may be lucky and remember A's commit object name,\nbut when I did that I had to ask around on the list X-<.\n\nThe second step is a single command:\n\n\t$ git merge -s ours 'Graft the lost side branch back in' \\\n\t\tHEAD A\n\nwhere A is the object name of that commit.  On your current\nbranch, this creates a merge commit between A and B (your\ncurrent HEAD), taking the tree object from B.\n\n                 o---o---o---A\n                /             \\\n    ---o---o---o---o---o---B---M\n\nYou want to keep the contents of the cleaned-up HEAD, so that is\nwhy you are taking the tree from B.  With this commit M, you are\ntelling the outside world that it is OK if they start from a\ncommit on the now-recovered side branch.\n\nIf the tree of A and B exactly match, further merges with people\nstarting from A branch would not have conflicts.  If the\ndifference between A and B are mostly clean-ups, automerge would\nlose dirtiness you cleaned-up when they update to your new HEAD\n(because the transition from A to M reverts the dirtiness, which\nis what your clean-up was about), which is what you want.\n"},{"id":"17621","messageId":"1142623141.17536.225.camel@cashmere.sps.mot.com","threadId":"3654","inReplyTo":"7v4q1x95yo.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-reset and clones","fromName":"Jon Loeliger","fromEmail":"jdl@freescale.com","sentAt":"2006-03-17T19:19:02Z","receivedAt":"2006-03-17T19:19:02Z","isPatch":false,"sender":{"key":"jdl@jdl.com","avatar":"https://gravatar.com/avatar/75ce9a10b151acd2c28ec4ab2136dba7b2ff1634530bd04b155981a749d08a64?d=mp&s=160"},"body":"On Thu, 2006-03-16 at 20:10, Junio C Hamano wrote:\n\n> \n> You used to have something like this:\n> \n> \n>                  o---o---o---A\n>                 /            ^ your HEAD used to point at here\n>     ---o---o---o\n> \n> and you forgot other people already have the commit chain up to\n> commit A.   But you rewound and did cleanups:\n> \n>                  o---o---o---A\n>                 /\n>     ---o---o---o---o---o---B\n>                            ^ your HEAD now points at here\n> \n> People who track your HEAD have A and your updated head B does\n> not fast forward.  Oops.\n> \n> The recovery consists of two steps.  The first step is more\n> important.  To find what commits you lost that others already\n> may have.  You may be lucky and remember A's commit object name,\n> but when I did that I had to ask around on the list X-<.\n> \n> The second step is a single command:\n> \n> \t$ git merge -s ours 'Graft the lost side branch back in' \\\n> \t\tHEAD A\n> \n> where A is the object name of that commit.  On your current\n> branch, this creates a merge commit between A and B (your\n> current HEAD), taking the tree object from B.\n> \n>                  o---o---o---A\n>                 /             \\\n>     ---o---o---o---o---o---B---M\n\nJunio,\n\nCan you explain a bit more why the \"ours\" strategy\ncomes into play here?  I _think_ I understand, but\nI'd like to hear a bit more explanation, please.\nHow is this different from just merging in A directly?\n\n> You want to keep the contents of the cleaned-up HEAD, so that is\n> why you are taking the tree from B.\n\nAnd the \"ours\" strategy effectively says, \"Favor the B\nside of things when pulling in the A parts\", right?\n\n>   With this commit M, you are\n> telling the outside world that it is OK if they start from a\n> commit on the now-recovered side branch.\n\nThis is mystical to me.  How is the \"A\" (ie, side branch)\nnow in a \"recovered\" state?\n\nThanks,\njdl\n"},{"id":"17622","messageId":"7vslpgztzc.fsf@assigned-by-dhcp.cox.net","threadId":"3654","inReplyTo":"1142623141.17536.225.camel@cashmere.sps.mot.com","subject":"Re: git-reset and clones","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-17T20:39:19Z","receivedAt":"2006-03-17T20:39:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jon Loeliger <jdl@freescale.com> writes:\n\n>> ...  On your current\n>> branch, this creates a merge commit between A and B (your\n>> current HEAD), taking the tree object from B.\n>> \n>>                  o---o---o---A\n>>                 /             \\\n>>     ---o---o---o---o---o---B---M\n>\n> Can you explain a bit more why the \"ours\" strategy\n> comes into play here?  I _think_ I understand, but\n> I'd like to hear a bit more explanation, please.\n> How is this different from just merging in A directly?\n\n>> You want to keep the contents of the cleaned-up HEAD, so that is\n>> why you are taking the tree from B.\n>\n> And the \"ours\" strategy effectively says, \"Favor the B\n> side of things when pulling in the A parts\", right?\n\nYes, it is stronger than that.  \"ours\" says: \"the tree from our\nhead commit B *is* the resulting tree -- whatever we are merging\ninto us does not matter\".\n\n>>   With this commit M, you are\n>> telling the outside world that it is OK if they start from a\n>> commit on the now-recovered side branch.\n>\n> This is mystical to me.  How is the \"A\" (ie, side branch)\n> now in a \"recovered\" state?\n\nAlthough their effects are superseded (B^{tree} == M^{tree}),\nthey are still in the ancestry chain.\n\nTo a downstream person who were lucky enough not to have made\ncommits on A yet, next pull from you would have involved merging\nB and A.\n\nIf the upstream did not do the magic \"ours\" merge, the git-fetch\nstep would refuse to update the remote tracking branch head, so\nthe downstream person needs to force the fetch.  After forcing\nthe fetch, the merge would have involved resolving the conflicts\ncoming from 3-way merge in this:\n\n                  o---o---o---A---N\n                 /               /  \n     ---o---o---o---o---o---B---'\n\nBecause the forked track leading to B was either to fix mistakes\nor clean things up the upstream originally did in the track\nleading to A, the commits on the tracks leading to A and B from\ntheir fork point are almost guaranteed to have conflicting\nchanges, and resolution of that conflict is forced on the\ndownstream person.  Worse yet, from this point on, since the\nupstream discarded the track that contains A, the branch\ndownstream person has will _never_ converge to upstream branch,\neven though the downstream person did _no_ development of his\nown in the meantime.  This is *B*A*D*.\n\nIf there is a magic \"ours\" merge, the downstream person's\nrepository records A as the last tip on the tracking branch, and\ngit-fetch sees the updated head M is a descendant of it, so it\nsimply fast-forwards:\n\n                  o---o---o---A\n                 /             \\\n     ---o---o---o---o---o---B---M\n\n\nNow, if the downstream was unlucky and have commits based on A,\nthe story is a bit different, but the principles are the same.\n\nWithout the \"ours\" merge M, you will get this:\n\n                  o---o---o---A---X---N\n                 /                   /  \n     ---o---o---o---o---o---B-------'\n\nWhen creating the merge N, even if the change between A and X\n(i.e. the downstream's own work) does not touch the paths that\ndiffer between A and B, the downstream is forced to resolve\nconflicts between A and B. This is unnecessary burden for him.\nThe upstream should have cleaned up his own mess.\n\nWith the \"ours\" merge M, you will get this:\n\n\n                  o---o---o---A---X---N\n                 /             \\     /\n     ---o---o---o---o---o---B---M---'\n\nThe downstream does not need to worry about the conflicts\nbetween A and B.  It has been already resolved at M.\nEspecially, if the change between A and X does not touch the\npaths that differ in A and B, conflict resolution would be\npurely about his own work.\n\nIn either case, since the downstream has his own development,\nthe heads of their branches never converge until the upstream\nbuys his changes (i.e. pull from the downstream that has \"N\"\ncommit), but that is not a problem but a feature and does not\nhave anything to do with this \"oops, rewound by mistake\" issue.\n"},{"id":"17623","messageId":"1142629202.17536.242.camel@cashmere.sps.mot.com","threadId":"3654","inReplyTo":"7vslpgztzc.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-reset and clones","fromName":"Jon Loeliger","fromEmail":"jdl@freescale.com","sentAt":"2006-03-17T21:00:03Z","receivedAt":"2006-03-17T21:00:03Z","isPatch":false,"sender":{"key":"jdl@jdl.com","avatar":"https://gravatar.com/avatar/75ce9a10b151acd2c28ec4ab2136dba7b2ff1634530bd04b155981a749d08a64?d=mp&s=160"},"body":"On Fri, 2006-03-17 at 14:39, Junio C Hamano wrote:\n\n> > And the \"ours\" strategy effectively says, \"Favor the B\n> > side of things when pulling in the A parts\", right?\n> \n> Yes, it is stronger than that.  \"ours\" says: \"the tree from our\n> head commit B *is* the resulting tree -- whatever we are merging\n> into us does not matter\".\n\nAha!  This all makes much more sense now suddenly.\n\nThank you.\n\n\n> \n>                   o---o---o---A---N\n>                  /               /  \n>      ---o---o---o---o---o---B---'\n> \n> Because the forked track leading to B was either to fix mistakes\n> or clean things up the upstream originally did in the track\n> leading to A, the commits on the tracks leading to A and B from\n> their fork point are almost guaranteed to have conflicting\n> changes, and resolution of that conflict is forced on the\n> downstream person.  Worse yet, from this point on, since the\n> upstream discarded the track that contains A, the branch\n> downstream person has will _never_ converge to upstream branch,\n> even though the downstream person did _no_ development of his\n> own in the meantime.  This is *B*A*D*.\n\nWow.  Yeah.  Bad.\n\n> If there is a magic \"ours\" merge, the downstream person's\n> repository records A as the last tip on the tracking branch, and\n> git-fetch sees the updated head M is a descendant of it, so it\n> simply fast-forwards:\n\nThat's beautiful.  I get it.  This has been an\nextraordinarily helpful explanation (for me)!\n\nThank you!\n\njdl\n"},{"id":"17624","messageId":"441B2865.5090505@op5.se","threadId":"3654","inReplyTo":"1142623141.17536.225.camel@cashmere.sps.mot.com","subject":"Re: git-reset and clones","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-03-17T21:21:41Z","receivedAt":"2006-03-17T21:21:41Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"I'm in sort of shallow waters, hoping that Junio or Linus will come \nalong and pull me off the shores in case I mis-step and say something \nstupid that would have made an amusing pictograph had it been done right \nby a cartoonist.\n\nJon Loeliger wrote:\n> On Thu, 2006-03-16 at 20:10, Junio C Hamano wrote:\n> \n> \n>>You used to have something like this:\n>>\n>>\n>>                 o---o---o---A\n>>                /            ^ your HEAD used to point at here\n>>    ---o---o---o\n>>\n>>and you forgot other people already have the commit chain up to\n>>commit A.   But you rewound and did cleanups:\n>>\n>>                 o---o---o---A\n>>                /\n>>    ---o---o---o---o---o---B\n>>                           ^ your HEAD now points at here\n>>\n>>People who track your HEAD have A and your updated head B does\n>>not fast forward.  Oops.\n>>\n>>The recovery consists of two steps.  The first step is more\n>>important.  To find what commits you lost that others already\n>>may have.  You may be lucky and remember A's commit object name,\n>>but when I did that I had to ask around on the list X-<.\n>>\n>>The second step is a single command:\n>>\n>>\t$ git merge -s ours 'Graft the lost side branch back in' \\\n>>\t\tHEAD A\n>>\n>>where A is the object name of that commit.  On your current\n>>branch, this creates a merge commit between A and B (your\n>>current HEAD), taking the tree object from B.\n>>\n>>                 o---o---o---A\n>>                /             \\\n>>    ---o---o---o---o---o---B---M\n> \n> \n> Junio,\n> \n> Can you explain a bit more why the \"ours\" strategy\n> comes into play here?  I _think_ I understand, but\n> I'd like to hear a bit more explanation, please.\n> How is this different from just merging in A directly?\n> \n\n\"Ours\" is an algorithm you can invent yourself and pass as the defautl \nmerge strategy (useful if you know you'll always keep upstream as-is or \nsome such).\n\n> \n>>You want to keep the contents of the cleaned-up HEAD, so that is\n>>why you are taking the tree from B.\n> \n> \n> And the \"ours\" strategy effectively says, \"Favor the B\n> side of things when pulling in the A parts\", right?\n> \n\nYes, and/or no. \"Ours\"' is still whatever you want it to be. Perhaps we \nshould add some new strategies, like \"favour-current\" and \"favour-new\".\n\n> \n>>  With this commit M, you are\n>>telling the outside world that it is OK if they start from a\n>>commit on the now-recovered side branch.\n> \n> \n> This is mystical to me.  How is the \"A\" (ie, side branch)\n> now in a \"recovered\" state?\n> \n\nBecause the commits pullers already have are now inside the respository \nhistory, as seen by average pullers (again). The merge between \"master\" \n(or some such) and \"new-devel\" (or some such) happen to coincide, which \nmeans they share a mutual merge-base, which means they're both part of \nthe same chain of developemnt. If you intend to disimiss most of the \nchanges between (fork-point) and (point-of-new-weird-rebase) this might \nnot be the best solution, but...\n\n\nSorry, but to me this is friaday night and currently I can't logically \ndiffer between a bluewhale and a kangaroo [*1]\n\n/exon\n\n[1]\nSadly, this has been empirically proven. [*2]\n\n\n[2]\nAt some other time. I'm no *that* drunk right now.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"17678","messageId":"20060319214038.GF18185@pasky.or.cz","threadId":"3654","inReplyTo":"7v4q1x95yo.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-reset and clones","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-03-19T21:40:38Z","receivedAt":"2006-03-19T21:40:38Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Fri, Mar 17, 2006 at 03:10:23AM CET, I got a letter\nwhere Junio C Hamano <junkio@cox.net> said that...\n> You used to have something like this:\n> \n> \n>                  o---o---o---A\n>                 /            ^ your HEAD used to point at here\n>     ---o---o---o\n> \n> and you forgot other people already have the commit chain up to\n> commit A.   But you rewound and did cleanups:\n> \n>                  o---o---o---A\n>                 /\n>     ---o---o---o---o---o---B\n>                            ^ your HEAD now points at here\n> \n> People who track your HEAD have A and your updated head B does\n> not fast forward.  Oops.\n\nJust for the sake of completeness, this is a GIT-only doctrine; Cogito\nis more confiding and has less strict requirements.\n\nFirst, when fetching, it does not care at all whether the new head is a\nfast-forward of the original one or not.\n\nSecond, when the people who are tracking you had A as their current\nmaster head _and_ also the origin remote head (or whichever their\nrespective branch names are), their current master head will be updated\nto B when cg-updating, as Cogito pretends it to be a fast-forward even\nthough it is not.\n\nSo, in the simple tracking cases, Cogito will do the right thing, if you\nuse cg-update.\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"}]}