RoboTux wrote:
Oh, I think for my patches it's not worthwhile since at least they
compile and don't introduce regressions.
It's okay. True history is a value too. (Then again history is not
about truth really.)
I can see several risks and one limitation to this clean up:
- [risk] A push occurs between the check and the push -f
Yes, but I think it did happen only once in the past. And then the other
person was smart enough to re-push the patch later.
- [risk] Someone based his branch upon latest mob, and have to rebase his
work on the new clean commit (with something like git rebase --onto
origin/mob fork_commit hismob where fork_commit is the commit upon which
he based his branch hismob)
The same happens if someone else pushes while you are working on a patch.
Then before you push, you need to merge the other changes or rebase your
changes. People seem to prefer rebase (which is fine actually).
- [limitation] Can't do anything if a new commit was pushed on top on the
not clean one in between.
That is not true. You would simple cherry-pick (or rebase) these new
patches
onto the cleaned mob before you push (-f) it.
BUT, you need to be careful not to mess up other peoples' work.
Don't worry, I know all the consequences it could produce.
Great ;)
--- grischka
Thomas Preud'homme
_______________________________________________
Tinycc-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/tinycc-devel