From: "Nico Williams" <nico@xxxxxxxxxxxxxxxx>
On Tue, Jul 29, 2014 at 2:29 PM, Philip Oakley <philipoakley@xxxxxxx>
wrote:
From: "Nico Williams" <nico@xxxxxxxxxxxxxxxx>
Local merge commits mean that you either didn't rebase to keep all
your local commits on top of the upstream, or that you have multiple
upstreams (the example exception I gave).
Conversely, if you always rebase your local commits on top of the
upstream then you won't have merge commits to worry about.
Whilst it may not be "the Git Way", I'd expect that in many less well
informed companies, the need to keep merge commits fom other lines of
development would be quite a common (political ) technique where some
preparatory branch needs to be merged in before one's feature can be
completed (similar to all those cases on the list when folk say
'builds on
top of xy's commit deadbeaf)
The way we did this at Sun, first with Teamware, then later with
Mercurial, was as follows:
- "projects" kept their own clone repos of the upstream
- engineers working on a project cloned the project repo ("project
gate")
- engineers pushed/pulled to/from the project gate
- each project gate had a gatekeeper whose job it was to periodically
rebase onto the latest upstream
- then engineers would rebase onto the new project gate
No "merge turds" (Sun speak) were ever allowed in any upstream,
whether a project gate or the ultimate upstream. All commits had to
be organized according to specific rules, and squashed. These rules
applied at the project gate and in the upstream.
- when the project was ready for integration the gatekeeper would
rebase and squash as necessary, then push to the upstream
(I'm eliding some details. In particular when an intermediate
upstream rebased the previous head was left available as a "snapshot"
to make the equivalent of git rebase --onto possible.)
The upshot was: all local commits were always on top of whatever the
next upstream in the chain was. Always. No merge commits ever.
That workflow works just fine with git.
I'm not saying that it isn't a good technique and can work well. Rather
I'm saying we should be tolerant of the rules and techniques of others
who do have 'merges' in their workflow organisation. They may have a
very long QA delay between feature 'done' and feature 'done done tested
merged', which requires maintaining merges of done items that aren't yet
merged to master. Such techniques are more common in mixed engineering
than pure software environments (where engineering rules apply, and
software has to follow)
It worked really well at Sun
(with thousands of engineers working on Solaris alone). And it should
work well for anyone who doesn't have two or more forked upstreams to
follow.
I'm just cautious of an accidental one size fits all approach, so the
ability to rebase lines of development which contain merge commits
should be possible (with an appropriate and documented option) without
hidden traps.
Philip
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html