[Sorry for the repeat, Junio] On Wed, Sep 7, 2011 at 16:46, Junio C Hamano <gitster@xxxxxxxxx> wrote: > 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 > I think it would be great if at some point you could write a detailed tutorial of how you maintain git (using example topics, example patch series and pull requests, and follow-along command sequences, etc.). Most importantly, it would be nice to see an explicit description of the maintenance properties you are trying to achieve with your workflow. -- 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