Re: Git without morning coffee

[Junio C Hamano <gitster@pobox.com>]

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.