Re: rebase destroys branches

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Mar 05, 2013 at 02:05:32PM +1300, Gene Thomas [DATACOM] wrote:
> 
> >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.

See the dovcumentation for "git reflog"

> >All the content is still available until the logs expire.
> 
> So we will be unable to checkout content after a time?

You need to make a distinction between a user's local repository, and
the team's central repository.  The workflow of the individual user is
one where they can and should be allowed to use rebase and "git commit
--amend" if they like.  Consider this the same thing as the user who
chooses to use "quilt" on their local machine while they are preparing
their patches, so they are carefully honed before they are cast into
concrete.  Whether they use "quilt", or manual patching, or simply
don't bother checking things into the central SCM until things are
cleaned up, the end result is the same.

The team's central repository is one where you don't want to allow
history to be lost, and so there you can enforce rules to prevent
this.  For example, if you use Gerrit, you can limit the ability to
reset branches to administrators only.  Everyone else can only add new
commits, not change older ones.

(If someone accidentally checks in NDA'ed material belonging to
someone else, or some other IP content guaranteed to cause your
general counsel to have heart palpitations, trust me, you'll want to
allow administrators to rewind a git branch.  :-)

You can also use Gerrit to enforce code reviews, so that no change
goes in until a second engineer reviews the commit and gives it a
thumbs up (with a permanent record of the code review kept in Gerrit,
something which can be important for pointy-haired corporate types who
worry about Sarbanes Oxley controls --- although from your e-mail
address, you may be lucky enough to be exempt from needing to worry
about SOX controls :-).

Regards,

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]