On Wed, Jul 25, 2012 at 7:10 PM, Jeff Garzik <jgarzik@xxxxxxxxx> wrote:
>
> Thanks, so noted. I guess if the merge gets more complex than something
> easily described in an email, that implies that maintainers should do more
> cross-coordination and maybe a merge tree.
It's fairly rare. It happens mostly with the arch trees for some
reason - the ARM tree used to be an unholy mess.
And then we have the small "oops, we didn't even notice" things when
some driver (or FS) interface changes, and we have a new driver/fs or
just extended an old one, and there's a subtle conflict. And people
miss those, and quite frankly, it's not a huge deal. We can fix it up
later. It's the "oh, I knew about this" cases where it's fixed up as a
separate commit I dislike.
And quite frankly, I really do a lot of merges, and over the history
of git we have not had all that many really complicated ones. I
commonly send people email saying "ok, this clashed, you need to
double-check my merge", but it's not common that they are really
problems.
So to a first approximation, I'd actually prefer that submaintainers
not care *at*all* about whether something clashes upstream or not. If
there are consistent and problematic clashes, that implies some deeper
problem, and the solution to that is not "let's pre-merge", but rather
more along the lines of "we're doing something wrong, maybe our
interfaces are crap, or our modularity is wrong, let's think about
it".
And for subsystems where we have had problems, it's actually really
nice if the maintainer sends me the unmerged "this is the work I've
done" tree, and then perhaps has a separate "xyzzy-merged" branch that
has a pre-merged version. For cases like that, I will do the merge
myself, but I'll actually double-check my merge against the maintainer
merge. And it's happened more than once that my merge has differed,
and _my_ merge is the correct one. The maintainer may know his code
better, but I know my merging. I do a ton of them.
For example, this week I've done 66 merges, and 15 of them had
conflicts. Of the 15, only two were interesting iirc, but even those
weren't really "problematic", they were just enough to trigger me to
send out emails to the maintainers about them. And I don't think your
libata merge would really have merited even that, apart from the small
semantic thing (which would also have been trivial with a oneliner
"heads up, check out the semantic change in xyz.c:abcdef()".
> What's the best way for libata to move forward, now that this hideous merge
> has been pushed out to the Well Known libata branches? The
> pre-jgarzik-merge commit you would have pulled is
> dc7f71f486f4f5fa96f6dcf86833da020cde8a11 had my pull request been proper.
I'll take your merge, it's not like it's a huge problem. What I care
most about is the "flow", and I am making a stink just so that this
doesn't become a common issue. We have tons of ugly history, and I'm
not black-and-white - problems happen. Big deal. I just want to make
sure that they don't become systemic.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
