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

Durham Goode durham at fb.com
Wed May 10 11:45:42 EDT 2017


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.

>   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")


More information about the Mercurial-devel mailing list