This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Merge commits and ChangeLog entries


Thomas Schwinge wrote:
> On Fri, May 15, 2009 at 11:49:18PM +0200, Jim Meyering wrote:
>> E.g., I'll be installing a so-called update hook to prohibit
>> pushing merge commits
>
> Why prohibit merge commits?  Sure, for a lot of scenarios they're not of
> any value, but for a number of other scenarios it is, in my opinion,
> helpful to see in which context a patch was created (i.e., which revision
> of the repository a patch was originally written for).

At least in the beginning, when switching from CVS, nearly everyone I've
spoken with has preferred to keep a linear "string of pearls" history for
"master".

This is to prevent the unnecessary merge commits that result from people
forgetting to rebase their local changes to latest head of master before
pushing them to the public repository.  The "bad" (unnecessary) merges
appear as e.g., diamonds or parallelograms, or worse in the graph you'd
see when running e.g., gitk.  With this hook in place, all new commits
on marked branches will be linear, i.e., each change set will have one
parent and one child.  Of course, if you really do want to push a merge
commit, it's easy to turn off the hook temporarily.

Sure, once everyone is more familiar with git and with manipulating
their own private topic branches, they may well opt to relax the
no-merge-commits-on-master constraint.  There are some fine work flows
that rely on merging branches.  Just look at the kernel's or git's own
git.git repository.

There are examples, explanation, how-to style things and discussion
on this thread from when we switched gnulib to git:

  http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/11266/focus=11268

FYI, here's the script I've been using to implement that policy:

http://git.et.redhat.com/?p=ovirt-release.git;a=blob_plain;f=git-hook/update;hb=refs/heads/vcs-admin

-------------
BTW, if you look at that script, you'll see it has another option:

  # hooks.allowbadwhitespace
  #   This boolean sets whether you may push a commit that adds bad whitespace.
  #   By default, you may not.

Consider whether you'd like that to be enabled in glibc.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]