hg qrefresh
John J Barton
This is the bit that surprises me:
hg status
These show you only uncommitted edits�work that's neither committed
nor in an MQ patch. After a qrefresh, they'll both be empty.
Based on this description:
hg qrefresh
Update the current patch to include your latest uncommitted changes
I guessed that the file system is examined and any diffs from the repo
are stored in the patch at the top of the queue. But something else
mysterious also happens because after a qrefresh the hg status will be
empty? Where are my changes with respect to the repo base at this point?
Is hg qrefresh doing something to the repo?
jjb
Joshua Cranmer
> Is hg qrefresh doing something to the repo?
The way mq is actually implemented internally is that it's changesets
with a few magical properties (namely, the hg qpop/hg qpush/hg qref
modifications).
hg status (and other commands like hg diff, etc.) therefore look at the
changes to the repo since the last changeset, i.e., the current mq patch
you are working on.
Ehsan Akhgari
inside the queue, and commits them as a changeset to the local repository,
and tags it as qtip. So, hg status would return empty, because there is no
_uncommitted_ edits in the repository at this point (note that qrefresh
commits the merged patch in your repository).
If you want to see the edits with respect to the repo base, you should do:
hg diff -r qbase:qtip
Which shows the diff between qbase (the first patch in your mq) and qtip
(the topmost applied patch in your queue).
--
Ehsan
<http://ehsanakhgari.org/>
On Wed, Dec 2, 2009 at 7:09 PM, John J Barton
<johnj...@johnjbarton.com>wrote:
> I think I am missing something pretty important about hg queues.
>
> This is the bit that surprises me:
>
> hg status
> These show you only uncommitted edits—work that's neither committed nor
> in an MQ patch. After a qrefresh, they'll both be empty.
>
> Based on this description:
>
> hg qrefresh
> Update the current patch to include your latest uncommitted changes
>
> I guessed that the file system is examined and any diffs from the repo are
> stored in the patch at the top of the queue. But something else mysterious
> also happens because after a qrefresh the hg status will be empty? Where are
> my changes with respect to the repo base at this point?
>
> Is hg qrefresh doing something to the repo?
>
> jjb
> _______________________________________________
> dev-builds mailing list
> dev-b...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-builds
>
John J Barton
> hg qrefresh takes your uncommitted edits, merges them with the topmost patch
> inside the queue, and commits them as a changeset to the local repository,
> and tags it as qtip. So, hg status would return empty, because there is no
> _uncommitted_ edits in the repository at this point (note that qrefresh
> commits the merged patch in your repository).
I want to get to the state where the edits from my topmost patch are on
my working copy (and the repo has all the rest I guess). That way I can
hg revert some files whose edits got in to the topmost patch.
Plus I can then use hg status to see what files are in the patch, but
maybe there is another way to do that.
jjb
Ehsan Akhgari
<johnj...@johnjbarton.com>wrote:
> Ehsan Akhgari wrote:
>
>> hg qrefresh takes your uncommitted edits, merges them with the topmost
>> patch
>> inside the queue, and commits them as a changeset to the local repository,
>> and tags it as qtip. So, hg status would return empty, because there is
>> no
>> _uncommitted_ edits in the repository at this point (note that qrefresh
>> commits the merged patch in your repository).
>>
>
> I want to get to the state where the edits from my topmost patch are on my
> working copy (and the repo has all the rest I guess). That way I can hg
> revert some files whose edits got in to the topmost patch.
>
You mean you want to undo a qrefresh? I don't think there's any easy way to
do that. If you've set up your mq as a repo, and you have qcommit-ed before
the last qref, you may be able to hg diff inside .hg/patches, and get the
latest qrefresh changes, and do something with that, but that would be
scary.
You should only qrefresh when you're sure that you want to keep your current
work, and qcommit often so that if things go wrong you can always go back
and revert your mq changes.
> Plus I can then use hg status to see what files are in the patch, but maybe
> there is another way to do that.
To get the list of files in your topmost mq patch, you can simply do:
hg tip -p | lsdiff
--
Ehsan
<http://ehsanakhgari.org/>
John J Barton
> On Wed, Dec 2, 2009 at 7:26 PM, John J Barton
> <johnj...@johnjbarton.com>wrote:
>
>> Ehsan Akhgari wrote:
>>
>>> hg qrefresh takes your uncommitted edits, merges them with the topmost
>>> patch
>>> inside the queue, and commits them as a changeset to the local repository,
>>> and tags it as qtip. So, hg status would return empty, because there is
>>> no
>>> _uncommitted_ edits in the repository at this point (note that qrefresh
>>> commits the merged patch in your repository).
>>>
>> I want to get to the state where the edits from my topmost patch are on my
>> working copy (and the repo has all the rest I guess). That way I can hg
>> revert some files whose edits got in to the topmost patch.
>>
>
> You mean you want to undo a qrefresh? I don't think there's any easy way to
> do that. If you've set up your mq as a repo, and you have qcommit-ed before
> the last qref, you may be able to hg diff inside .hg/patches, and get the
> latest qrefresh changes, and do something with that, but that would be
> scary.
>
> You should only qrefresh when you're sure that you want to keep your current
> work, and qcommit often so that if things go wrong you can always go back
> and revert your mq changes.
So I can see I was way off base. It sounds like |hg qrefresh| is much
more like |svn commit|. The whole queue thing is much more like named
commits on a stack. But in the hg world these commits are to a local
repo, so the rest of the planet does not see my mistakes. Until later.
Sounds like I better learn about hg qcommit. Thanks!
>
>
>> Plus I can then use hg status to see what files are in the patch, but maybe
>> there is another way to do that.
>
>
> To get the list of files in your topmost mq patch, you can simply do:
>
> hg tip -p | lsdiff
That gives "lsdiff: command not found".
>
> --
> Ehsan
> <http://ehsanakhgari.org/>
Zack Weinberg
> Ehsan Akhgari wrote:
> > hg qrefresh takes your uncommitted edits, merges them with the
> > topmost patch inside the queue, and commits them as a changeset to
> > the local repository, and tags it as qtip. So, hg status would
> > return empty, because there is no _uncommitted_ edits in the
> > repository at this point (note that qrefresh commits the merged
> > patch in your repository).
>
> I want to get to the state where the edits from my topmost patch are
> on my working copy (and the repo has all the rest I guess). That way
> I can hg revert some files whose edits got in to the topmost patch.
Usually what I do when I get into this kind of mess is 'qpop' the
patch with unwanted changes in it, and then edit the file in
.hg/patches. Emacs has a mode for editing diffs that keeps all the
line counts accurate for you, and can delete entire chunks or files.
If you didn't rename, delete, or add any files, you could also 'qpop'
the patch, manually re-apply it with the standalone 'patch' utility,
and then truncate the file in .hg/patches.
zw
Benjamin Smedberg
> I want to get to the state where the edits from my topmost patch are on
> my working copy (and the repo has all the rest I guess). That way I can
> hg revert some files whose edits got in to the topmost patch.
You can specify what files should be included in the current patch:
hg qrefresh file file2 directory
Or, you can specify files to exclude while refreshing:
hg qrefresh -X not/this/directory
When you do this, the files which are not in the patch will become local
changes in your working directory again.
--BDS
Blair McBride
> If you want to see the edits with respect to the repo base, you should do:
>
> hg diff -r qbase:qtip
Or, the shorter version: hg qdiff
And the MQ equivalent to "hg status" is: hg status --rev -2:.
I find having this in my .hgrc helps (less typing):
[alias]
qstatus = status --rev -2:.
Then its just: hg qstatus
- Blair
John J. Barton
gavin suggested this and I was successful in using it to remove then
revert the files I did not want in my patch.
It did have two seemingly bizarre properties.
1) If you issue two of these commands with different paths, the first
one is effectively nullified. I can see why -- the change taken out by
the first becomes fodder for the second qrefresh -- but it was a surprise.
2) If you misspell the path, there is no behavior difference from
success, so you have to puzzle about it.
>
> --BDS
Ehsan Akhgari
<johnj...@johnjbarton.com>wrote:
> To get the list of files in your topmost mq patch, you can simply do:
>>
>> hg tip -p | lsdiff
>>
>
>
> That gives "lsdiff: command not found".
>
You need to have patchutils installed for the lsdiff command (and a bunch of
other useful commands).
--
Ehsan
<http://ehsanakhgari.org/>
Ehsan Akhgari
Blair McBride
be the one you're working on). I think using -1 (as in: "hg status --rev
-1:.") is the default, comparing the last commit to the working set.
I don't find it useful to compare all patches in the queue - only the
top one.
- Blair