{"thread":{"id":"6636","subject":"Re: Why is it bad to rewind a branch that has already been pushed out?","startedAt":"2007-02-03T08:42:47Z","lastAt":"2007-02-03T09:04:54Z","messageCount":2,"participants":["linux@horizon.com","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"33435","messageId":"20070203084247.13894.qmail@science.horizon.com","threadId":"6636","inReplyTo":null,"subject":"Re: Why is it bad to rewind a branch that has already been pushed out?","fromName":"","fromEmail":"linux@horizon.com","sentAt":"2007-02-03T08:42:47Z","receivedAt":"2007-02-03T08:42:47Z","isPatch":false,"sender":{"key":"linux@horizon.com","avatar":null},"body":"You're quite right that git's basic history model won't get\nconfused, just the users might be.\n\nThe basic problem is that, if you rewind your series from j to j^,\nand Alice has already fetched it, she'll get an error when she tries to\nfetch it again and git notices that j -> h is not a fast-forward.\n\nIt's not the error per se that's the problem, but the potentially\nconfusing condition that git fetch justifiably refuses to let you\nget into without explicit authorization.\n\nHeck, it could be a security breach, which is the main reason that\nit's an error and not a warning.\n\nIt won't confuse git, but might confuse Alice.\n\nHow about:\n\n Be careful with that last command: in addition to losing any changes\n in the working directory, it will also remove all later commits from\n this branch.  If this branch is the only branch containing those\n-commits, they will be lost.  (Also, don't use \"git reset\" on a\n-publicly-visible branch that other developers pull from, as git will\n-be confused by history that disappears in this way.)\n+commits, they will be lost.  Also, avoid using \"git reset\" on a\n+publicly-visible branch that other developers have pulled from,\n+because git (deliberately) has no way to \"pull back\" the commits\n+they've already seen.  Git can cope with the resultant mess, but\n+it can be confusing.\n"},{"id":"33436","messageId":"7vzm7v7gsp.fsf@assigned-by-dhcp.cox.net","threadId":"6636","inReplyTo":"20070203084247.13894.qmail@science.horizon.com","subject":"Re: Why is it bad to rewind a branch that has already been pushed out?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-03T09:04:54Z","receivedAt":"2007-02-03T09:04:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"linux@horizon.com writes:\n\n> The basic problem is that, if you rewind your series from j to j^,\n> and Alice has already fetched it, she'll get an error when she tries to\n> fetch it again and git notices that j -> h is not a fast-forward.\n\nWell, if you do a pull without tracking branch, like Linus seems\nto do, there is no non-fast-forward error.  Also, repositories\nprepared with git-clone from 1.5.0 by default will have tracking\nbranches of forcing kind.  I.e. the fetch configuration will\nspecify tracking with '+' in front:\n\n\t[remote \"origin\"]\n\t\tfetch = +refs/heads/*:refs/remotes/origin/*\n\nso non-fast-forward check will not trigger in general.\n\n> It won't confuse git, but might confuse Alice.\n\nI think I should have made it more obvious, but the emphasis of\nmy proposed rewording is not about removing the word \"git gets\nconfused\" in order to defend git.\n\nIt is very likely to confuse Alice (especially if she did not\nhave any 'a' commits), having to do the merge.  But I think the\nconfusion is just a symptom, and the real disease lies\nelsewhere.  The real disease is that it is wrong for me to force\nthe merge on Alice, from the workflow perspective, and that is\ntrue even if we were lucky and Alice did not get confused about\nthe merge (e.g. 'j' and 'h' series did not have anything\nrelated, and/or 'a' really fixed up 'j').  In any case, Alice\nshould not to have to worry about what happened between 'j' and\n'h' forks, and I think the document should emphasize that point.\n"}]}