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

Jun Wu quark at fb.com
Fri May 19 18:28:12 EDT 2017


Excerpts from Pierre-Yves David's message of 2017-05-20 00:20:08 +0200:
> > 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.

If it's not for divergence resolution, but just for human eyes. Then the
operation metadata is strictly better from a user-experience point of view.

> 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.

As you said that distributed cases need to be considered when designing
things. In order to make the journal information useful, it needs to be
exchanged somehow. That does not sound like a good idea. So please ignore
journal for now.


More information about the Mercurial-devel mailing list