From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4831 invoked by alias); 10 Oct 2013 05:13:20 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 4809 invoked by uid 89); 10 Oct 2013 05:13:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: rock.gnat.com 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; Thu, 10 Oct 2013 05:13:18 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id DFDD011666D; Thu, 10 Oct 2013 01:13:37 -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 tPu4RwrNP+Cp; Thu, 10 Oct 2013 01:13:37 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 8466B11658E; Thu, 10 Oct 2013 01:13:37 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id E3A66E0149; Thu, 10 Oct 2013 09:13:14 +0400 (RET) Date: Thu, 10 Oct 2013 05:13:00 -0000 From: Joel Brobecker To: Tom Tromey Cc: Binutils Development , GDB Development Subject: Re: src.git test repository Message-ID: <20131010051314.GI3066@adacore.com> References: <87y565m7ma.fsf@fleche.redhat.com> <87r4bu9mw3.fsf@fleche.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87r4bu9mw3.fsf@fleche.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2013-10/txt/msg00129.txt.bz2 > One note here is that I am still considering a hook to reject merge > commits. > > The rationale for this is that merge commits are ugly, and that it isn't > a big deal to require a rebase before a merge, so that any merge is a > fast-forward. This has my support. We've found at AdaCore that unexperienced users will often create merges unintentionally, and then push them without even ever noticing it. The typical case is forgetting to add --rebase in their "git pull" when they want to push a commit and find that their repo is out of date. There will be issues with special-feature development branches, however. Let's say, for instance, that people want to collaborate on a certain feature, and use a branch for its development. If development takes a while, they might want to do regular merges from HEAD... We can adjust the rule to say that merges are verbotten except on branches whose name is prefixed by Eg. "topic/". > I've done various test commits and pushes and I think these scripts are > working adequately well. Agreed. For future enhancements open for consideration (and I may actually take care of those myself), my only regrets are: - we seem to be getting one email per push, instead of one email per commit? - If we received one email per commit, we could put the subject of the commit as the subject of the email Something that should also be reasonably easy to implement: - Style check the revision log to forbid commits if the second line (line after subject) is not empty. I have found that this assumption is too ingrained everywhere in git, and that not respecting it makes things look bad. -- Joel