hg equivalent of git stash
anatoly techtonik
On Sat, 2008-01-12 at 17:13 -0600, Phillip Koebbe wrote:
I was reading earlier today about "git stash" and was thinking itYou might be interested in mq, which is about a million times more
would be very useful to me. Is something like that available in hg?
useful.
anatoly t.
Masklinn
> hg qnew -f [-i] [-m "reminder message"] some-patch-name [files…]
> hg qpop
will put your changes (potentially filtered by -i or the files list) in your queue, and then "pop" (unapply and store) these changes
To reintroduce them, `hg qpush` will "push" (apply) these changes. The "drawback" for a shelve scenario is that these changes are already in the form of a revision at this point, you can either finish the changes within mq (using `hg qrefresh` to update it and `hq qfinish` to serialize it into an hg revision living outside of MQ) or strip out the revision keeping the patch data via `hg strip -k`.
Alternatively, there are third-party shelve extensions which provide a simpler workflow for shelving: Attic[0] and Shelve[1]. As far as I can see, Attic is not maintained anymore so I'd suggest going with shelve.
[0] http://mercurial.selenic.com/wiki/AtticExtension
[1] http://mercurial.selenic.com/wiki/ShelveExtension
_______________________________________________
Mercurial mailing list
Merc...@selenic.com
http://selenic.com/mailman/listinfo/mercurial
Sam Steingold
> On Jan 12, 2008 3:27:01 pm, Matt Mackall wrote:
>> On Sat, 2008-01-12 at 17:13 -0600, Phillip Koebbe wrote:
>>
>>> I was reading earlier today about "git stash" and was thinking it
>>> would be very useful to me. Is something like that available in hg?
>>
>> You might be interested in mq, which is about a million times more
>> useful.
>
>
> Among million use cases for mq, can anybody explain the mq equivalent of
> git stash?
>
> My use case: I want to put my current changes away temporarily (into
> stash), do some unrelated changes, commit them and then get my previous
> changes back (removing them from stash). How do I do this with mq?
when someone will answer this question, it would be _very_ much
appreciated if the answer were put back into both
-- http://mercurial.selenic.com/wiki/GitConcepts which suggests the
ShelveExtension or the AtticExtension neither of which is distributed
with mercurial
-- http://mercurial.selenic.com/wiki/MqExtension which does not mention
the word "stash" at all
thanks in advance.
--
Sam Steingold (http://sds.podval.org/) on Ubuntu 11.10 (oneiric) X 11.0.11004000
http://openvotingconsortium.org http://dhimmi.com http://mideasttruth.com
http://www.PetitionOnline.com/tap12009/ http://jihadwatch.org http://pmw.org.il
Who is General Failure and why is he reading my hard disk?
anatoly techtonik
> * anatoly techtonik <grpu...@tznvy.pbz> [2011-12-12 18:15:38 +0300]:
> On Jan 12, 2008 3:27:01 pm, Matt Mackall wrote:when someone will answer this question, it would be _very_ much
>> On Sat, 2008-01-12 at 17:13 -0600, Phillip Koebbe wrote:
>>
>>> I was reading earlier today about "git stash" and was thinking it
>>> would be very useful to me. Is something like that available in hg?
>>
>> You might be interested in mq, which is about a million times more
>> useful.
>
>
> Among million use cases for mq, can anybody explain the mq equivalent of
> git stash?
>
> My use case: I want to put my current changes away temporarily (into
> stash), do some unrelated changes, commit them and then get my previous
> changes back (removing them from stash). How do I do this with mq?
appreciated if the answer were put back into both
-- http://mercurial.selenic.com/wiki/GitConcepts which suggests the
ShelveExtension or the AtticExtension neither of which is distributed
with mercurial
-- http://mercurial.selenic.com/wiki/MqExtension which does not mention
the word "stash" at all
thanks in advance.
--
anatoly t.
Tom Anderson
Some combination of qnew, qrefresh, qpop, and qpush.
Try this:
$ # first set up a repo and enable MQ
$ hg init anatoly
$ cd anatoly
$ cat >.hg/hgrc <<EOF
[extensions]
mq =
EOF
$ # some base data
$ echo apples >fruit
$ echo cheddar >cheese
$ hg add .
adding cheese
adding fruit
$ hg commit -m 'initial commit'
$ # some work in progress
$ echo bananas >fruit
$ hg status
M fruit
$ cat fruit
bananas
$ # stash!
$ hg qnew stash
$ hg qpop -a
popping stash
patch queue now empty
$ hg status
$ cat fruit
apples
$ # some unrelated changes
$ echo brie >cheese
$ hg commit -m 'second commit'
$ # unstash!
$ hg qpush stash
applying stash
now at: stash
$ hg status
$ cat fruit
bananas
Having done that, you have a patch called stash, so you can't do qnew
again. You could either pick a new name, or do a qrefresh instead of a
qnew (i think).
Roughly, in this situation:
qnew = "create a new patch, and add all my current uncommitted changes
to that patch"
qrefresh = "add all my current uncommitted changes to an existing patch"
qpop = "remove a patch from the working directory"
qpush = "add a patch to the working directory"
Because MQ allows multiple patches, it treats patches as named
objects, which makes it a bit more verbose than Git's stash for this
use case. Note that there other extensions which provide a simpler
stash behaviour which are more concise.
tom
--
Tom Anderson | e2x Ltd, 1 Norton Folgate, London E1 6DB
(e) t...@e2x.co.uk | (m) +44 (7960) 989794 | (f) +44 (20) 7100 3749
anatoly techtonik
> hg qnew -f [-i] [-m "reminder message"] some-patch-name [files…]On 2011-12-12, at 16:15 , anatoly techtonik wrote:
> Quoting http://markmail.org/message/lglewvoffuxnffbz
> On Jan 12, 2008 3:27:01 pm, Matt Mackall wrote:
>> On Sat, 2008-01-12 at 17:13 -0600, Phillip Koebbe wrote:
>>> I was reading earlier today about "git stash" and was thinking it
>>> would be very useful to me. Is something like that available in hg?
>> You might be interested in mq, which is about a million times more
>> useful.
> Among million use cases for mq, can anybody explain the mq equivalent of
> git stash?
>
> My use case: I want to put my current changes away temporarily (into
> stash), do some unrelated changes, commit them and then get my previous
> changes back (removing them from stash). How do I do this with mq?
> hg qpop
Sam Steingold
>
> $ # unstash!
> $ hg qpush stash
> applying stash
> now at: stash
> $ hg status
> $ cat fruit
> bananas
usually at this point I do not want "hg status" to be empty, i.e., I do
not want the changes pushed from the stash to be already committed.
i.e.
$ hg status
M fruit
$ cat fruit
bananas
--
Sam Steingold (http://sds.podval.org/) on Ubuntu 11.10 (oneiric) X 11.0.11004000
http://openvotingconsortium.org http://pmw.org.il http://www.memritv.org
http://memri.org http://truepeace.org http://iris.org.il
Why do we want intelligent terminals when there are so many stupid users?
Masklinn
anatoly techtonik
anatoly techtonik
Some combination of qnew, qrefresh, qpop, and qpush.> On Jan 12, 2008 3:27:01 pm, Matt Mackall wrote:
>> On Sat, 2008-01-12 at 17:13 -0600, Phillip Koebbe wrote:
>>
>>> I was reading earlier today about "git stash" and was thinking it
>>> would be very useful to me. Is something like that available in hg?
>>
>> You might be interested in mq, which is about a million times more
>> useful.
>
> Among million use cases for mq, can anybody explain the mq equivalent of git
> stash?
>
> My use case: I want to put my current changes away temporarily (into stash),
> do some unrelated changes, commit them and then get my previous changes back
> (removing them from stash). How do I do this with mq?
Try this:
$ hg status
$ cat fruit
bananas
Brendan Cully
You've popped the patch at this point. It's tucked away in a patch
file in .hg/patches right now. If you want to see the diff, the
simplest way is to 'hg qpush' then 'hg qdiff'. Alternatively, 'cat
.hg/patches/stash' is equivalent to git stash show.
When you want to put the changes back into the working directory at
the very end, run 'hg qref -X .' from the root to transfer them out of
the patch. (Admittedly, this invocation has git-like clarity.)
Masklinn
>
> The whole point of stashing stuff is to restore it later in the same form.
> With 'hg qnew/qpop/qpush` I can't get my changes back. After I do 'hg
> push', 'hg diff/st' is empty.
You may also be interested in the *third* paragraph.
anatoly techtonik
When you want to put the changes back into the working directory at
the very end, run 'hg qref -X .' from the root to transfer them out of
the patch. (Admittedly, this invocation has git-like clarity.)
anatoly techtonik
On 2011-12-12, at 17:33 , anatoly techtonik wrote:Please read comments in full before saying they're incomplete, the answers you're looking for are in the rest of the second paragraph. Read that paragraph beyond the first phrase.
>
> The whole point of stashing stuff is to restore it later in the same form.
> With 'hg qnew/qpop/qpush` I can't get my changes back. After I do 'hg
> push', 'hg diff/st' is empty.
You may also be interested in the *third* paragraph.
Brendan Cully
qdiff includes the working directory changes too. If it's in hg
diff, it's in your working directory. If you cat .hg/patches/stash,
however, that should be empty.
> > hg qdel stash
> abort: cannot delete applied patch stash
> > hg qpop
> abort: local changes found, refresh first
>
> catch22 =)
Hmm, I thought I remembered that qpop didn't object unless the patch
file touched modified files in the working directory (which it
wouldn't here since the patch file will be empty). I guess you would
have to qpop -f
This isn't a beautiful user experience, but it should work.
This ugliness is the reason people have written the shelve and attic
extensions.
Masklinn
> I am puzzled. After 'hg qref -X .', 'hg qdiff' and 'hg diff' show the same
> info. Did I break something?
* A working copy in its original (dirty) state
* A completely empty applied MQ patch
It's perfectly normal that qdiff and diff show the same output, as qdiff is the sum of the current mq patch and the current working copy diff. If the patch is empty, it is the same thing as a direct diff.
Masklinn
>> hg qpush
>> hg qfinish
> abort: no revisions specified
>
> It is not clear which revisions should I (as a user) specify.
> I understand
> that I should commit with 'qfinish' first to be able to do 'hg strip -k'
> after.
It's not necessary.
Chuck Kirschman
I think "hg shelve" and "hg unshelve" are what you're looking for. It's
a handy extension that does exactly that. It's not quite the swiss army
knife / ball of yarn that MQ is.
http://mercurial.selenic.com/wiki/ShelveExtension
chuck
Angel Ezquerra
On Dec 12, 2011 8:10 PM, "Chuck Kirschman" <Chuck.K...@bentley.com> wrote:
>
> On 12/12/2011 10:15 AM, anatoly techtonik wrote:
>>
>> Quoting http://markmail.org/message/lglewvoffuxnffbz
>>
>> On Jan 12, 2008 3:27:01 pm, Matt Mackall wrote:
>>
>> On Sat, 2008-01-12 at 17:13 -0600, Phillip Koebbe wrote:
>>
>> I was reading earlier today about "git stash" and was thinking it
>> would be very useful to me. Is something like that available in hg?
>>
>> You might be interested in mq, which is about a million times more
>> useful.
>>
>>
>> Among million use cases for mq, can anybody explain the mq equivalent of
>> git stash?
>>
>> My use case: I want to put my current changes away temporarily (into
>> stash), do some unrelated changes, commit them and then get my previous
>> changes back (removing them from stash). How do I do this with mq?
>>
>> Please, CC.
>> --
>> anatoly t.
>>
>>
>
> I think "hg shelve" and "hg unshelve" are what you're looking for. It's a handy extension that does exactly that. It's not quite the swiss army knife / ball of yarn that MQ is.
> http://mercurial.selenic.com/wiki/ShelveExtension
Also, if you don't mind using a GUI tool, both the shelve and the mq extensions come builtin with TortoiseHg. "Stashing" (called "shelving" in the mercurial and TortoiseHg jargon) changes is super easy using the tortoisehg workbench.
Angel
Brendan Cully
> This isn't a beautiful user experience, but it should work.
>
> This ugliness is the reason people have written the shelve and attic
> extensions.
By the way, I think another reason this is as ugly as it is, is that
shelve/stash is probably mostly used by new converts from
CVS/svn. Once you get into mq, it feels much better to keep your code
always in an mq patch rather than leaving it unprotected in the
working directory. So experienced users don't spend much time on the
qref/qpop -f bits of the process.
anatoly techtonik
This isn't a beautiful user experience, but it should work.
This ugliness is the reason people have written the shelve and attic
extensions.
anatoly techtonik
On 2011-12-12, at 18:09 , anatoly techtonik wrote:`hg qref -X` removes everything from the MQ patch, so you now have:
> I am puzzled. After 'hg qref -X .', 'hg qdiff' and 'hg diff' show the same
> info. Did I break something?
* A working copy in its original (dirty) state
* A completely empty applied MQ patch
It's perfectly normal that qdiff and diff show the same output, as qdiff is the sum of the current mq patch and the current working copy diff. If the patch is empty, it is the same thing as a direct diff.
anatoly techtonik
On 2011-12-12, at 18:27 , anatoly techtonik wrote:either `tip`, or just use the `-a` flag to finish "all applied patches" (there's only one).
>> hg qpush
>> hg qfinish
> abort: no revisions specified
>
> It is not clear which revisions should I (as a user) specify.
It's not necessary.
> I understand
> that I should commit with 'qfinish' first to be able to do 'hg strip -k'
> after.
anatoly techtonik
On Monday, 12 December 2011 at 09:46, Brendan Cully wrote:By the way, I think another reason this is as ugly as it is, is that
> This isn't a beautiful user experience, but it should work.
>
> This ugliness is the reason people have written the shelve and attic
> extensions.
shelve/stash is probably mostly used by new converts from
CVS/svn. Once you get into mq, it feels much better to keep your code
always in an mq patch rather than leaving it unprotected in the
working directory. So experienced users don't spend much time on the
qref/qpop -f bits of the process.
Matt Mackall
> On Mon, Dec 12, 2011 at 8:47 PM, Masklinn <mask...@masklinn.net> wrote:
>
> > On 2011-12-12, at 18:09 , anatoly techtonik wrote:
> > > I am puzzled. After 'hg qref -X .', 'hg qdiff' and 'hg diff' show the
> > same
> > > info. Did I break something?
> > `hg qref -X` removes everything from the MQ patch, so you now have:
> > * A working copy in its original (dirty) state
> > * A completely empty applied MQ patch
> >
> > It's perfectly normal that qdiff and diff show the same output, as qdiff
> > is the sum of the current mq patch and the current working copy diff. If
> > the patch is empty, it is the same thing as a direct diff.
> >
>
> It appears that misunderstood `hg qdiff` command from the moment I first
> used it (and it was a while since then). =) I thought it is used to show
> the contents of current patch.
The fundamental thing to understand about MQ is that an applied patch IS
A CHANGESET. Thus all commands that can show the diff of an existing
changeset will work, no special MQ-specific commands are necessary.
So you can use:
- hg log -vpr <rev>
- hg diff -c <rev>
- hg export <rev>
- hg outgoing -p
etc..
--
Mathematics is the supreme nostalgia of our time.
Matt Mackall
> On Mon, Dec 12, 2011 at 10:25 PM, Brendan Cully <bre...@kublai.com> wrote:
>
> > On Monday, 12 December 2011 at 09:46, Brendan Cully wrote:
> > > This isn't a beautiful user experience, but it should work.
> > >
> > > This ugliness is the reason people have written the shelve and attic
> > > extensions.
> >
> > By the way, I think another reason this is as ugly as it is, is that
> > shelve/stash is probably mostly used by new converts from
> > CVS/svn. Once you get into mq, it feels much better to keep your code
> > always in an mq patch rather than leaving it unprotected in the
> > working directory. So experienced users don't spend much time on the
> > qref/qpop -f bits of the process.
> >
>
> I think you are wrong in both cases. Despite my vast experience with SVN,
> CVS and cvs2svn, this post was inspired by git user, who showed me how do
> they live without MQ. I am using queues for more than 6 months for sure,
> but I am not as enthusiastic as you with them for several reasons: 1. I
> still can not get enough time to learn them completely. 2. I can't
> reorder/edit them without using editor to mess with .hg/patches.
hg qpush --move
> 3. Many
> commands, but hard to do basic things - I still don't know if it is
> possible to edit commit message with my editor after the patch is created,
> or set it when finalizing MQ.
hg qref -e
--
Mathematics is the supreme nostalgia of our time.
anatoly techtonik
2. I can'thg qpush --move
> reorder/edit them without using editor to mess with .hg/patches.
> 3. Manyhg qref -e
> commands, but hard to do basic things - I still don't know if it is
> possible to edit commit message with my editor after the patch is created,
> or set it when finalizing MQ.
anatoly techtonik
Matt Mackall
s/like//
Disable mq while a patch is applied and consult 'hg log' to achieve
enlightenment. Provided you understand how changeset hashes are
computed, you will also understand why it's only possible to qref -e the
top-most patch or reorder unapplied patches.
Frank Kingswood
It's not clear why you would qpush, qfinish and immediately strip -k it.
If you want to work on it just
$ hg qpush
[work]
$ hg qdiff # show current changes including the stacked ones
to save your work in progress and do something else temporarily again:
$ hg qrefresh # save my changes
$ hg qpop
Note that you can pull and update to a different revision between qpop
and qpush to rebase your changes on top of the new revision.
If you want to delete the changes then
$ hg qdelete stash-work-in-progress
> Not very intuitive either, but at least easier to remember. This
> solution is better in a way that it doesn't require me to remember the
> name of the patch with stash, but worse, because I can forget to specify
> -k argument one day and lose changes. I also did not understand how can
> it be so that it is not necessary to do `qfinish` before `strip -k`?
> From what I can see `strip` doesn't work with queues.
It just so happens that strip is implemented in this extension.
Losing the named patch just to be able to make changes to it seems like
a downside of git stash.
Frank
--
------------------------------------------------------------------------
Frank A. Kingswood fr...@kingswood-consulting.co.uk
Cambridge, United Kingdom +44-7545-209 100
Arne Babenhauserheide
> I don't want to spread FUD replying to the 3rd one, and it is not my aim. I
> just want to say that a while ago Mercurial the power of different HG
> extensions was a huge advantage compared to other VCS. Now that other VCS
> also support all the options an average user needs, it is becoming a major
> disadvantage of Mercurial that its extensions don't work "by default".
> Other extension is not an preferred option. In addition Matt itself
> recommended MQ as a better 'git stash' in Mercurial.
Frankly I don’t really like the workflow with MQ either - it is too powerful
for an extension and has tons of usecases which need knowledge which partly
replaces core commands. Also it reduces the itch to create easy to use
advanced commands, because it can somehow do everything…
But (to me) the point of extensions is not mainly that you can more easily add
advanced functionality to Mercurial (which is true nontheless). The main
advantage is that dangerous functionality can be put behind a layer of
insulation, so users have to consciously activate it and new users are in less
danger of losing work.
I can give a new user Mercurial and he can just use it.
I agree though that there is some functionality which would be nice to have by
default. Luckily there is work being done on that: To get things like stash,
but as fully integrated part of the workflow, there’s been work on the LiquidHG
concept for over a year, which aims to bring safe history editing of
unpublished changes to Mercurial.
It just takes time to do it right…
If you’re interested, have a look at the “phases” patches.
Best wishes,
Arne
Masklinn
> Losing the named patch just to be able to make changes to it seems like a downside of git stash.
Now can you express stash operations in terms of mq? Of course at this thread demonstrates, but each stash commands balloons into 2 to 3 mq commands with somewhat cryptic behaviours, and a simple and straightforward tasks becomes… awkward.
That's why, even though I know and *love* mq, I have shelve installed and enabled. I don't need an 18-wheeler to go and get a pound of sugar at the grocery store 'round the corner, a pair of shoes will do.
Arne Babenhauserheide
> On 13 déc. 2011, at 04:04, Frank Kingswood <frank@kingswood-
consulting.co.uk> wrote:
> > Losing the named patch just to be able to make changes to it seems like
> > a downside of git stash.
> is exactly what it says, it's a place where you temporarily stash changes
> when you need to do something else. Stash manages interruptions, not
> changes. As a result, not having names is neither a loss nor a bug: they
> would add needless complexity to the simple task of "put this [stuff] away
> for a while". Every diff does not need a name.
How about
hg diff > 1.patch
hg revert .
(work)
hg import --no-commit 1.patch
?
Best wishes,
Arne
Masklinn
>
> hg diff > 1.patch
> hg revert .
> (work)
> hg import --no-commit 1.patch
>
> ?
Shelve extensions also generally take advantage of `record`-type features to shelve only parts of the current working copy changes
Paul Boddie
>
> Yes. Not as beautiful as Matt's ad promised. =) You also need to type in
> your patch name in the last command, so it becomes much harder to be
> automated.
I don't really know why Matt made that "ad". Every query about using mq
I can recall him responding to has elicited the advice to try something
simpler first. Maybe he knows that you like a challenge. ;-)
[...]
> At least we now all agree that this is ugly and user experience is pretty
> bad compared to Git. The question is if you are going to fix that?
I'm not sure that it is a bad user experience if you just use the other
extensions. Maybe mq makes more sense if you're used to stuff like
quilt, with which I've had some recent, brief experiences and which
looks quite similar superficially.
Paul