[PATCH RFC/WIP] introduce stash command
idankk86 at gmail.com
Sat Sep 29 14:24:55 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.
So it's been a while and things that can help have changed since I first
sent this. I'd like to see how we can move forward with this, hopefully
to see it in the next version (which is a month away).
> 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.
Stash commits are now created in the secret phase and bookmarked under
the '.hg/stash/' namespace. Currently on default these aren't exchanged
on push/pull but are still shown in log and other commands.
But with Pierre-Yves's work on changelog filtering, we're very close to making
secret changesets secret (partially working with his repofilter patches).
> - unstashing does a graft/rebase
> - 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.
These two points are covered by changelog filtering.
> - will lose rollback context
> Probably fine.
> - will prevent qpop
> There goes a big use-case.
Still an issue. Unfortunately I don't see this changing until
MQ is rewritten to use obsolete markers rather than strip
and there's no sign of that happening anytime soon.
> - are probably rebased when "real" parent commits are rebased
> Also probably fine.
> - -p vs --pop is sure to annoy people
Renamed -p/--patch to -s/--show.
> 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.
More information about the Mercurial-devel