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

[Martin von Zweigbergk]

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:
>>
>> On 05/10/2017 01:34 AM, Durham Goode wrote:
>>>
>>> # HG changeset patch
>>> # User Durham Goode <durham at fb.com>
>>> # Date 1494372571 25200
>>> #      Tue May 09 16:29:31 2017 -0700
>>> # Node ID 22051b0924bcbc5cde6d25d700dcce6afcaafd98
>>> # Parent  8f1a2b848b52ea7bf3fe2404e3b62924c7aae93f
>>> obsolete: add operation metadata to rebase/amend/histedit obsmarkers
>>
>>
>> TL;DR; Storing more information is useful, but the pre-existing plans
>> aims at storing slightly different data in a different way. We should
>> stick to it.
>>
>> The idea is to use the obsmarker bitfields to store the data and record
>> a pre-defined set of "effects" in each markers. (eg: "content change,
>> message change, parent change")
>>
>> For examples:
>>
>> 1) a `hg amend` that update the diff will create a markers recording the
>> "content changes".
>>
>> 2) a `hg amend -e` that only update he commit message will record the
>> "message change".
>>
>> 3) a `hg rebase` will record the "parent change".
>>
>> 4) a `hg amend` that update the message, the content and user will
>> record these three things (content, message and meta changes).
>>
>> These data can then be used to have nice template as shown by Durham
>> (eg: is X is a successors of Y and the markers as some "content change"
>> bit, we can display "amended as Y"; if their are some parent change, we
>> can display "rebased as Y", if both are present "amended and rebased as
>> Y").
>>
>
> While having the above data seems nice, I don't know if it justifies not
> going with the current simple approach today. Otherwise we have to wait for
> this large obsstore refactor, which seems like a rather big dependency to
> block an important UX feature we could deliver today.
>
> When the bit field is added in the future we can always change our templates
> and messaging to use that data as well.  And if it's good enough, we can
> drop the 'operation' metadata entirely, with little compatibility issue.
>
>> The above approach as multiple advantages:
>>
>>   Compact: Since we use the (existing) bitfield, the storage cost is
>> free (or minimal if we need to adds an extra byte of bitfield).
>> Accessing the data is also very cheap:
>>
>>   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.

>
>>   UI Abstraction: since we record the "effect" information, we abstract
>> the command names. This makes use more agile about the actual UI. User
>> can use their own "hg myownrewritetool" command and still record
>> information useful for the other users.
>
>
> I think recording the actual command the user ran is important. The goal of
> showing this in the UI is to let the user know what past action caused this
> commit to become a new commit, so if they run 'hg flabbernate' it's much
> more useful to show them 'fblabbernated to be X' than it is to show them
> 'amended to be X'. So potentially, even if we have the bitfield data, it
> could still be important to record the actual command that caused this
> obsmarker to be created (ex: "amended to be X by hg flabbernate")
>
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel