[PATCH RFC/WIP] introduce stash command

Idan Kamara idankk86 at gmail.com
Sat Jun 2 17:43:02 CDT 2012


On Sun, Jun 3, 2012 at 1:00 AM, Matt Mackall <mpm at selenic.com> wrote:
>
> On Sat, 2012-06-02 at 16:27 +0300, Idan Kamara wrote:
> > On Sat, Jun 2, 2012 at 4:25 PM, Idan Kamara <idankk86 at gmail.com> wrote:
> > >
> > > # HG changeset patch
> > > # User Idan Kamara <idankk86 at gmail.com>
> > > # Date 1338643506 -10800
> > > # Node ID 6e5f3f08d11199f5893b501dfa8096979675314f
> > > # Parent  357e6bcfb61973478bfbe4cf5652026a6bda7ef7
> > > introduce stash command
> >
> > As the title says, this patch adds a stash command that is aimed
> > to replace the various broken extensions and/or use of mq as an
> > alternative.
> >
> > In terms of functionality it's pretty much complete. The UI is not
> > perfect yet and I'm open to suggestions (e.g. --list format).
> >
> > The only thing that is currently unimplemented is hiding of stashes
> > so they're not exposed to the user (which is pretty integral though).
> >
> > Please look at the code or ask questions for more details.
>
> It'd be massively helpful if you explained how they were implemented
> rather than having us read a big patch. From what I can gather:
>
> - stashes are commits
>
> Ok. Git does this, and it works pretty well for them. This has the
> upside of not being lossy like an MQ diff and properly connected to
> history for future rebasing.
>
> - flagged/tracked with bookmarks
>
> Hmm. Git does something with refs/stash. I don't know Git internals well
> enough to tell how this relates to their other ref namespaces or whether
> stashes are hidden from push/pull, but I assume they are.
>
> The bookmark namespace pollution here is a bit worrisome. People will be
> able to see these names remotely, and clone will clone them by default.

Right now they're saved with a 'stashes/' prefix. I wrote somewhere
that we might want a generic private namespace such as 'hg/'.

>
> - unstashing does a graft/rebase
>
> Great.
>
> - currently visible to push/outgoing/etc.
>
> Problematic, especially if you do:
>
> $ hg stash  # stash commit becomes branch head!
> $ hg push  # off it goes!
>
> - visible to update
>
> Same issue. Git avoids this by having no idea where its heads are
> without tracking them directly. (One sometimes suspects that Git is
> really intended as a deniable filesystem and its wide deployment as an
> SCM is part of its cover story.) Because Mercurial keeps its changeset
> graph readily accessible, there's currently no easy way to hide anything
> from ourselves.

Yes, the visibility is the remaining issue. But the idea is
to somehow hide them from log/push/pull/bookmarks/update/etc.

>
> - will lose rollback context
>
> Probably fine.
>
> - will prevent qpop
>
> There goes a big use-case.

Not sure I get the use case.

>
> - are probably rebased when "real" parent commits are rebased
>
> Also probably fine.
>
> - -p vs --pop is sure to annoy people

Including myself. But I wanted to stay consistent with -p
which is used in log/tip.

Maybe we can rename pop to restore (although then it's not
immediately obvious how it differs from apply).

>
> I'm not sure how much sense it makes to have a commit-based stash until
> we have a way to actually hide things from ourselves in history.

Yeah, when I started this thing yesterday afternoon, I thought it's
as easy as putting some stuff in repo.changelog.hiddenrevs, but
there's no infrastructure for it yet.

So any pointers/help in this area will be appreciated.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20120603/a48b4c91/attachment.html>


More information about the Mercurial-devel mailing list