{"thread":{"id":"33069","subject":"rebase destroys branches","startedAt":"2013-03-04T23:06:10Z","lastAt":"2013-03-05T21:39:06Z","messageCount":5,"participants":["Gene Thomas [DATACOM]","Philip Oakley","Theodore Ts'o"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"210596","messageId":"C057AC9B02D06A49810E9597C11F55BF14DFE51C9F@dnzwgex2.datacom.co.nz","threadId":"33069","inReplyTo":null,"subject":"rebase destroys branches","fromName":"Gene Thomas [DATACOM]","fromEmail":"gene.thomas@datacom.co.nz","sentAt":"2013-03-04T23:06:10Z","receivedAt":"2013-03-04T23:06:10Z","isPatch":false,"sender":{"key":"gene.thomas@datacom.co.nz","avatar":null},"body":"Hello,\n          I am evaluating git for use in a company. Please correct if I am wrong. I am concerned that an inexperienced developer could mistakenly rebase branches, destroying the original branch. Attached is a script (Windoze) that shows the 'topic' branch being moved!, after the rebase we are unable to see the original branch, read it's history or find it's commit points.\n\nSurely no operation should remove anything from the repository. Operations like this irreversibly break the repository . When rebasing the original branch must be retained.\n\nYours faithfully,\n\n\nGene Thomas.\n\n"},{"id":"210597","messageId":"64FF012BC4AF45C4A5067DE93FD9FE17@PhilipOakley","threadId":"33069","inReplyTo":"C057AC9B02D06A49810E9597C11F55BF14DFE51C9F@dnzwgex2.datacom.co.nz","subject":"Re: rebase destroys branches","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":null,"receivedAt":"2013-03-04T23:06:10Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Gene Thomas [DATACOM]\" <Gene.Thomas@datacom.co.nz>\nSent: Monday, March 04, 2013 11:06 PM\n>Hello,\n>I am evaluating git for use in a company. Please correct if I am wrong.\n>I am concerned that an inexperienced developer could mistakenly rebase\n>branches, destroying the original branch.\n\nThe original branch is not 'destroyed', rather the pointer to the \nprevious tip is within the logs. All the content is still available \nuntil the logs expire.\n\n>   Attached is a script (Windoze)\n>that shows the 'topic' branch being moved!, after the rebase we are\n>unable to see the original branch, read it's history or find it's \n>commit\n>points.\n\n>Surely no operation should remove anything from the repository.\n>Operations like this irreversibly break the repository . When rebasing\n>the original branch must be retained.\n\nIt's easy to misread some of Git's strengths if you have come from other \nhistoric corporate 'version control systems' which are often based on \ndrawing office practice of old (e.g. the belief there is a single master \nto be protected is one misconception for software).\n\nRebase, at the personal level, is an important mechanism for staff to \nprepare better code and commit messages. Trying to hide the reality will \njust make your management 'control' less effective as staff work around \nit and delay check-ins, etc.\n\nThe broader access control and repo management issues are deliberately \nnot part of Git, and there are good tools for that. e.g. Gitolite.\n\n>Yours faithfully,\n\n\n>Gene Thomas.\n\nPhilip\n"},{"id":"210601","messageId":"C057AC9B02D06A49810E9597C11F55BF14DFE5214F@dnzwgex2.datacom.co.nz","threadId":"33069","inReplyTo":"64FF012BC4AF45C4A5067DE93FD9FE17@PhilipOakley","subject":"RE: rebase destroys branches","fromName":"Gene Thomas [DATACOM]","fromEmail":"gene.thomas@datacom.co.nz","sentAt":"2013-03-05T01:05:32Z","receivedAt":"2013-03-05T01:05:32Z","isPatch":false,"sender":{"key":"gene.thomas@datacom.co.nz","avatar":null},"body":"Philip,\n        Thanks for your reply.\n\n>The original branch is not 'destroyed', rather the pointer to the previous tip is within the logs. \n\nIs that the 'git log' log or internal logs? Are you sure? There doesn't appear to be a way to checkout that tip of see the log back from that tip.\n\n>All the content is still available until the logs expire.\n\nSo we will be unable to checkout content after a time?\n\nGene Thomas.\n\n-----Original Message-----\nFrom: Philip Oakley [mailto:philipoakley@iee.org] \nSent: Tuesday, 5 March 2013 12:44\nTo: Gene Thomas [DATACOM]; Git List\nSubject: Re: rebase destroys branches\n\nFrom: \"Gene Thomas [DATACOM]\" <Gene.Thomas@datacom.co.nz>\nSent: Monday, March 04, 2013 11:06 PM\n>Hello,\n>I am evaluating git for use in a company. Please correct if I am wrong.\n>I am concerned that an inexperienced developer could mistakenly rebase \n>branches, destroying the original branch.\n\nThe original branch is not 'destroyed', rather the pointer to the previous tip is within the logs. All the content is still available until the logs expire.\n\n>   Attached is a script (Windoze)\n>that shows the 'topic' branch being moved!, after the rebase we are \n>unable to see the original branch, read it's history or find it's \n>commit points.\n\n>Surely no operation should remove anything from the repository.\n>Operations like this irreversibly break the repository . When rebasing \n>the original branch must be retained.\n\nIt's easy to misread some of Git's strengths if you have come from other historic corporate 'version control systems' which are often based on drawing office practice of old (e.g. the belief there is a single master to be protected is one misconception for software).\n\nRebase, at the personal level, is an important mechanism for staff to prepare better code and commit messages. Trying to hide the reality will just make your management 'control' less effective as staff work around it and delay check-ins, etc.\n\nThe broader access control and repo management issues are deliberately not part of Git, and there are good tools for that. e.g. Gitolite.\n\n>Yours faithfully,\n\n\n>Gene Thomas.\n\nPhilip\n"},{"id":"210603","messageId":"20130305022153.GA17878@thunk.org","threadId":"33069","inReplyTo":"C057AC9B02D06A49810E9597C11F55BF14DFE5214F@dnzwgex2.datacom.co.nz","subject":"Re: rebase destroys branches","fromName":"Theodore Ts'o","fromEmail":"tytso@mit.edu","sentAt":"2013-03-05T02:21:53Z","receivedAt":"2013-03-05T02:21:53Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Tue, Mar 05, 2013 at 02:05:32PM +1300, Gene Thomas [DATACOM] wrote:\n> \n> >The original branch is not 'destroyed', rather the pointer to the previous tip is within the logs. \n> \n> Is that the 'git log' log or internal logs? Are you sure? There doesn't appear to be a way to checkout that tip of see the log back from that tip.\n\nSee the dovcumentation for \"git reflog\"\n\n> >All the content is still available until the logs expire.\n> \n> So we will be unable to checkout content after a time?\n\nYou need to make a distinction between a user's local repository, and\nthe team's central repository.  The workflow of the individual user is\none where they can and should be allowed to use rebase and \"git commit\n--amend\" if they like.  Consider this the same thing as the user who\nchooses to use \"quilt\" on their local machine while they are preparing\ntheir patches, so they are carefully honed before they are cast into\nconcrete.  Whether they use \"quilt\", or manual patching, or simply\ndon't bother checking things into the central SCM until things are\ncleaned up, the end result is the same.\n\nThe team's central repository is one where you don't want to allow\nhistory to be lost, and so there you can enforce rules to prevent\nthis.  For example, if you use Gerrit, you can limit the ability to\nreset branches to administrators only.  Everyone else can only add new\ncommits, not change older ones.\n\n(If someone accidentally checks in NDA'ed material belonging to\nsomeone else, or some other IP content guaranteed to cause your\ngeneral counsel to have heart palpitations, trust me, you'll want to\nallow administrators to rewind a git branch.  :-)\n\nYou can also use Gerrit to enforce code reviews, so that no change\ngoes in until a second engineer reviews the commit and gives it a\nthumbs up (with a permanent record of the code review kept in Gerrit,\nsomething which can be important for pointy-haired corporate types who\nworry about Sarbanes Oxley controls --- although from your e-mail\naddress, you may be lucky enough to be exempt from needing to worry\nabout SOX controls :-).\n\nRegards,\n\n\t\t\t\t\t\t- Ted\n"},{"id":"210662","messageId":"BF397CFFF4D4468384AEB32BC18A0D2B@PhilipOakley","threadId":"33069","inReplyTo":"C057AC9B02D06A49810E9597C11F55BF14DFE5214F@dnzwgex2.datacom.co.nz","subject":"Re: rebase destroys branches","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":null,"receivedAt":"2013-03-05T21:39:06Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Gene Thomas [DATACOM]\" <Gene.Thomas@datacom.co.nz>\nSent: Tuesday, March 05, 2013 1:05 AM\n> Philip,\n>        Thanks for your reply.\n>\n>>The original branch is not 'destroyed', rather the pointer to the\n>>previous tip is within the logs.\n>\n> Is that the 'git log' log or internal logs? Are you sure? There\n> doesn't appear to be a way to checkout that tip of see the log back\n> from that tip.\n\nDouble checking the [rebase] manual page... [The ref] \"ORIG_HEAD is set\nto point at the tip of the branch before the reset.\"\n\nSo your original branch starts there (I just checked one of mine).\nObviously this is only for the machine that did the rebase, and only has\nthe last rebase tip. But then until it's pushed to an open repo no one \nknows ;-)\n\n>\n>>All the content is still available until the logs expire.\n>\n> So we will be unable to checkout content after a time?\n>\n> Gene Thomas.\n>\n> -----Original Message-----\n> From: Philip Oakley [mailto:philipoakley@iee.org]\n> Sent: Tuesday, 5 March 2013 12:44\n> To: Gene Thomas [DATACOM]; Git List\n> Subject: Re: rebase destroys branches\n>\n> From: \"Gene Thomas [DATACOM]\" <Gene.Thomas@datacom.co.nz>\n> Sent: Monday, March 04, 2013 11:06 PM\n>>Hello,\n>>I am evaluating git for use in a company. Please correct if I am\n>>wrong.\n>>I am concerned that an inexperienced developer could mistakenly rebase\n>>branches, destroying the original branch.\n>\n> The original branch is not 'destroyed', rather the pointer to the\n> previous tip is within the logs. All the content is still available\n> until the logs expire.\n>\n>>   Attached is a script (Windoze)\n>>that shows the 'topic' branch being moved!, after the rebase we are\n>>unable to see the original branch, read it's history or find it's\n>>commit points.\n>\n>>Surely no operation should remove anything from the repository.\n>>Operations like this irreversibly break the repository . When rebasing\n>>the original branch must be retained.\n>\n> It's easy to misread some of Git's strengths if you have come from\n> other historic corporate 'version control systems' which are often\n> based on drawing office practice of old (e.g. the belief there is a\n> single master to be protected is one misconception for software).\n>\n> Rebase, at the personal level, is an important mechanism for staff to\n> prepare better code and commit messages. Trying to hide the reality\n> will just make your management 'control' less effective as staff work\n> around it and delay check-ins, etc.\n>\n> The broader access control and repo management issues are deliberately\n> not part of Git, and there are good tools for that. e.g. Gitolite.\n>\n>>Yours faithfully,\n>\n>\n>>Gene Thomas.\n>\n> Philip\n>\n"}]}