Re: rebase destroys branches

From: Philip Oakley <philipoakley@iee.org>
Date: Mar 5, 2013, 21:39 UTC
Message-ID: <BF397CFFF4D4468384AEB32BC18A0D2B@PhilipOakley>
In-Reply-To: <C057AC9B02D06A49810E9597C11F55BF14DFE5214F@dnzwgex2.datacom.co.nz>

From: "Gene Thomas [DATACOM]" <Gene.Thomas@datacom.co.nz>
Sent: Tuesday, March 05, 2013 1:05 AM

Show 9 quoted lines

> Philip,
>        Thanks for your reply.
>
>>The original branch is not 'destroyed', rather the pointer to the
>>previous tip is within the logs.
>
> 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.

Double checking the [rebase] manual page... [The ref] "ORIG_HEAD is set to point at the tip of the branch before the reset."

So your original branch starts there (I just checked one of mine). Obviously this is only for the machine that did the rebase, and only has the last rebase tip. But then until it's pushed to an open repo no one knows ;-)

Show 54 quoted lines

>
>>All the content is still available until the logs expire.
>
> So we will be unable to checkout content after a time?
>
> Gene Thomas.
>
> -----Original Message-----
> From: Philip Oakley [mailto:philipoakley@iee.org]
> Sent: Tuesday, 5 March 2013 12:44
> To: Gene Thomas [DATACOM]; Git List
> Subject: Re: rebase destroys branches
>
> From: "Gene Thomas [DATACOM]" <Gene.Thomas@datacom.co.nz>
> Sent: Monday, March 04, 2013 11:06 PM
>>Hello,
>>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.
>
> The 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.
>
>>   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.
>
>>Surely no operation should remove anything from the repository.
>>Operations like this irreversibly break the repository . When rebasing
>>the original branch must be retained.
>
> It'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).
>
> Rebase, 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.
>
> The broader access control and repo management issues are deliberately
> not part of Git, and there are good tools for that. e.g. Gitolite.
>
>>Yours faithfully,
>
>
>>Gene Thomas.
>
> Philip
>