[PATCH 2 of 2 RFCv2] commands: introduce stash command

Pierre-Yves David pierre-yves.david at logilab.fr
Mon Feb 18 13:41:16 UTC 2013


On Mon, Feb 18, 2013 at 02:10:41PM +0200, Idan Kamara wrote:
> On Mon, Feb 18, 2013 at 2:03 AM, Pierre-Yves David <
> pierre-yves.david at ens-lyon.org> wrote:
> >
> >
> > On 15 févr. 2013, at 01:15, Idan Kamara wrote:
> >
> > > # HG changeset patch
> > > # User Idan Kamara <idankk86 at gmail.com>
> > > # Date 1360886982 -7200
> > > # Node ID 06dd5eda17402c1e89a1aa212e340b146394fad8
> > > # Parent  d4c029076cf2213ad680a53dfd32b0886b2b7be0
> > > commands: introduce stash command
> >
> > I'm very happy to see this happening. Having a sane and stable solution to
> > shelve/unshelve is very important.
> >
> > I not sure that putting that as a core command is the right things to do.
> > I would expect the command to be introduced in an extension before getting
> > into core.
> 
> I guess that's fine since it relies on some fairly new features in core.
> I just hope it won't require all sorts of glue code to work properly as an
> extension.
> 
> How do others feel?

To clarify my point I would prefer it to be a separated extensions for a few
month. It will validate the approach leaves the door open for some UI and
behavior adjustement.

> > > Stashes are unnamed (by default) and can be listed using --list and
> > > inspected
> > > with -s/--show.
> >
> > Is there real usage for unnamed stash? don't we want to force the user to
> > provide a minimal description ?
> 
> Of course, it's a lot faster to do:
> 
> $ hg stash
> $ hg up <where-i-really-wanted-to-be>
> $ hg stash -p
> 
> Than to start thinking of an unused name.

not really convinced. I would probably always use

  $ hg stash wip
  $ hg up <where-i-really-wanted-to-be>
  $ hg stash -p wip

Where having wip already taken is an highlight that something is wrong.

(I'm not telling your approach is wrong)

> > > Referring to stashes is done either by index (as shown in --list) or
> > > name (if
> > > one was given). If neither is specified, the most recent stash is
> > > chosen.
> >
> > Most recent rules seems sane.
> >
> > > A stash is saved as a regular secret commit in the repository
> >
> > Note that once it is hidden, it does not needs to be secret. Its already
> > excluded from exchanges.
> 
> Ok, so I'm slightly confused. Does secret imply hidden? Do I want it
> to be hidden or secret?

You want it to be hidden. It does not needs to be secret to be excluded from pull and push.

    visible = all() - hidden()
    served  = all() - (hidden() or secret()


> > > and is identified by a bookmark under a special namespace '.hg/stash/'.
> >
> > Muh? what does stash as do do with bookmark? Can't you keep the label
> > internally? (and expose them in revset if needed)
> 
> Keep it internally how? A dedicated file in .hg/? Why not use an
> existing mechanism?

Yes a dedicated file in .hg/store/

As far as I understand stash id:
- Does not behaves as bookmarks,
- Does not moves like bookmarks,
- Are not exchanged like bookmarks,

If its does not look like a bookmarks, it is not a bookmark. (reverse duck typing)



-- 
Pierre-Yves David

http://www.logilab.fr/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mercurial-scm.org/pipermail/mercurial-devel/attachments/20130218/79b14c1b/attachment.asc>


More information about the Mercurial-devel mailing list