[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