[PATCH] obsolete: add operation metadata to rebase/amend/histedit obsmarkers

[Durham Goode]

On 5/10/17 8:52 AM, Martin von Zweigbergk wrote:
> On Wed, May 10, 2017 at 8:45 AM, Durham Goode <durham at fb.com> wrote:
>> On 5/10/17 3:40 AM, Pierre-Yves David wrote:
>>>
>>>   Compoundable: We'll often needs to combine multiple markers to reports
>>> changesets between two revisions (eg: we do not have the intermediate
>>> revisions locally). the bit field approach makes it trivial to compound
>>> the information. We can display display the same final information when
>>> the same result if obtained from different path (eg: from two markers
>>> [content change; message change] or from one markers [content change |
>>> message change]).
>>>   This part is important because simply using operation name makes it
>>> quite hard to combine the information.
>>
>>
>> Yes, if there were multiple operations we'd have to union them just as
>> operation='modified' or something. Not ideal, but should be an outlier case.
>
> With our setup internally, it's not really an outlier case. We tag
> revisions that are sent for code review and leave the tags until next
> time the change is sent for review. There can thus be many amends and
> rebases between the revision sent for review and the current latest
> revision. I'm not sure what a good way of presenting that to the user
> would be.

Ah, yes. I was thinking about multiple markers between the same nodes, 
but the chain of commits that are not all visible is a common case (and 
is obviously what Pierre-Yves was talking about when I read closer).

Yes, this case wouldn't be well handled by the operation string 
solution.  One solution we've had internally is to have a smartlog 
output that shows all the successors to a node.  So you can see "X was 
amended to be Y", "Y was rebased to be Z", "Z was landed as V". It makes 
it very easy to visually traverse the history of a node and could allow 
a user to dig in to a generic "X was modified to be V" unioned-message.