linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Ingo Molnar <mingo@kernel.org>
Cc: Will Deacon <will@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux ARM Kernel Mailing List 
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [GIT PULL] arm64: Fixes for -rc4
Date: Mon, 21 Oct 2019 07:45:11 -0400	[thread overview]
Message-ID: <CAHk-=wgxm_w-BCEuBOFnRpTwQuCYwMtsDNz3cW0MDGEmQZTUGg@mail.gmail.com> (raw)
In-Reply-To: <20191021064658.GB22042@gmail.com>

On Mon, Oct 21, 2019 at 2:47 AM Ingo Molnar <mingo@kernel.org> wrote:
>
> I think at least once I ran into that and sent you a 'slightly wrong'
> diffstat - and maybe there's also been a few cases where you noticed
> diffstats that didn't match your merge result, double checked it yourself
> and didn't complain about it because you knew that this is a "git
> request-pull" artifact?

Right. If I see a diffstat that doesn't match, I just look at what a
non-merged diffstat would have looked like, and if that matches I know
what happened.

There are other reasons why diffstats won't match, of course. Like me
just having merged part of the same commits from another source (or
multiple trees applying the same patch). So it's not _just_ due to
multiple merge bases that the mis-match can happen.

> Most of the time I notice it like Will did because the diffstat is
> obviously weird and it's good to check pull requests a second (and a
> third :-) time as well, but it's possible to have relatively small
> distances between the merge bases where the diffstat doesn't look
> 'obviously' bogus and mistakes can slip through.

Yup.

> Anyway, a small Git feature request: it would be super useful if "git
> request-pull" output was a bit more dependable and at least warned about
> this and didn't include what is, from the viewpoint of the person doing
> the merge, a bogus diffstat.

Well, warning for it would be fairly simple. Giving the "right" result
isn't simple, though, since the merge might need manual fixup to
succeed.

The warning you can check yourself: just do

    git merge-base --all upstream mybranch

and if you get more than one result, you know you are in the situation
where a diff from the merge base might not work (it *might* work, but
probably won't).

You can play around with it yourself, of course. Look at the
git-request-puill.sh script, it says something like this:

  merge_base=$(git merge-base $baserev $headrev) ||
  die "fatal: No commits in common between $base and $head"

and you could add something like

  all_merge_bases="$(git merge-base --all $baserev $headrev)"

and then add a warning if "all_merge_bases" doesn't match "merge_base".

                Linus

  reply	other threads:[~2019-10-21 11:45 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-17 23:43 [GIT PULL] arm64: Fixes for -rc4 Will Deacon
2019-10-18  0:06 ` Linus Torvalds
2019-10-18 17:41   ` Will Deacon
2019-10-18 19:17     ` Linus Torvalds
2019-10-21  6:46       ` Ingo Molnar
2019-10-21 11:45         ` Linus Torvalds [this message]
2019-10-22  8:16         ` Uwe Kleine-König
2019-10-18  0:15 ` pr-tracker-bot
2019-10-18 20:09 ` Jayachandran Chandrasekharan Nair
  -- strict thread matches above, loose matches on Subject: below --
2023-01-13 10:29 [GIT PULL] arm64 fixes " Will Deacon
2023-01-13 13:58 ` pr-tracker-bot
2022-09-02 11:12 Will Deacon
2022-09-02 18:30 ` pr-tracker-bot
2022-04-22 11:20 Will Deacon
2022-04-22 21:19 ` pr-tracker-bot
2021-12-03 13:19 Will Deacon
2021-12-03 18:53 ` pr-tracker-bot
2020-11-13 12:39 GIT " Will Deacon
2020-11-13 12:44 ` [GIT " Will Deacon
2020-11-13 17:25   ` Linus Torvalds
2020-07-04 13:05 Will Deacon
2020-07-05 17:35 ` pr-tracker-bot
2019-06-07 15:13 [GIT PULL] arm64: " Will Deacon
2019-06-07 16:45 ` pr-tracker-bot
2019-04-05 17:17 [GIT PULL] arm64 " Catalin Marinas
2019-04-05 23:50 ` pr-tracker-bot
2018-09-14 16:19 [GIT PULL] arm64: " Will Deacon
2017-12-15 18:31 Will Deacon
2017-08-04 18:32 Will Deacon
2016-06-17 17:07 Will Deacon
2015-05-14 15:48 Will Deacon
2015-01-09 15:22 Will Deacon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHk-=wgxm_w-BCEuBOFnRpTwQuCYwMtsDNz3cW0MDGEmQZTUGg@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).