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

[Martin von Zweigbergk]

On Fri, May 19, 2017 at 3:20 PM, Pierre-Yves David
<pierre-yves.david at ens-lyon.org> wrote:
> On 05/19/2017 10:49 PM, Jun Wu wrote:
>>
>> Excerpts from Pierre-Yves David's message of 2017-05-19 22:08:31 +0200:
>>>>
>>>> Talking about perfection, I also don't think the 3 bits: parent-change,
>>>> content-change and metadata-change is a good abstraction.
>>>>
>>>> Because they are redundant data. They can be calculated afterwards, in a
>>>> cache.
>>>
>>>
>>> No they can not. The obsolescence graph can contains reference to node
>>> we do not have locally then we cannot compute the "effect" of operation
>>> between these nodes.
>>>
>>> Storing the effect are creation time is important. For example, I can
>>> see that both Alice and Bob rewrote a changeset between two locally
>>> known version. If I need to dig deeper, I can use the effect-flags to
>>> discover that Alice changed the code but Bob is the one who did the
>>> description proof reading and the rebase,
>>
>>
>> If it's for divergence resolution - anyone who has the original changeset
>> could figure out what to do without the obsstore flags.
>
>
> No, this is to offer informative (and zoomable) capability to look at the
> obsolescence history. It is to be used by human user, this class of feature
> is an actual requestion from actual team testers.

It seems like a very reasonable assumption that people will not care
to zoom into the changes in the part of the obs history for which they
don't have any commits. If we accept that assumption, then Jun is
right that this could be moved out into a cache, right? It would be
data that can be safely cached with just the obsmarker (some hash of
it probably) as key. It wouldn't even be affected by stripping commits
(nor obsmarkers).

I really like the new obslog/olog command from the evolve extension,
but it's clearly missing important information (which is no surprise
for a new command). I would really like a -p option for it. The tricky
thing, of course, is that it would pretty much have to have a way of
skipping hunks that changed because of rebasing. I always found git's
"combined diff" format hard to read, but I don't have a better
suggestion here.

The other obvious missing information from obslog is what this thread
is about. The things I can think of that would be useful to me are 1)
3 bits: commit moved, commit message changed, contents changes, and 2)
the operation that created the obsmarker. (2) is of course what
Durham's patch is about. I do think it will be helpful to know that a
commit was created as a result of histedit rather than just knowing
that it moved (for example). Regarding (2), and as noted above, I'm
still with Jun about calculating the bits rather than storing them in
the obsmarkers. However, that seems like more work and it sounded from
Boris's email that the bits would stored inside the metadata field and
we can always ignore that field in 3 years when we have implemented
the bit cache.

In summary, it seems to me like both the operation and the bits would
be useful, so I support getting both in. I'm also not very concerned
about the size overhead. We can start compressing that later if
necessary.

Sorry to add more to an already long thread.

>
> Most of the rest of your reply seems to be around divergence resolution so
> I'll drop it for now.
>
>>>> "operation" metadata is not redundant - you cannot get them from
>>>> elsewhere
>>>> so they should be recorded.
>>>
>>>
>>> Locally, we already have the command information in the journal. And
>>> once we cross the distributed barrier, the content of "operation perform
>>> very poorly.
>>
>>
>> journal is an extension and is experimental and I do have plans to make
>> big
>> changes to it. obsstore is in core already. I don't think we should depend
>> on journal for now.
>
>
> Evolution is an experimental feature with most of it UI in an extension, so
> this is not too different. Journal is an extension dedicated to keeping
> track of locally executed commands, this seems to fit your "operation" use
> case well. This is why I'm pointing at it.
>
> Cheers,
>
> --
> Pierre-Yves David