From: "Nico Williams" <n...@cryptonector.com>
On Tue, Jul 29, 2014 at 4:58 AM, Sergei Organov <o...@javad.com> wrote:
Nico Williams <n...@cryptonector.com> writes:
That exception aside, keeping all local commits "on top" by always
rebasing them onto the upstream is extremely useful: a) in
simplifying
conflict resolution, b) making it easy to identify
as-yet-unintegrated
local commits, c) making it easy to contribute local commits.
But 'pull --rebase=preserve' does rebase local commits onto the
upstream, and result is exactly the same as 'pull --rebase=true',
unless
you have some of your own merges to be rebased. That's where the
difference between these two options appears. It's --rebase=false
that
performs merges rather than rebase.
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)
Philip
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
