[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Tinycc-devel] Cleaning mob [Was Several patchs from Debian packaging]

From: RoboTux
Subject: [Tinycc-devel] Cleaning mob [Was Several patchs from Debian packaging]
Date: Tue, 20 Apr 2010 23:41:06 +0200
User-agent: KMail/1.12.4 (Linux/2.6.32-3-amd64; KDE/4.3.4; x86_64; ; )

Le mardi 20 avril 2010 23:21:19, grischka a écrit :
> RoboTux wrote:
> > ... When upgrading
> > master to mob, do you simply merge mob in master or do you clean up
> > things and squash commits ?
> Well, I might cleanup some things or simply drop e.g. buggy patches,
> but you can do that too if you want to (and I'd appreciate that).
So when you update master, as some commit are dropped or modified, all SHA1 in 
mob are changed. Now I understand why mob must be forked-pushed-destroyed each 
time one wants to work on it.
> Basically you would create a new branch, say "clean-mob" with your
> cleaned-up patches (e.g. one instead of three) and of course also
> with the patches from the other people.
> Then you would check equality, e.g. using
> $ git diff mob clean-mob
> There should be no differences.
> Then you can delete your old "mob" and rename "clean-mob" to "mob"
> Then you should check that no one else has committed new patches
> to the public "mob" in between.
> And then you could replace the public mob with your new version,
> using "git push --force ..."
Oh, I think for my patches it's not worthwhile since at least they compile and 
don't introduce regressions. I can see several risks and one limitation to 
this clean up:
- [risk] A push occurs between the check and the push -f
- [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)
- [limitation] Can't do anything if a new commit was pushed on top on the not 
clean one in between.
> BUT, you need to be careful not to mess up other peoples' work.
Don't worry, I know all the consequences it could produce. I won't use this 
possiblity I think.
> > Thomas Preud'homme
> --- grischka
Thomas Preud'homme

Attachment: signature.asc
Description: This is a digitally signed message part.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]