From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 7274BDD9 for ; Fri, 23 Aug 2019 19:08:50 +0000 (UTC) Received: from mail-qk1-f194.google.com (mail-qk1-f194.google.com [209.85.222.194]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E14487FB for ; Fri, 23 Aug 2019 19:08:49 +0000 (UTC) Received: by mail-qk1-f194.google.com with SMTP id p13so9092670qkg.13 for ; Fri, 23 Aug 2019 12:08:49 -0700 (PDT) MIME-Version: 1.0 References: <20190823013619.GA8130@mit.edu> <20190823151843.GH8130@mit.edu> <20190823161947.GA112509@dtor-ws> In-Reply-To: From: Joel Fernandes Date: Fri, 23 Aug 2019 15:08:36 -0400 Message-ID: To: Doug Anderson Content-Type: text/plain; charset="UTF-8" Cc: Barret Rhoden , ksummit , Greg Kroah-Hartman , Jonathan Nieder , Tomasz Figa , Han-Wen Nienhuys , Theodore Tso , David Rientjes , Dmitry Torokhov , Dmitry Vyukov Subject: Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Fri, Aug 23, 2019 at 2:00 PM Doug Anderson wrote: [snip] > > On Fri, Aug 23, 2019 at 12:45 PM Doug Anderson wrote: > > [snip] > > > Sure, if a given patch in the series is totally wrong and I re-write > > > it (but still want the re-write to be considered a new version of the > > > previous patch) then I have to manually copy the Change-Id for a > > > gerrit upload. ...but I'd also be OK if people just get a new > > > Change-Id in this case. > > > > Sometimes it is not "totally wrong" but just "done in a different > > away" and is a new series. This happens a lot since upstream > > development can be evolutionary. So your v1 may look nothing like v2 > > and is a whole new series. Yet the history linking the 2 series is > > important. And no amount of automated commit ID generation can link > > them. This is the scenario I was talking about. I know the git hook > > works, but sometimes the Change-Id has to be manually copied. That's > > not automatable. May be we are slightly on different tracks, but this > > is the scenario that would be useful to trace IMO. > > Agreed that it would be useful and (personally) I'd do it. Maybe > others who are used to the gerrit workflow would also do it. ...but > what I like is that the fallback for those that don't try to hard > isn't that terrible. Yes they'd end up with a new Change-Id in some > cases, but presumably it still wouldn't be that hard for tools to help > you. Namely, if you have a series: > > Patch v1 1/3 - Add a frob - Change-Id A > Patch v1 2/3 - Add a larb - Change-Id B > Patch v1 3/3 - Use the frob to tweak the larb - Change-Id C > > ...and you decide that you should be tweaking a sneech instead of a > larb, you might end up with this if someone isn't careful to copy > Change-Ids and their workflow is to throw away the old patch #2 and #3 > instead of amending. > > Patch v2 1/3 - Add a frob - Change-Id A > Patch v2 2/3 - Add a sneech - Change-Id D > Patch v2 3/3 - Use the frob to tweak the sneech - Change-Id E > > So you can't find v1 of patch #2 directly from v2 of patch #2. > ...but, a good tool could still help you here. It would see that at > least one patch in this series had the same Change-Id and it should > help you find the whole v1 series. > > If all 3 patches were all totally new and lost Change IDs then I guess > you're SOL, but maybe in that case it really should be considered a > new series anyway? Maybe it should be. It is hard to generalize it to work all the time. But I agree with you the above flow is better than nothing. It does seem people need more convincing here though, that inserting a unique ID into a commit message is acceptable. Another thing that could be done is, have the git hook insert the whatever-ID into the discardable part of the patch. The archive will then have it even if the commit doesn't. Then something email2git or patchwork can connect different patches in the archive with a particular commit. I think Thomas Gleixner or someone else also proposed something similar in this thread. What's wrong with that idea? thanks, - Joel