This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: A wrong commit


> Thanks for the explanation and tips, Roland and Marek.
> I should be more cautious next time.

Yes.  No harm done this time.  But it goes without saying that anyone
granted git write access is expected to be very circumspect in using
'git push'.  I'm a fairly seasoned git user, but I still double-check
things before pushing most of the time.  A good way to be paranoid
is to run 'git push --dry-run'.  It will print something like:
	To ssh://roland@sourceware.org/git/glibc.git
	   8e47560..1cac723  master -> master
Then run 'git log 8e47560..1cac723' and verify that only the commits
you intend are in the range.

That said, one of the reasons we have a version control system is so that
we can always recover from such errors.  So don't fret overmuch.  But we
would like to avoid useless pollution and reversions in the history.  

The only truly catastrophic case would be something like pushing commits
that contain code whose copyright is not properly assigned (or perhaps just
adding enormous amounts of data that extremely bloated the repository size
everyone has to download).  If that ever happened, then someone like me
would go in, manually reset the history to the last good point, and then
replay the good commits without the bad ones.  That would be a hassle for
everybody who had fetched the bad state into their local git repositories,
as well as being a tedious and dangerous task for the person saddled with
fixing the state on sourceware.  Let's hope such a case never arises.


Thanks,
Roland


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]