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

Martin von Zweigbergk martinvonz at google.com
Wed May 10 11:59:55 EDT 2017


On Wed, May 10, 2017 at 8:57 AM, Augie Fackler <raf at durin42.com> wrote:
>
>> On May 10, 2017, at 11:52, Martin von Zweigbergk <martinvonz at google.com> 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.
>
> I think the common case is rebased and amended - couldn't we observe the list of actions in the list and emit something like
>
> deadbeef rebased, amended to beefdead
>
> in `hg log` output?
>
> I'd rather not let the perfect be the enemy of the good here - we can at least get the data recorded and start experimenting with ways of operating on it. It's already missing from countless thousands of markers, so we'll never be able to assume it exists, so I feel like we might as well start recording it and see if we need to iterate on how we're recording it from there.

I agree. I didn't mean to use it as an argument against Durham's
patch, just something to think about. And I think agree with you about
how to do it. My initial thought was also to keep a set of all
distinct operations along the chain.


More information about the Mercurial-devel mailing list