[PATCH RFC/WIP] introduce stash command

Matt Mackall mpm at selenic.com
Sat Jun 2 22:00:06 UTC 2012


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.

- 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.

- will lose rollback context

Probably fine.

- will prevent qpop

There goes a big use-case.

- are probably rebased when "real" parent commits are rebased

Also probably fine.

- -p vs --pop is sure to annoy people

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.

-- 
Mathematics is the supreme nostalgia of our time.





More information about the Mercurial-devel mailing list