[Twisted-Python] github, again

[Jonathan Vanasco]

On Jun 6, 2013, at 12:52 PM, Phil Mayers wrote:

> On 06/06/13 17:08, Jonathan Vanasco wrote:
> 
>> the only downside to git, is that once something goes onto the
>> server... it's there for good.  it's possible to rebase a repo back
>> to a specific commit , then replay without specific commits, and
>> "push -f" to overwrite the history... but if anyone updated against
>> the server, those commits will come back and haunt you.  over and
>> over and over again.
> 
> Yes. Never do this. It's hateful to fix, and rude to contributors!
> 
> (Obviously not an issue if your git repo will just be a read-only copy of SVN used to drive git-based code review tools)

It shouldn't ever happen in an Open Source project, or on "master" but in a corporate setting... you'd be surprised. 

	a - Someone accidentally commits and pushes a config file with credentials in it
	b - You have commits A,B,C,D,E.  D needs to be rebased out in order for a merge to successfully work.  You can't get rebase to work well, so you have to roll back to C, push -f, apply a diff from C-E ( which doesn't have D in it, all done by hand ), and then committed.  

Thankfully when someone brings this to you , you can say to your team "Ok.  everyone nuke your git repos and go to lunch.  i'll fix it for you".

That being said, i'm a HUGE fan of having an "upstream" repo that is only used for merging in changes, and everyone has their own fork to work on.   I'm not a fan of people working in branches on the 'source' at all.