How to hide a changeset by committing in another one?

Pierre-Yves David pierre-yves.david at logilab.fr
Mon Jun 20 11:49:01 CDT 2011


On Mon, Jun 20, 2011 at 11:23:09AM -0500, Kevin Bullock wrote:
> Looks like your extension would just add grouped changesets to the changelog.hiddenrevs list in the wrapped `log` command.

(reordering changeset) You also have a display a grouped diff of all you children.

> > Then you have to describe how hidden changeset with non-hidden changeset should
> > behave, convince use and implement the proper log behaviour.
> > 
> > (or join the "obsolete changeset" effort)
> 
> 
> I think Arne is getting at something different here, namely reimplementing the group extension (with all of, and only, its current behavior) using the new 'hidden' facility.

Obsolete get you something similar:

* You don't show previous changeset related to the same thing.
* You get a full diff of what changet from before the "group" to after the group.
* You can see detailed history if you want.

But you don't have to hack log (and several other) display the whole group diff
as the diff of the last group changeset. The last obsolete changeset hold all
the diff by definition. (you have to write obsolet to get diff in the subgroup
thought).

This is one of the main difference:
    * with the current group extension you see every step as changeset and extend logic to it a consistent group.
    * with obsolete you see the consistent group as a changeset and extend logic to see every step.

> Arne, as far as I know the only documentation is the changesets themselves, namely for your purposes: <http://www.selenic.com/hg/rev/7e295dd10d40> and <http://www.selenic.com/hg/rev/f3a40fd7008c>.

As commit http://www.selenic.com/hg/rev/7e295dd10d40 say: Code adding revisions
to the set are responsible to the consistency of it's data.

For now it's not consistent to have non-hidden children to hidden changeset.
Defining a consistent behavior non-hidden children of hidden changeset will
allow the group extension be rewritten with the hidden content.  I have nothing
again defining such behaviour it's just not done yet.

-- 
Pierre-Yves David

http://www.logilab.fr/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20110620/ba3f3282/attachment.pgp>


More information about the Mercurial-devel mailing list