Messages in this thread |  | | Date | Thu, 5 Apr 2018 20:04:41 +0100 | From | Mark Brown <> | Subject | Re: [GIT PULL] sound updates for 4.17-rc1 |
| |
On Thu, Apr 05, 2018 at 10:50:26AM -0700, Linus Torvalds wrote:
> Mark, we talked about this already. YOU ARE DOING SOMETHING HORRIBLY > WRONG. You already admitted to automated merging, I already told you > not to do that.
Ah, sorry - my impression was rather that the issue was the mess caused by the history being too complex for git to eliminate null merges. IIRC you didn't say much when I explained what the automation is there for which I (apparently incorrectly) took as as being OK with the automation, just not the results it ended up doing in that particular pull request.
> I'm attaching a screenshot of part of this to give as an example of > what I see when I pull.
I agree it's not super lovely.
I looked at the image and also rechecked the history I'm seeing in gitk and I didn't spot cases where one topic branch was merged more than once though it's possible I missed something. I do see a couple of cases where I merged the fix branch up into the topic branch more than once in order to resolve some conflicts that'd otherwise have been painful for anyone working on things, and one case where I applied a fix twice for some reason. There *are* a very large number of commits with very similar subject lines sitting in branches but I'm not seeing any instances of the previous problem, AFAICT it's that there's lots of branches since Morimoto-san ended up touching almost every driver and I put them on per-driver branches like I usually do.
> STOP MERGING THE SAME BRANCHES OVER AND OVER AGAIN, DAMMIT!
> If you have merged a branch once, don't do it again tomorrow.
Just to be clear the merges I did one day get thrown away the next if they weren't included in a pull request, the scripts only try to merge anything once and are done this way mainly to try to avoid generating pull requests which have incremental merges of the same branch.
I'm a little bit confused about what's best to do here. The reason I'm throwing the merge away and redoing it is that you've previously said that you don't want to see main development branches that contain nothing but long strings of merges, if I keep the same set of branches and just do the merges incrementally every time a branch is added or changes then there'd be even more merges which I'm pretty sure you wouldn't be at all happy with either.
I could also just stop doing topic branches but that makes any cross tree merges that need doing painfully big, this was why I started doing topics so much. I could go half way to that and try to figure out in advance which things will end up needing cross tree merges but that never worked out that well in the past. I suppose I could also just duplicate commits to make the topic branches if things need cross tree merges after the fact, that's not great either though it does make for a minimal number of branches while avoiding messy cross tree merges.
In the absence of any other feedback I guess I should just stop using topic branches so much and go back to putting everything I don't explicitly know will need a cross tree merge on just one fixes and one -next branch and hope we don't need too many cross tree merges I didn't anticipate. Or possibly keep the fixes branches since they do get individually used much more often and there's far fewer of them. [unhandled content-type:application/pgp-signature] |  |