From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9661 invoked by alias); 20 Sep 2013 17:30:35 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 9647 invoked by uid 89); 20 Sep 2013 17:30:35 -0000 Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Fri, 20 Sep 2013 17:30:35 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: rock.gnat.com Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 68128116415; Fri, 20 Sep 2013 13:30:47 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dfHOR3cw8Ks9; Fri, 20 Sep 2013 13:30:47 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 33BFF1163F4; Fri, 20 Sep 2013 13:30:47 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 2683DE0FC2; Fri, 20 Sep 2013 10:30:32 -0700 (PDT) Date: Fri, 20 Sep 2013 17:30:00 -0000 From: Joel Brobecker To: Tom Tromey Cc: gdb-patches@sourceware.org, Binutils Development Subject: Re: RFC: git config and scripts Message-ID: <20130920173032.GT3132@adacore.com> References: <87siwzqw6w.fsf@fleche.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87siwzqw6w.fsf@fleche.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2013-09/txt/msg00776.txt.bz2 > This work consists of a few parts: > > * A modified copy of git's sample "post-receive" script, which I've > hacked to be able to send email to multiple commit lists based on > which directories were modified, and to send email to bugzilla when a > PR is mentioned in a commit message. > > * A modified copy of the loginfo script we use, with anything pertaining > to cvs removed, leaving just some bugzilla functionality. I further > modified this to look in multiple products for a bug, when desired. > > * The "src-email" file, some configury for src.git which tells > post-receive which directories correspond to which commit lists. > > * The git "config" file for src.git. Nice! > About the last part -- there are various settings we could have for > src.git. A few to consider: > > * I chose a relatively simple format for the commit email, and I kept > the format used for bugzilla the same. The format I chose mentions > the commit's URL, plus the "--pretty" log output (SHA, author, date, > and commit message). A pretty good first start to get us going! At AdaCore, we needed to have individual emails for each commit for internal reasons, and some of the reasons might actually apply to us (someone pushing multiple commits solving multiple PRs - would the email to bugzill cross-pollute the PRs?). The implementation we came up with is fairly complex, and is unfortunately difficult to share, because it depends on some internal python modules we developed to tie all our internal tools. And also there is the fact that it does not handle multiple projects sharing the same repository. I think I can give access to some of the code, even if I'm not super happy with it yet. That's why I am happy starting with what you wrote, see how it feels, before proposing anything. For completeness, we original used an adaptation of the git hooks used by GNOME, but I'd personally stay away from them. Really hard to adapt and improve, I thought. > * The appended config requires fast-forward pushes only. In archer > we've relaxed this, since we like to be able to rebase, but not > everybody likes that. I agree with that policy. If people want to do non-fast-forward changes on branches shared with others, they can always host it themselves. Alternatively, what we have done at AdaCore is allow rebasing on all branches named "topic/*". We have a second mechanism that allows us to configure repositories to accept rebasing on specific branches, but I don't think we ever used it. > * Other projects have "update" hooks to do things like reject merge > commits to master, or reject commits that introduce trailing > whitespace. Some good ideas for our next rainy day... I'm not sure about rejecting merges or not, but rejecting trailing whitespaces would be helpful, I think. Ever since I adapted my editor to highlight them, it's been bugging me :-). -- Joel