Re: Git without morning coffee

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 7, 2011, 16:46 UTC
Message-ID: <7vehzs47we.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4E6721E3.7000207@drmicha.warpmail.net>

Michael J Gruber <git@drmicha.warpmail.net> writes:

> git merge ":/Merge branch 'jk/generation-numbers' into pu"
> fatal: ':/Merge branch 'jk/generation-numbers' into pu' does not point
> to a commit
> # Huh?

Interesting.

> git merge $(git rev-parse ":/Merge branch 'jk/generation-numbers' into pu")
> error: addinfo_cache failed for path 't/t7810-grep.sh'
> Performing inexact rename detection: 100% (91476/91476), done.
> error: addinfo_cache failed for path 't/t7810-grep.sh'

Smells like another case where merge-recursive is looking at the work tree when it shouldn't inside an inner merge or something.

> I mean, I'm merging a commit from origin/pu to origin/next when the
> latter is basically contained in the former (except for some merge
> commits).

This falls into the "side note" category, but these days 'next' and 'pu' do not share any history beyond the tip of 'master'. Every time I update the 'pu' branch, it is rebuilt directly on top of 'master' from scratch by merging the topics in 'next' (and at this point I make sure its tree matches that of 'next') and then merging remaining topics on top of the result. A topic often goes through multiple iterations of fix-ups while in 'next', and these fix-ups result in multiple incremental merges of the same topic into 'next'; I do not want to see an incorrect merge when such a topic is merged in a single-step into 'master', and it is one way to ensure the health of the merge fixup machinery (including the rerere database) to attempt from-scratch-the-whole-topic-at-once merges and verify the result.

The merge you attempted will have a lot of "the history leading to the current commit added/modified in a certain way and the history being merged did the same modification independently" kind of conflicts that should resolve to no-op.