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.
_______________________________________________
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
