From: Takashi Iwai <tiwai@suse.de>
To: Jan Kara <jack@suse.cz>
Cc: James Bottomley <James.Bottomley@hansenpartnership.com>,
ksummit-discuss@lists.linuxfoundation.org
Subject: Re: [Ksummit-discuss] [MAINTAINER SUMMIT] Distribution kernel bugzillas considered harmful
Date: Wed, 19 Sep 2018 11:27:37 +0200 [thread overview]
Message-ID: <s5hd0t9u99y.wl-tiwai@suse.de> (raw)
In-Reply-To: <20180919092343.GK10257@quack2.suse.cz>
On Wed, 19 Sep 2018 11:23:43 +0200,
Jan Kara wrote:
>
> On Wed 19-09-18 08:31:04, Takashi Iwai wrote:
> > On Wed, 19 Sep 2018 08:16:17 +0200,
> > Geert Uytterhoeven wrote:
> > >
> > > Hi Iwai-san,
> > >
> > > On Tue, Sep 18, 2018 at 10:37 PM Takashi Iwai <tiwai@suse.de> wrote:
> > > > On Tue, 18 Sep 2018 15:43:08 +0200,
> > > > Martin K. Petersen wrote:
> > > > > Sorry I'm a little late to the game here. Been out on vacation.
> > > > >
> > > > > > We order patches in our trees in the same git-topological-ordering as they
> > > > > > are upstream. It has a lot of benefits, most importantly: it doesn't
> > > > > > introduce artificial conflicts that don't exist in reality.
> > > > > >
> > > > > > In order to achieve that, we of course need 1:1 mapping between our
> > > > > > patches and upstream commits. Rebases destroy that mapping.
> > > > > >
> > > > > > And in some areas (scsi is one, but not the only one), we basically had no
> > > > > > other choice than considering maintainer's tree to be already "upstream
> > > > > > enough", without waiting for Linus' tree merge.
> > > > >
> > > > > When I discussed this with Johannes a little while ago, I suggested you
> > > > > guys used git patch-id to track patches instead of commit ids. That's
> > > > > how we track patches applied across many different trees internally.
> > > > > Works much better than using the upstream sha.
> > > >
> > > > What is git patch id? Is there any internal patch tag?
> > >
> > > It's the output of "git patch-id", which is a hash of the patch, without
> > > including its dependencies. This allows to match identical commits in
> > > different branches, and is what "git cherry" and "git rebase" use to detect
> > > already applied patches.
> > >
> > > Example (from v4.18.y):
> > >
> > > $ git show -s e496c9a4c17d4a97ed8d222f368f3b8ad8133fb9
> > > commit e496c9a4c17d4a97ed8d222f368f3b8ad8133fb9
> > > Author: Robert Munteanu <rombert@apache.org>
> > > Date: Tue Jun 19 11:20:40 2018 +0300
> > >
> > > HID: redragon: fix num lock and caps lock LEDs
> > >
> > > commit dc9b8e85ed95cbe7e3ad0eabb5b48d617bbc365e upstream.
> > >
> > > The redragon asura keyboard registers two input devices. The initial commit
> > > 85455dd906d5 ("HID: redragon: Fix modifier keys for Redragon Asura
> > > Keyboard")
> > > considered this an error and prevented one of the devices from registering.
> > > However, once this is done the num lock and caps lock leds no
> > > longer toggle on
> > > and off, although the key functionality is not affected.
> > >
> > > This commit removes the code that prevents the input device
> > > registration and restores the num lock and caps lock LEDs.
> > >
> > > Fixes: 85455dd906d5 ("HID: redragon: Fix modifier keys for
> > > Redragon Asura Keyboard")
> > > Signed-off-by: Robert Munteanu <rombert@apache.org>
> > > Signed-off-by: Jiri Kosina <jkosina@suse.cz>
> > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > >
> > > $ git show e496c9a4c17d4a97ed8d222f368f3b8ad8133fb9 | git patch-id
> > > 9d4546a92b459de7249748c0a38b50c989f13bd1
> > > e496c9a4c17d4a97ed8d222f368f3b8ad8133fb9
> > > $ git show dc9b8e85ed95cbe7e3ad0eabb5b48d617bbc365e | git patch-id
> > > 9d4546a92b459de7249748c0a38b50c989f13bd1
> > > dc9b8e85ed95cbe7e3ad0eabb5b48d617bbc365e
> > >
> > > So both commits are identical, as they have the same patch ID.
> >
> > Thanks for the explanation!
> >
> > This would help for identifying the rebased patch, yes. But it still
> > doesn't help for sorting as is. You cannot get the topology
> > information from the patch id, so you don't know the patch order,
> > either. (You can deduce the actual commit from the patch id, but it's
> > too heavy if you have 20,000 patches :)
>
> Actually we could use the patch id to identify new commit id of a rebased
> patch and infer proper ordering once we have the new commit id. So I think
> using patch id (additionally to commit id) would really help us and solve
> 95% of rebases of e.g. SCSI tree by our automation without human
> interaction.
Yes, we can use the patch id in addition to the commit id as
complementary information for tracking the upstream. I chatted with
people here now, and it seems feasible.
Thanks for the nice suggestion!
Takashi
next prev parent reply other threads:[~2018-09-19 9:27 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-05 10:13 [Ksummit-discuss] [MAINTAINER SUMMIT] Distribution kernel bugzillas considered harmful James Bottomley
2018-09-05 11:37 ` Mark Brown
2018-09-05 15:03 ` Paul E. McKenney
2018-09-05 15:50 ` Steven Rostedt
2018-09-05 16:20 ` Paul E. McKenney
2018-09-05 16:45 ` James Bottomley
2018-09-05 17:00 ` Paul E. McKenney
2018-09-05 19:25 ` Jiri Kosina
2018-09-05 19:40 ` James Bottomley
2018-09-06 19:54 ` Jiri Kosina
2018-09-18 13:43 ` Martin K. Petersen
2018-09-18 14:12 ` Geert Uytterhoeven
2018-09-18 15:01 ` Martin K. Petersen
2018-09-18 15:27 ` Christoph Hellwig
2018-09-18 15:34 ` Jens Axboe
2018-09-18 17:08 ` Mark Brown
2018-09-18 16:12 ` Mark Brown
2018-09-18 20:20 ` Takashi Iwai
2018-09-19 0:08 ` Mark Brown
2018-09-18 20:37 ` Takashi Iwai
2018-09-19 6:16 ` Geert Uytterhoeven
2018-09-19 6:31 ` Takashi Iwai
2018-09-19 9:23 ` Jan Kara
2018-09-19 9:27 ` Takashi Iwai [this message]
2018-09-05 13:16 ` Takashi Iwai
2018-09-05 13:20 ` Jiri Kosina
2018-09-05 13:39 ` Konstantin Ryabitsev
2018-09-05 15:16 ` Sasha Levin
2018-09-05 16:44 ` Laura Abbott
2018-09-05 20:15 ` Konstantin Ryabitsev
2018-09-05 20:36 ` Takashi Iwai
2018-09-07 20:24 ` Mauro Carvalho Chehab
2018-09-05 17:41 ` Laura Abbott
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=s5hd0t9u99y.wl-tiwai@suse.de \
--to=tiwai@suse.de \
--cc=James.Bottomley@hansenpartnership.com \
--cc=jack@suse.cz \
--cc=ksummit-discuss@lists.linuxfoundation.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 read-only IMAP folder(s) and NNTP newsgroup(s).