On Thu, 18 Jun 2020 at 11:28, Curtin, Eric <Eric.Curtin@xxxxxxxx> wrote: > > > What I'd like to stress though is that there is a pitfall here: is it > > feasible to try to support concurrent conflict resolution, or is it to > > be sequential (even if in multiple turns)? I incline to the latter. > > > Concurrent conflict resolution would lead to conflicts in conflict > > resolutions, that already sounds too complex to be useful for my taste, > > and we already are in recursion that must be stopped somewhere, so it's > > tempting to stop it one level up. > > I think concurrent doesn't make sense, only sequential. > > > I find that the solution in these cases is to first use interactive > > rebase to squash and reorganize the commits in the branches so you > > have a nice clean patch sequence. Once you have the branches cleaned > > up and squashed into a sequence of reasonable topic based chunks you > > then merge, sometimes it even means you dont get conflicts at all, git > > merge is pretty smart. > > Again, as said in the initial email, anything that rewrites history, > recreates SHA's (such as rebase, squash, etc.) on a remote > branch is not allowed in our repo. Of course with unpushed > commits you can do some of these things as the remote end > knows no different. Ah I see, I missed that detail. We have a similar rule at work but only for the "trunk" branch (what most people call "master"), topic branches are allowed to change before the merge to trunk. I guess there is no way to convince your policy makers that if commit A and B are different but have the same tree hash they refer to the same state on the disk? I have had audit conversations like that. Anyway, sorry my reply wasn't helpful. Good luck. cheers, Yves
