On 05/10/2017 05:45 PM, Durham Goode 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 <dur...@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.
There seems to be a major misunderstanding here.
Obsmarkers -already- has a bitfield (for many years) so are -already-
able to use them to record actions. There are no delay or blocker here
everything is already in place for it. There are basically no reason to
not just do it.
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.
Having multiple markers between local changesets is the common case once
people start exchanging draft changesets. We can not dismiss this as an
outliers, behaving properly here is an actual request from the current
users.
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")
Having more information is always useful, but this looks like something
to add as a second step.
The action-bit approach has clear advantages (no size concerns, clear
behavior with marker compositions), so this appears as a clear good
first step here.
In addition, if that first step turn out to not be enough and we want
more precise data we might want to look at leveraging the "hg journal"
local data for this.
I would recommend the following step forward:
1) add a simple "rewritten as" template,
2) record action-bit, use it in the template (and other related output),
3) gather data and look at the best way to issue more details.
By chance step (1) and (2) are on the list of UI improvement founded by
Unity (1) is about to be done (read: next week) and (2) is likely to be
scheduled in the next batch (read, this month).
If you want to work in this area, I recommend catching up with the
recent improvement in evolve and getting in touch with Boris Feld
(currently writing doing most of the lifting in this area).
Cheers,
--
Pierre-Yves David
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
