Re: [GIT PULL] xfs: updates for 3.18-rc1

[Linus Torvalds]

On Sun, Oct 12, 2014 at 9:37 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote:
>
> i.e. I have generated this pull-req from the base tree I've been working
> on (3.17-rc2) but there have already been commits merged into a more
> recent upstream tree (3.17-rc4) in this tree. When I generate the
> pull request from the underlying 3.17-rc2 branch, it includes all
> those commits, both in the summary and the diffstat. If I base the
> pull request off 3.17, the base commit is the last one that was
> merged into your tree, and the diffstat and commit list reflect
> that.

That's fine, and works for me too. This is normal and expected for
stuff that has gotten into my tree other ways (ie bugfixes that were
cherrypicked to be backported from development trees etc).  I'm used
to it, and while I hope people minimize it (not only because of
multiple commits showing up with the same patch, but because it can
easily cause stupid merge conflicts because the development tree then
made further changes on top of the same patch), it's also very much
considered "normal development".

That said, when there are actual *common* commits as in your case (as
opposed to cherrypicked commits that generate duplicate commits with
the same patch), I would generally suggest you just let "git
merge-base" figure it all out from my latest tree. That way it takes
into account the stuff that you sent earlier on its own.

But this is not a big deal.

> So my question is this: Which tree should I generate the pull
> request from? I flipped a coin an generated this one from 3.17-rc2,
> but if you'd prefer to see just the commits/diffstat that aren't in
> your tree, let me know and I'll do it differently next time....

Normally, I'd suggest the easiest way to handle things is to have a
"linus" branch that tracks my upstream, and then just generate the
pull request off that. Git will figure out the latest merge base and
just do the right thing, and you don't need to really think about
where you forked things off, and which parts you have already sent to
me.

As mentioned, even then the diffstat doesn't always end up being
exactly right, because the history with partially merged branches, and
with potential cherry-picked commits. So I am not surprised or upset
if the diffstat doesn't always match, it happens quite commonly. I go
on a rant when that i sdue to bad development practices, but I don't
see anything like that in your tree.

Some people avoid this by actually generating a test-merge (to warn me
about upcoming conflicts etc), and then generate the diffstat from
that test merge instead of just using the plain "git diff" in the
git-pull-request helper scripts. Whatever works. This is not a huge
deal, exactly because it's "normal development" (unlike the
back-merges issue).

And in this case, it looks like you don't even have cherry-picks, but
just shared common branches, some of which you sent earlier. It looks
like the diffstat if you just use my current tree as the other point
of the git merge-base is correct, although I haven't actually done the
merge itself yet (still waiting for the build for the previous merge
to finish).

                Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/