Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> 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. -- 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