<div dir="ltr">On Mon, Feb 18, 2013 at 2:03 AM, Pierre-Yves David <<a href="mailto:pierre-yves.david@ens-lyon.org" target="_blank">pierre-yves.david@ens-lyon.org</a>> wrote:<br>><br>><br>> On 15 févr. 2013, at 01:15, Idan Kamara wrote:<br>

><br>> > # HG changeset patch<br>> > # User Idan Kamara <<a href="mailto:idankk86@gmail.com" target="_blank">idankk86@gmail.com</a>><br>> > # Date 1360886982 -7200<br>> > # Node ID 06dd5eda17402c1e89a1aa212e340b146394fad8<br>

> > # Parent  d4c029076cf2213ad680a53dfd32b0886b2b7be0<br>> > commands: introduce stash command<br>><br>> I'm very happy to see this happening. Having a sane and stable solution to<br>> shelve/unshelve is very important.<br>

><br>> I not sure that putting that as a core command is the right things to do.<br>> I would expect the command to be introduced in an extension before getting<br>> into core.<div><br></div><div>I guess that's fine since it relies on some fairly new features in core.</div>
<div>I just hope it won't require all sorts of glue code to work properly as an</div><div>extension.</div><div><br></div><div>How do others feel?</div><div><br>><br>> > Stashes are unnamed (by default) and can be listed using --list and<br>
> > inspected<br>> > with -s/--show.<br>><br>> Is there real usage for unnamed stash? don't we want to force the user to<br>
> provide a minimal description ?</div><div><br></div><div>Of course, it's a lot faster to do:</div><div><br></div><div>$ hg stash</div><div>$ hg up <where-i-really-wanted-to-be></div><div>$ hg stash -p</div>

<div><br></div><div>Than to start thinking of an unused name.</div><div><br>><br>> > Referring to stashes is done either by index (as shown in --list) or<br>> > name (if<br>> > one was given). If neither is specified, the most recent stash is<br>

> > chosen.<br>><br>> Most recent rules seems sane.<br>><br>> > A stash is saved as a regular secret commit in the repository<br>><br>> Note that once it is hidden, it does not needs to be secret. Its already<br>

> excluded from exchanges.</div><div><br></div><div>Ok, so I'm slightly confused. Does secret imply hidden? Do I want it</div><div>to be hidden or secret?</div><div><br>><br>> > and is identified by a bookmark under a special namespace '.hg/stash/'.<br>
><br>> Muh? what does stash as do do with bookmark? Can't you keep the label<br>
> internally? (and expose them in revset if needed)</div><div><br></div><div>Keep it internally how? A dedicated file in .hg/? Why not use an</div><div>existing mechanism?</div><div><br>><br>> >  It is hidden from the user and isn't exchanged with other repositories.<br>
><br>> > When a stash is popped or deleted, it is stripped from the repository or<br>
> > marked obsolete if obsolete is enabled.<br>><br>> If you use obsolescence markers, you have to ensure that people can<br>> recreate the "same stash" with a different commit hash.<br>><br>> In the same way it seems that you are storing stash commit as plain<br>

> standard commit (including commit message content), this open the way to<br>> unfortunate collision between stash and standard changeset.</div><div><br></div><div>Interesting, I'll look into it.</div><div><br>
><br>> > It's currently not possible to stash when an mq patch is applied. Unless<br>
> > mq<br>> > sometime in the future stops the use of strip (unlikely, mainly due to<br>> > lack of<br>> > interest in touching it), this won't change.<br>><br>> Your check is too weak. User can qimport stash parent and qpop them. You<br>

> need stronger check in MQ</div><div><br></div><div>Right.. I haven't really thoroughly tested how it behaves with MQ yet.</div></div>