From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) 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_AU,HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD shortcircuit=no autolearn=ham autolearn_force=no version=3.4.0 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by dcvr.yhbt.net (Postfix) with ESMTP id 8F9AF1F43C for ; Mon, 13 Nov 2017 10:30:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752053AbdKMKaR (ORCPT ); Mon, 13 Nov 2017 05:30:17 -0500 Received: from pb-smtp1.pobox.com ([64.147.108.70]:58934 "EHLO sasl.smtp.pobox.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751391AbdKMKaQ (ORCPT ); Mon, 13 Nov 2017 05:30:16 -0500 Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 74B83B91BB; Mon, 13 Nov 2017 05:30:09 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=sasl; bh=A+o+DPnY1ndGljwaTp0eJRUUaBQ=; b=yUWbld sXIxUpaXC+dlkjQbqr42xUMD1LHrro7UMdmTIdOXpB0nOGg7z35OVEjUviw9UChq hnlOfe0hEmNWHz9BdmTM7CsJgI2S/YaSRZEg68pxEqSKLxCQo2JCEWckz7haIBQu JFDyNLBhtdmTA5FIjRbWp/rEGNK1fCjAogxTs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; q=dns; s=sasl; b=ACV9HRiSKxUnzSJA1LtkJdWQqomioKJW CgcY86g1PU9HlaRuzYwDgSne0+DqxiKfRORDFPEk4ftlBmqhuafMJScuqmBcdRUn J/4W0XRDjsGi+xEBlrVky2qlLksw3wc25DWjLE01zSLrPGNtkZ/MmP9waKx6QchC UK2y3a41GEg= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 6BE95B91BA; Mon, 13 Nov 2017 05:30:09 -0500 (EST) Received: from pobox.com (unknown [104.132.0.95]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id CFE90B91B7; Mon, 13 Nov 2017 05:30:07 -0500 (EST) From: Junio C Hamano To: Nicolas Morey-Chaisemartin Cc: git@vger.kernel.org Subject: Re: [RFC] cover-at-tip References: <357e8afb-4814-c950-1530-530bb6dd5f5a@suse.de> Date: Mon, 13 Nov 2017 19:30:06 +0900 In-Reply-To: (Junio C. Hamano's message of "Mon, 13 Nov 2017 18:48:58 +0900") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Pobox-Relay-ID: 9EBBC864-C85D-11E7-A4B8-8EF31968708C-77302942!pb-smtp1.pobox.com Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Junio C Hamano writes: > Nicolas Morey-Chaisemartin writes: > >> I agree this is a "am" job. Was just wondering if reusing some of >> the code from apply (and move it so it makes more sense) wouldnd't >> make more sense than rewriting a patch detection function. > > Yes, I understood that and have already given an answer, no? This was a bit too terse to be useful, so let me try again. I think the ideal endgame would be to allow people to come up with a topic branch of this shape (illustrated is a three-patch series on top of 'origin'): ---o---o (origin) \ 1---2---3 and then add an empty commit C whose log message is used to store "cover letter material", i.e. ---o---o (origin) \ 1---2---3---C (topic) And then you should be able to (1) merge such branch yourself, coming up with a history like this, where merge M uses material from C in the merge log message ---o---o---x---x---M \ / 1---2---3 (2) "git format-patch origin..topic" that would create the cover letter using material found in C in addition to the usual stuff (like shortlog) generated by "format-patch --cover", followed by these three patches. (3) "git format-patch M" should be able to (a) realize that M merges a side branch that is a three-commit series (i.e. M^1..M^2), and (b) notice that log message of M has human-readable description. Then it grabs the merge log message of M and do the same as (2). (4) "git am" the result from (2) or (3) should recreate the original history i.e. what we started with with C. ---o---o (origin) \ 1---2---3---C (topic) Now, I _think_ what the machinery needs a lot more is to be able to detect C is an empty commit (when doing (2)), and then you have quite a lattitude in designing what exactly such an automated cover letter looks like, so that the receiving end (4) can recognize it more easily and (more importantly) more robustly than "the message does not have any patch in it". Not all random messages that do not have a patch in it are cover letters, and that is why I do not think touching any code in the apply layer in an attempt to "reuse" anything is a bad idea. It will risk butchering the code without any real gain, because what we really need to know is *not* absence of patch, but presence of cover letter material. The simplest would probably be to notice that the subject of one has 0/N on it, while other messages were labeled with 1/N..(N-1)/N; that would be a lot stronger clue that 0/N has a cover than "it does not have any patch in it". It may be that we would not just want to identify which message is cover and which message is not, but which part of the cover letter message should go back to the log message of the capping empty commit (and moved to the merge log message). Just like we invented the conventions like scissors, three-dashes, etc., you might want to come up with a way to do so in your format-patch enhancement used to do the (2) and (3) above. Then it will be the matter of teaching that convention to "am" used in (4).