On Tue, 12 Feb 2008, Benny Halevy wrote:Hell no! No rebasing! If people rebase, then it's useless as a base. That base tree needs to be something people can *depend* on. It contains the API changes, and not anything else. Otherwise I will never ever pull the resulting mess, and you all end up with tons of extra work. Just say *no* to rebasing. Rebasing is fine for maintaining *your* own patch-set, ie it is an alternative to using quilt. But it is absolutely not acceptable for *anythign* else. In particular, people who rebase other peoples trees should just be shot (*). It's simply not acceptable behaviour. It screws up the sign-off procedure, it screws up the people whose code was merged, and it's just WRONG. Linus (*) The exception being if there is something seriously wrong with the tree. I think I've had trees which I just refused to pull, and while most of the time I just say "I refuse to pull", early on in git development I actually ended up fixing some of those trees up because my refusal was due to people mis-using git in the first place. So I have actually effectively rebased a maintainer tree at least once. But I still think it is seriously screwed up. --
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| David Woodhouse | [PATCH 1/3] firmware: allow firmware files to be built into kernel image |
| Linus Torvalds | Linux 2.6.21 |
| Parag Warudkar | BUG: soft lockup - CPU#1 stuck for 15s! [swapper:0] |
git: | |
| David Miller | [GIT]: Networking |
| Rick Jones | Re: Network latency regressions from 2.6.22 to 2.6.29 |
| Gerrit Renker | [PATCH 18/37] dccp: Support for Mandatory options |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
