Neels J Hofmeyr wrote: > Julian Foad wrote: > > > > I believe it should be a low level job [1] to detect when a (potential) > > tree conflict is happening, and a higher-level job to decide how to > > resolve the (potential) conflict. The low level should pass the details > > to the higher layer, and the higher layer can say something like: > > > > { > > if user-option is ACCEPT-THEIRS or ACCEPT-MINE or ...: > > return user-option > > > > switch (tree-conflict-type): > > > > delete+edit: > > choice = interactive-resolve(...) > > return choice > > > > add+add: > > if same-content(...): > > return ACCEPT-THEIRS # THEIRS or MINE, doesn't matter > > choice = interactive-resolve(...) > > return choice > > > > ... > > } > > Hmm, would such higher layer also need to distinct between TC during > update/switch and merge?
I would want it to be able to know and modify its behaviour based on what kind of operation is happening. Every callback should take a callback baton so that the higher level code can pass information such as this to it. - Julian > > > > I say "(potential) conflict" because even in a case like delete+delete > > or add+add when the two nodes conflicting are identical and most users > > just want it resolved automatically, I think the low level should pass > > the details to the higher layer, and the higher layer can say "if it's > > delete+delete then return ACCEPT-THEIRS" or similar. Even if this > > decision is hard-coded in the higher layer rather than customizable, I > > believe that having it there will make a much better design than if the > > lower layer made that decision and didn't bother to ask the higher > > layer. > > I like that :) > > The low layer would be check_tree_conflict() in _wc/update_editor.c and <the > code that determines parameters passed to tree_conflict() and > tree_conflict_on_add()> in _client/merge.c, of which the result could be run > by a common higher-layer function, after which the lower code carries out > the actions indicated (like now, e.g. where the code decides to fall through > the 'delete' code path in case of reason_deleted during update...) > > ~Neels