David Kastrup <d...@gnu.org> writes: > David Kastrup <d...@gnu.org> writes: > >> Don't rebase either origin and translation. Simple rule. Don't try >> being clever about it: being clever around git is a recipe for disaster. >> If you messed up your own repository (and that does not mean "merely" >> the state of the work tree, but the history of commits), don't push. >> Ask. We will figure out how to get it back into a nice state. >> >>> Then I waited until patchy merges into master, so I can now be sure >>> that all those commits are 'upstream'. I could now safely merge master >>> into translations as usual. When I will eventually merge again, >>> duplicate commits should ideally combine in a single history. >>> >>> If not, and if we have any conflicts, I could merge with strategy >>> recursive and option 'theirs'. >> >> Well, there we are. It would appear that you used the merge strategy >> "theirs" rather than "recursive + option theirs". The respective merge >> _claims_ to merge two commits but doesn't. It just takes the tree from >> "theirs" unchanged. At least this is what happened with the merge I >> traced to be faulty. > > Ok, I take that back: this merge might not necessarily be the exact > cause of the trouble. If you merge an original branch again after you > already rebased it, the merge conflict resolution would essentially > resolve to what the rebased branch already had. So that merge > resolution would indeed look like a one-sided merge strategy in its > outcome. > > Digging further.
man git-rebase has a few interesting bits: -m, --merge Use merging strategies to rebase. When the recursive (default) merge strategy is used, this allows rebase to be aware of renames on the upstream side. Note that a rebase merge works by replaying each commit from the working branch on top of the <upstream> branch. Because of this, when a merge conflict happens, the side reported as ours is the so-far rebased series, starting with <upstream>, and theirs is the working branch. In other words, the sides are swapped. Also -p, --preserve-merges Instead of ignoring merges, try to recreate them. This uses the --interactive machinery internally, but combining it with the --interactive option explicitly is generally not a good idea unless you know what you are doing (see BUGS below). Merge commits are usually _ignored_ when rebasing. This includes merges from master into translation. If you rebased the translation branch on an _old_ version of master (namely on your local master rather than origin/master). Hm, no, I still don't get what happened. I need to figure out more. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel