Re: Use case (was Re: Should branches be objects?)

From: John Keeping <john@keeping.me.uk>
Date: Jun 24, 2014, 11:01 UTC
Message-ID: <20140624110127.GH28807@serenity.lan>
In-Reply-To: <CAK3OfOgskVKs=eUT+EM+GZOjh0p6gxKeDWH-iTt29P1i1d1iZA@mail.gmail.com>

On Mon, Jun 23, 2014 at 10:20:14PM -0500, Nico Williams wrote:

Show 9 quoted lines

> The Illumos repo, like OpenSolaris before it, and Solaris itself at
> Sun (and now at Oracle) requires that fixes be broken down into small
> commits, with related fixes, tests, and docs changes all typically in
> separate commits, but all pushed together, so that a single push of N
> commits is a logical set of changes (e.g., to be backed out together
> if, say, any one of them breaks a build).  With git the only way to
> record this grouping at push time is with a post-receive hook that
> does the recording (which is what the Illumos repo does, sending email
> to a list about all the commits pushed in one go).

Have you considered using merges for this instead? If each set of related changes is its own branch, then if you merge with `--no-ff` so that a merge commit is always created, you can identify the set of related changes with:

	git log ${MERGE_COMMIT}^1..${MERGE_COMMIT}^2

There are some interesting effects with reverting merge commits, particularly if you want to merge the same set of changes at a later date, but this seems like the "Git way" of identifying related commits.