git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Strange git merge behaviour with empty branches
@ 2012-03-19 18:53 Will Deacon
  2012-03-19 19:51 ` Junio C Hamano
  0 siblings, 1 reply; 2+ messages in thread
From: Will Deacon @ 2012-03-19 18:53 UTC (permalink / raw)
  To: git

Hello git people,

I'm seeing some strange behaviour with git merge and wondered if you could
help me to understand what's going on.

Say I have a master branch tracking upstream and a few local branches based
off that:

$ git branch
  master
  foo
  bar
  baz

Furthermore, let's say that both foo and bar are currently at master (that
is, they have no additional commits) but baz does have changes committed on
top of master.

Now, if I make an integration branch:

$ git checkout master -b integration

I can then merge foo, bar and baz into this:

$ git merge foo bar baz

which works fine. However, specifying the non-empty branch first does:

$ git merge baz foo bar
Already up-to-date.

and the changes from baz are not merged in. For extra weirdness, if you
have another non-empty branch (qux) and do:

$ git merge baz foo bar qux

Then you end up with a branch that *doesn't* contain baz, *does* contain
qux and has a weird looking merge-commit message that just reads "baz"!

Now, I appreciate that merging in empty branches might seem weird but it's
sometimes useful if you have scripts that take a set of known branches, merge
them and then do a build.

Any thoughts?

Cheers,

Will

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Strange git merge behaviour with empty branches
  2012-03-19 18:53 Strange git merge behaviour with empty branches Will Deacon
@ 2012-03-19 19:51 ` Junio C Hamano
  0 siblings, 0 replies; 2+ messages in thread
From: Junio C Hamano @ 2012-03-19 19:51 UTC (permalink / raw)
  To: Will Deacon; +Cc: git

Will Deacon <will.deacon@arm.com> writes:

> Any thoughts?

What is recorded in Octopus merges is a rather torn issue.  The original
motivation was to allow recording anything the user throws at us, even
though some are ancestors of others, without reducing them to the minimum
set of parents that are necessary to represent the full history, because
that is after all what the user wanted to do. You see some of that there.

On the other hand, there was an edict from the original maintainer that we
shouldn't record useless merge parents, so there were some changes in that
direction to cull obviously redundant parents from the parent list.

But over time, novelty of Octopus merges waned, and nobody serious uses it
for real work these days, except when bored and being curious, playing
around and seeing what it does.

An advice for an end-user is "Don't throw meaningless parents at
Octopus. It will do whatever it does, and the only guarantee you are
getting is that it does not record wrong parents, it may omit obviously
redundant parents, and it will never discard an independent parent."

An advice for a developer is to update it to make sure only the
independent parents are recorded; "show-branch --independent" may be a
good tool to compute them

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2012-03-19 19:51 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-03-19 18:53 Strange git merge behaviour with empty branches Will Deacon
2012-03-19 19:51 ` Junio C Hamano

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).