From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 7697F1F4C0 for ; Fri, 25 Oct 2019 14:49:37 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:in-reply-to:message-id :references:mime-version:content-type; q=dns; s=default; b=VmWq2 gsKz9/FwzjXCR+q3gmgHBEQ+U1gNxtheA0TDQPIQEQdhg6XmfNNrbeTrsSQ+nudx nWJDnf3vDSZMMl+MDpylilX7bz/VJ5Jdb9TCSoyHzR3Dnnsk4VxscUn76I5a1xW0 1hOS7ykGKfSZW5V2O/pI223zpF7ihxdN4cOrX8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:in-reply-to:message-id :references:mime-version:content-type; s=default; bh=6CCUv4oETXq mO4giUEcminR7zj0=; b=r0HkbgeBuE6asWeEZiw7cfXgpfRgo+PfxhmFP0IUw3Q FlWoal0nQ6d0WTxA+a//p4Cg5NrExNFryqp2KmF7UPep/OXDVQWc3zqk53p47+oi TjJ8OhPHUccfk6UUpVeKgYIFfDsMhBlMYFYTv5gi1QQsR0rYCpxeV6ptkCrIdGuQ = Received: (qmail 108945 invoked by alias); 25 Oct 2019 14:49:05 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 108789 invoked by uid 89); 25 Oct 2019 14:48:57 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: esa3.mentor.iphmx.com IronPort-SDR: FZeENEVwgFN0h7JdVX5aQxHk1tXKbXKajA/bBXES7Gw8DtMcQn13uAa2nPVmBLOM6r/y3gAv94 JpqV8N5i0AxPrqCKw39/VPyvG9qrM0uMORTxpZ1PfFsKulqQo7G8psRMyXM1tCz9Cuz7rXFG16 cNxD22xfqyb+7omvg2tHZWwNWMb0DsZNcqOvzOmoa/fxV1Z2XKgft588DBL9x44BsD7v6fk7KI g6Xyt1B0/FebRcM72y9mp85JSoYweR35GlK+wHxRY3xyN51gio5wQs6l/kD12aFuelyX6y0YQ9 7wg= IronPort-SDR: btqpZkJYIvzc58LoRZz+7LoyYkZjU3nxmaJ1qSPWSpP/0JBu9Mnr3OTx0+g0K6oel2LYvKryGK z5WVjnb+PSlpF9rELCYgSVMFvX8yMgaxaiFRnzEkBJXEL5wS3c1kQXpOzbVe7tDhuBcuYwdayC VtZt0aUDPNoHI637XOTSQDjAAss28qN3QG1CnCbqa25jiFFvKqhMvC8J1mI6RhreKAbK2QfADy z1hLRJTH1RPcOpTwixpeUSMer27pSKD0E+ApX8XG9zpsbpoD9OKPOdqNiNiP5YoJHwARJdp+7Q 20E= Date: Fri, 25 Oct 2019 14:48:48 +0000 From: Joseph Myers To: Simon Marchi CC: Sergio Durigan Junior , Carlos O'Donell , libc-alpha , Jonathan Nieder Subject: Re: Setup non-pushing gerrit instance for glibc. In-Reply-To: Message-ID: References: <2e93ece9-386b-c587-9355-33a4695a3f02@redhat.com> <8b64d48f-3fd6-fa06-5b33-8daa97661fef@redhat.com> <87tv7xvaw7.fsf@redhat.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" On Thu, 24 Oct 2019, Simon Marchi wrote: > We'll maybe manage to do something a bit smarter, but I don't think we'll > easily be able to quote the _hunk_. This is where the mail is generated: I think the hunk - not just the new version of the code on its own - is critical information if someone is commenting on a particular part of a change, needed for such comments to be properly readable in context. > Also, remember that you can go put a comment on an unchanged section on the > file (e.g. to say "you forgot to update this call"), so there would be no > diff hunk to show for that comment anyway. In that case it should at least show a reasonable amount of context, with some indication of what function it is in, like in the diff hunk header. > They are naturally related due to them being git commits and having a > parent-child relationship. If I check out C, I'll automatically check > out its parent B and C. Gerrit doesn't see that as a series, just as > individual changes that are dependent on one another. There is a difference of *intent* between changes that depend on one another and a patch series. A patch series is saying: * there is a common purpose motivating the patches; and * some patches may best be understood by reference to ones later in the series (if e.g. one patch adds an interface that a later one adds users for), so the link to those later patches is important for review purposes. And so a patch series should be sent out to the list for review as such. There may be comments on the series as a whole, or on individual patches in it. There's also the variant of patch series that are explained in the cover letter (or in other text not intended for the final commit) as being split only for review purposes and intended to be squashed for commit, if the pieces most convenient for review don't form bisectable commits. I'm not sure how much any review system needs to know about the distinction between the two kinds of patch series if it's not pushing the commits itself. > Let's say I push a new version of C. A and B are still at their v1, > while C is at its v2. Then, if I push D on top of that, D will be at > its v1. > > Then, I (or even you!) could make a new change E on top of A, where E > would be unrelated to B, C and D (other than sharing A in their > ancestry). > > I can then decide to rebase A by itself (because master has moved on), > which will create a v2 of A. All the other changes will still be based > on the v1 of A. I will be able to rebase the other changes later on the > latest version of A, if I want to. All of this is perfectly meaningful for patch series - you can do [PATCHv2 3/3] and then potentially [PATCH 4/3] for D if it's intended as part of the series (or just a separate submission for D if it's not intended as part of the series). You can revise patch 1/3 with or without refreshing the whole series. -- Joseph S. Myers joseph@codesourcery.com