Hi Junio, On Thu, 8 Mar 2018, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > > >> Non-textual semantic conflicts are made (in the best case just once) > >> as a separate commit on top of mechanical auto-merge whose focus is > >> predictability (rather than cleverness) done by Git, and then that > >> separate commit is kept outside the history. When replaying these > >> merges to rebuild the 'pu' branch, after resetting the tip to > >> 'master', each topic is merged mechanically, and if such a fix-up > >> commit is present, "cherry-pick --no-commit" applies it and then > >> "commit --amend --no-edit" to adjust the merge. I find it quite > >> valuable to have a separate record of what "evil" non-mechanical > >> adjustment was done, which I know won't be lost in the noise when > >> these merges need to be redone daily or more often. > > > > So essentially, you have something that `git rerere` would have learned, > > but as a commit? > > You probably wouldn't be asking that if you read what you cut out > when you quoted above ;-) Sorry to be so stupid, and no, the part I cut did not clarify it for me, hence my question. > There are a collection of cherry-pickable commits in hierarchy under > refs/merge-fix. They are indexed by the branch that will cause > semantic conflicts that do not involve textual conflicts at all (the > important implication of which is that 'rerere' fundamentally will > not trigger to help resolving them) [*1*], and are used to create > evil merge when a corresponding branch is merged to 'pu' (and down). I see. My question was unclear, I agree. Please let me re-try: So essentially, what your cherry-pick'able commits are is a way to store what rerere would have stored (i.e. the set of merge conflicts together with their resolution)? If so, what tooling do you have to identify quickly what to cherry-pick, given merge conflicts? (I know I could spend some half hour to scour your `todo` branch and the documentation you wrote about how you maintain Git, but you already know the answer to this question, and it would probably be interesting to others who are as eager to have better tools for handling merge conflicts as I am, too, so it would save time overall to discuss this single question here.) > *1* One topic adds an extra parameter to read_index_from() that has > been and still is defined in a file and merged to 'pu' first, while > another topic adds a new callsite for the same function in a file > that the former topic does not touch, hence a merge of the latter > topic has no textual conflict to the file with a new callsite, but > still needs adjusting. That sort of think. Okay, so it is even more intricate than `rerere`: it does not only store the merge conflicts (by grace of using the "patch ID" of the merge conflicts) together with their resolution, but instead it has some sort of idea of what context needs to be met to require the resolution? Color me intrigued. If you really found a way to automate describing, say, that a function signature changed in one branch, and a caller was introduced in another, and that merging those requires adjusting the caller in a specific way, I now *really* think that this should be made available more broadly. Ciao, Dscho
