Messages in this thread | | | Date | Tue, 10 Jan 2012 22:27:11 +0000 | From | Mark Brown <> | Subject | Re: Regulator updates for 3.3 |
| |
On Tue, Jan 10, 2012 at 11:18:44AM -0800, Linus Torvalds wrote: > On Tue, Jan 10, 2012 at 10:45 AM, Mark Brown
> > Hrm, OK. These merges are all merges up of bug fixes for -rc from my > > own tree into the development code which I tend to do constantly to make > > it easier to work directly on the development branch. What's the best > > practice here - push things to you a bit more aggressively and wait > > until you've tagged a -rc and then merge that back up into the > > development branch?
> No. Just don't do the merges. If your development tree isn't stable on > its own, then there is something seriously wrong in what you do.
Just to be clear I'm not disagreeing that most if not all of these merges aren't needed, I'm just trying to figure out in general how to get the bug fixes into the development code when it is useful to do that. The merges are happening because I've been in the habit of merging fixes up as a matter of routine rather than due to an actual immediate need to get the fixes.
The major reason why the merges might be needed is that often enough to be interesting the stuff getting pushed into -rc is the result of fixing bugs that get discovered in the course of doing the new work and interfere with that new work. Either the testing needed to verify that work makes some existing issue (that might also be triggered in some other way) obvious or the bug got discovered by code inspection as someone was looking at a feature and so the two changes end up colliding with each other.
Especially in the cases where the lack of the bug fix breaks the new code it sems sensible enough to want to do the merges so that the history includes things that actually work. This was a lot easier back when there was no question of most embedded boards booting with vanilla mainline and you couldn't actually directly develop or test usefully with upstream code and working history wasn't an issue :/
> Just do this: > > gitk d52739c62e00..269d430131b6 > > to see what I actually got, and then look at what you did on Nov 27, > for example. You did *two* of the merges within hours of each other! > And then you had two more the very next day, without even having any > actual development in between! That's just crazy. The fact that you
Yes, it's excessive. I also made the above graph much more confusing by discarding my for-linus branch every time you merged it and making new ones based off new -rcs which means that gitk can't just show a for-linus branch that gets repeatedly merged into the development branch but instead shows a bunch of random isolated commits which get merged in. I'm not saying that this would solve the problem you see, just that it's an issue.
Clearly even if I did nothing beyond defer the merges until there was some need for them that'd help though it wouldn't fully address your issue. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |