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
[email protected]
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
