On Wed, May 10, 2017 at 8:57 AM, Augie Fackler <r...@durin42.com> wrote: > >> On May 10, 2017, at 11:52, Martin von Zweigbergk <martinv...@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. _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
