Home Original page

src.git test repository

Joel Brobecker brobecker@adacore.com
Thu Oct 10 05:13:00 GMT 2013 
> 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
More information about the Binutils mailing list