https://bugs.documentfoundation.org/show_bug.cgi?id=166723
--- Comment #47 from Eyal Rozenberg <[email protected]> --- (In reply to Telesto from comment #46) > A well, I did understand baseline (as original document) prior to any > track-changes. That's actually the same thing. If you reject all the changes, you get the document prior to any tracked changes being made. Unless I've now misunderstood you somehow... > Example with your definition: > A) baseline: "Hello World" (initial document, without track changes) > B) Bob: Deletion of "World" with track changes ON. Result: Hello. > Baseline = Hello World (Reject deletion = baseline) "Hello" is not the result. It is a proposal. > C) Alice presses 'reinstate' with track changes ON: Hello World. Deletion > becomes Insertion. Baseline = "Hello" (when Reject insertion). The baseline is "Hello" without your parenthesized qualifications. > > I don't think Alice intended to change "baseline" to "Hello". If she didn't intend to change the baseline - then she made a mistake, because - like you've noticed - she did do just that. And this is why we should absolutely not call this command "reinstate" or "reject and track", because that might convince her to to do so, which she really shouldn't. > The goal of Alice: reinstates the original state > > Or I'm I overlooking something? The point of this bug :-( To "reinstate the original state", we don't need to do anything: The document baseline is the original state, and it needs no reinstatement. (Or if you mean - do away with the proposed changes - that's a Reject All). This command does something else. -- You are receiving this mail because: You are the assignee for the bug.
