I'm a bit confused by hg shelve because the documentation is rather sparse. Somehow I got a commit in my log of the form:
changeset: 29:ad47ed1ca915
parent: 27:afca280f2884
user: shelve#localhost
date: Wed Jun 08 15:30:36 2016 -0600
summary: changes to: ...
I'm confused as to where this came from. It was my understanding that shelve was just stuffing things on the local machine and that they wouldn't get in the history. Am I misunderstanding that?
Here's my hg command history:
hg status
hg shelve list
hg shelve --list
hg unshelve
hg unshelve
hg resolve
hg resolve -all
hg resolve --all
hg resolve --all
hg clone a/ b
# By this point we have the commit (since 28 is after 27)
hg update -r 28
EDIT:
Ok, so the problem seems to be a partial unshelve. However, because I pull the changesets else where now I'm stuck with the changesets and am not sure what to do :(
EDIT2: Here's an example of how to cause this problem:
~ $ cd tmp
~/tmp $ mkdir shelve shelve/a
~/tmp $ cd shelve/a
~/tmp/shelve/a $ hg init
~/tmp/shelve/a $ echo a > a
~/tmp/shelve/a $ hg add a
~/tmp/shelve/a $ hg commit -m "a as a"
~/tmp/shelve/a $ cd ..
~/tmp/shelve $ hg clone a b
updating to branch default
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
~/tmp/shelve $ cd b
~/tmp/shelve/b $ echo aa > a
~/tmp/shelve/b $ hg commit -m "a as aa"
~/tmp/shelve/b $ cd ../a
~/tmp/shelve/a $ echo aaa > a
~/tmp/shelve/a $ hg shelve
shelved as default
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
~/tmp/shelve/a $ hg pull -u ../b
pulling from ../b
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
~/tmp/shelve/a $ hg unshelve
unshelving change 'default'
rebasing shelved changes
rebasing 2:6696488053d1 "changes to: a as a" (tip)
merging a
3 files to edit
was merge successful (yn)? n
merging a failed!
unresolved conflicts (see 'hg resolve', then 'hg unshelve --continue')
~/tmp/shelve/a $ hg heads
changeset: 2:6696488053d1
tag: tip
parent: 0:845abf4a2513
user: shelve#localhost
date: Thu Jun 16 19:44:05 2016 -0600
summary: changes to: a as a
changeset: 1:e1f75f582f85
user: Alex Orange <crazycasta#gmail.com>
date: Thu Jun 16 19:44:05 2016 -0600
summary: a as aa
Here's my solution. Also shows a bit more of the problem. The problem comes if you do an hg pull with an unresolved unshelve.
~ $ cd tmp
~/tmp $ cd shelve/a
~/tmp/shelve/a $ hg resolve a
merging a
3 files to edit
continue: hg unshelve --continue
~/tmp/shelve/a $ cd ../b
~/tmp/shelve/b $ echo Cause failure
Cause failure
~/tmp/shelve/b $ hg pull ../a
pulling from ../a
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files (+1 heads)
(run 'hg heads' to see heads, 'hg merge' to merge)
~/tmp/shelve/b $ hg heads
changeset: 2:6696488053d1
tag: tip
parent: 0:845abf4a2513
user: shelve#localhost
date: Thu Jun 16 19:44:05 2016 -0600
summary: changes to: a as a
changeset: 1:e1f75f582f85
user: Alex Orange <crazycasta#gmail.com>
date: Thu Jun 16 19:44:05 2016 -0600
summary: a as aa
~/tmp/shelve/b $ cd ../a
~/tmp/shelve/a $ hg unshelve --continue
rebasing 2:6696488053d1 "changes to: a as a" (tip)
unshelve of 'default' complete
~/tmp/shelve/a $ hg commit -m "a as aaa"
~/tmp/shelve/a $ cd ../b
~/tmp/shelve/b $ hg pull
pulling from /home/crazycasta/tmp/shelve/a
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
(run 'hg update' to get a working copy)
~/tmp/shelve/b $ echo Problem
Problem
~/tmp/shelve/b $ hg heads
changeset: 3:a804c9f51cd6
tag: tip
parent: 1:e1f75f582f85
user: Alex Orange <crazycasta#gmail.com>
date: Thu Jun 16 20:02:43 2016 -0600
summary: a as aaa
changeset: 2:6696488053d1
parent: 0:845abf4a2513
user: shelve#localhost
date: Thu Jun 16 19:44:05 2016 -0600
summary: changes to: a as a
~/tmp/shelve/b $ echo Solution
Solution
~/tmp/shelve/b $ hg strip -r 2
saved backup bundle to /home/crazycasta/tmp/shelve/b/.hg/strip-backup/6696488053d1-313495de-backup.hg
~/tmp/shelve/b $ hg heads
changeset: 2:a804c9f51cd6
tag: tip
user: Alex Orange <crazycasta#gmail.com>
date: Thu Jun 16 20:02:43 2016 -0600
summary: a as aaa
Related
Is there a command to import a patch already in the repository to your local sources with mercurial ?
You can use hg export -o filename to do this.
$ mkdir repo
$ cd repo
$ hg init
$ echo a > a
$ hg add a
$ hg commit -m "Commit 0"
$ hg export -o patch.txt
If you open patch.txt, it will look like
# HG changeset patch
# User Your Name <your email address>
# Date 1482413390 -19800
# Thu Dec 22 18:59:50 2016 +0530
# Node ID 6e46bc10f352958b841995d47e6944ae4e9ebd89
# Parent 0000000000000000000000000000000000000000
Commit 0
diff -r 000000000000 -r 6e46bc10f352 a
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/a Thu Dec 22 18:59:50 2016 +0530
## -0,0 +1,1 ##
+a
This is quite similar to what happens when you mail your patches to a mailing list. For more, you can do hg help export or go to Tutorial Export.
You can then import it where ever you want by doing hg import filename and the patch will be applied to that repository.
$ cd ..
$ mkdir repo0
$ hg init
$ hg import ../repo/patch.txt
applying ../repo/patch.txt
$ hg tip
changeset: 0:6e46bc10f352
tag: tip
user: Your Name <your email address>
date: Thu Dec 22 18:59:50 2016 +0530
summary: Commit 0
$ ls
a
You can see the patch is applied to your new directory.
In Mercurial repo:
1) I've checked out (updated) from default
2) I've edited something
3) I've realized I need a branch to experiment with my edits
4) When I try to create a branch Mercurial claims I have uncommitted changes
If I don't get mistaken, in git allows you to checkout -b in such situation. I need to create a branch and commit my changes there.
UPDATE
It turned out that hg is as smart as git, and ALLOWS creating branches when having uncommitted changes. So, the problem on step 4 had no relation to hg.
This works just fine for me:
ry4an#four:~$ hg init dan
ry4an#four:~$ cd dan
ry4an#four:~/dan$ echo text > afile
ry4an#four:~/dan$ hg commit -Am added
adding afile
ry4an#four:~/dan$ echo more >> afile
ry4an#four:~/dan$ hg branch newbranch
marked working directory as branch newbranch
(branches are permanent and global, did you want a bookmark?)
ry4an#four:~/dan$ hg commit -m another
ry4an#four:~/dan$ hg log
changeset: 1:84b54b473852
branch: newbranch
tag: tip
user: Ry4an Brase <ry4an-hg#ry4an.org>
date: Wed Dec 04 11:36:52 2013 -0500
summary: another
changeset: 0:b07d96580927
user: Ry4an Brase <ry4an-hg#ry4an.org>
date: Wed Dec 04 11:36:13 2013 -0500
summary: added
When I ran hg branch newbranch nothing was actually created. The hg branch command just tells Mercurial what branch the next commit should be on, and indeed when I did that commit the log shows it was on newbranch. I had uncommitted changes when I did the hg branch line and there was no warning or error saying I couldn't do it -- how, specifically, are you trying to create that branch?
I forgot to tag and older version of my files with a release tag. The older version is at r13, latest is about r65. I cloned the latest repository to a new directory, did an "hg update -r13" to get the older code I wanted to tag, then did the tag command, but got the message:
abort: not at a branch head (use -f to force)
Is it safe to use the -f option in this situation?
I guess you can still do the tagging right in the repo without updating yourself to a particular revision.
hg tag -r 13 tagname
See the details at Mercurial wiki.
I tried testing it :
temp $ hg init .
temp $ touch a.txt
temp $ hg add a.txt
temp $ hg commit -m "added a"
temp $ hg status
temp $ echo "sdwwdd" >> a.txt
temp $ hg commit -m "modified a"
temp $ echo "\neddwedd" >> a.txt
temp $ hg commit -m "modified a again"
temp $ hg log
changeset: 2:ef40a402fdab
tag: tip
user: "xxxx"
date: Fri Dec 23 16:51:48 2011 -0800
summary: modified a again
changeset: 1:d630dc3e2e3a
user: "xxxx"
date: Fri Dec 23 16:51:31 2011 -0800
summary: modified a
changeset: 0:7c9917f24515
user: "xxxx"
date: Fri Dec 23 16:51:04 2011 -0800
summary: added a
Output:
temp $ hg tag -r 1 a.txt a_1
temp $ hg tags
tip 3:e3157256098f
a_1 1:d630dc3e2e3a
a.txt 1:d630dc3e2e3a
temp $ hg tag -r 1 all_1
temp $ hg tags
tip 4:a643971911d8
all_1 1:d630dc3e2e3a
a_1 1:d630dc3e2e3a
a.txt 1:d630dc3e2e3a
we're trying to find a way to see the entire changeset of one or more incoming revisions in a mercurial repository inside the pretxnchangegroup hook. We use version 1.6.3.
We can get the first incoming change with $HG_NODE, but hg tip still points to the oldest, committed change, not to the one that we're about to tack on. The same for hg log -rNode:
We cannot even seem to get the diff of $HG_NODE in this hook, hg log just says "unknown revision"
It seems like this is related to http://groups.google.com/group/mercurial_general/browse_thread/thread/9321b94b08ab04b9
Has anyone had the same problem and solved it somehow?
It should definitely be the case that both tip and log reflect the post-arrival information. Are you sure that the directory in which you're running those commands is that of the repository triggehg clone hooktest hooktest-clone
ring the hook? The only way I could see that not being the case were if you were using hg -R, which you'd know.
Here's a test script you should be able to paste into a (unix or cygwin) shell:
hg init hooktest
echo this >> hooktest/afile
echo -e '[hooks]\npretxnchangegroup = hg log && hg tip' >> hooktest/.hg/hgrc
hg -R hooktest commit -A -m 'initial commit'
hg clone hooktest hooktest-clone
echo more >> hooktest-clone/afile
hg -R hooktest-clone commit -m 'second commit'
hg -R hooktest-clone push
When I paste that I get:
ry4an#hail [~/hg] % hg init hooktest
ry4an#hail [~/hg] % echo this >> hooktest/afile
ry4an#hail [~/hg] % echo -e '[hooks]\npretxnchangegroup = hg log && hg tip' >> hooktest/.hg/hgrc
ry4an#hail [~/hg] % hg -R hooktest commit -A -m 'initial commit'
adding afile
ry4an#hail [~/hg] % hg clone hooktest hooktest-clone
updating working directory
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
ry4an#hail [~/hg] % echo more >> hooktest-clone/afile
ry4an#hail [~/hg] % hg -R hooktest-clone commit -m 'second commit'
ry4an#hail [~/hg] % hg -R hooktest-clone push
pushing to /home/msi/ry4an/hg/hooktest
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
changeset: 1:ab2cec57f878
tag: tip
user: Ry4an Brase <ry4an#msi.umn.edu>
date: Wed Nov 03 09:10:40 2010 -0500
summary: second commit
changeset: 0:30db2e527437
user: Ry4an Brase <ry4an#msi.umn.edu>
date: Wed Nov 03 09:10:39 2010 -0500
summary: initial commit
changeset: 1:ab2cec57f878
tag: tip
user: Ry4an Brase <ry4an#msi.umn.edu>
date: Wed Nov 03 09:10:40 2010 -0500
summary: second commit
ry4an#hail [~/hg] %
Where you can see that both 'hg log' and 'hg tip' show the new changeset in the hook.
Does that test run for you?
I had 2 Python similar scripts, that I've since merged into one (and now takes some parameters to differ the behaviour appropriately). Both of the previous files are in the tip of my Mercurial repository. How can I indicate that the new file, is a combination of the 2 older files that I intend to remove?
Also note, that 1 file has been chosen in favor of the other, and some code moved across, so if it's not possible to create a version controlled file with a new name, then assimilating one file's history into the other will suffice.
It's not a perfect solution, and it might be too late to do it this time, but I think hg rename would get you where you want to go. Here's a sequence:
ry4an#hail [~/hg] % mkdir test
ry4an#hail [~/hg] % cd test/
ry4an#hail [~/hg/test] % hg init
ry4an#hail [~/hg/test] % echo stuff > file1
ry4an#hail [~/hg/test] % echo different > file2
ry4an#hail [~/hg/test] % hg commit --addremove -m 'adding both separately'
adding file1
adding file2
ry4an#hail [~/hg/test] % hg rename --force file1 file2
ry4an#hail [~/hg/test] % hg commit -m 'overwrote 2 with 1'
ry4an#hail [~/hg/test] % hg grep --follow different file2
file2:0:different
ry4an#hail [~/hg/test] % hg grep --follow stuff file2
file2:1:stuff
Notice that the file 'grep' find that 'stuff' was in file2 revision 1 and 'different' was in file two revision 0, so both histories are now in file2.
What follows is an example of a merge between two unrelated files "a" and "b".
Please note that I'm abusing a list format because I can't figure out how to use this system. Lines that appear to be headers but start as "summary:" are actually output from hg and happen to be the last line before a blank line. All other headers are my own comments explaining a command/sequence and its output. Commands appear on line that have 'timeless-mbp:...$'. All other lines are output.
Setup
timeless-mbp:~ timeless$ cd /tmp
timeless-mbp:tmp timeless$ rm -rf q
timeless-mbp:tmp timeless$ hg init q
timeless-mbp:tmp timeless$ cd q
Define my username
timeless-mbp:q timeless$ echo '[ui]' > .hg/hgrc
timeless-mbp:q timeless$ echo 'username = timeless' >> .hg/hgrc
First create, add and commit file a
timeless-mbp:q timeless$ echo a > a
timeless-mbp:q timeless$ hg commit -Am a
adding a
Start at a new scratch revision (null)
timeless-mbp:q timeless$ hg up -r null
0 files updated, 0 files merged, 1 files removed, 0 files unresolved
Create, add and commit file b
timeless-mbp:q timeless$ echo b > b
timeless-mbp:q timeless$ hg commit -Am b
adding b
created new head
Switch back to our first file, this is just to create an interleaved version history
timeless-mbp:q timeless$ hg up -r 0
1 files updated, 0 files merged, 1 files removed, 0 files unresolved
Rename a to file because we want to merge it with b under the name "file"
timeless-mbp:q timeless$ hg mv a file
timeless-mbp:q timeless$ hg commit -m 'rename a to file'
Switch back to our second file, this is just to create an interleaved version history
timeless-mbp:q timeless$ hg up -r 1
1 files updated, 0 files merged, 1 files removed, 0 files unresolved
Rename b to file because we want to merge it with a under the name "file"
timeless-mbp:q timeless$ hg mv b file
timeless-mbp:q timeless$ hg commit -m 'rename b to file'
I'm forcing a merge using internal because I don't want a merge tool to pop up, there are other merge tools you could use (e.g. on OS X with modern versions of Mercurial, it tends to pop up FileMerge.app, but that's hard to show in a log).
timeless-mbp:q timeless$ hg --config ui.merge=internal:local merge 2
0 files updated, 1 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
Replace the content with what I want
timeless-mbp:q timeless$ hg cat -r 2 file > file
timeless-mbp:q timeless$ hg cat -r 3 file >> file
Verify that it now has the content I want
timeless-mbp:q timeless$ cat file
a
b
Commit the "merged" file
timeless-mbp:q timeless$ hg commit -m merging
Review the repository history
timeless-mbp:q timeless$ hg log
changeset: 4:d9d3d23ec1cc
tag: tip
parent: 3:01c6a61cbe04
parent: 2:3de70df713a7
user: timeless
date: Wed Jun 02 16:10:08 2010 +0300
summary: merging
changeset: 3:01c6a61cbe04
parent: 1:e6b8058965b4
user: timeless
date: Wed Jun 02 16:09:43 2010 +0300
summary: rename b to file
changeset: 2:3de70df713a7
parent: 0:635f50240100
user: timeless
date: Wed Jun 02 16:09:30 2010 +0300
summary: rename a to file
changeset: 1:e6b8058965b4
parent: -1:000000000000
user: timeless
date: Wed Jun 02 16:09:17 2010 +0300
summary: b
changeset: 0:635f50240100
user: timeless
date: Wed Jun 02 16:09:01 2010 +0300
summary: a
Check annotate output
timeless-mbp:q timeless$ hg ann -f -c file
635f50240100 a: a
e6b8058965b4 b: b