I am getting the following error when trying to run hg update:
abort: Operation not permitted:
/var/www/simira/web/public/images/nominations/13/big/4f196667cf5a2.jpg
Here is some info:
$ cd /var/www/simira/web/public/images/nominations/13/big/
$ ll ./4f196667cf5a2.jpg
-rw-rw-r-- 1 martin portadesign 15356 Feb 2 22:10 4f196667cf5a2.jpg
$ ll -d ./
drwxrwxr-x 2 martin portadesign 4096 Feb 2 22:10 ./
$ id
uid=5004(clime) gid=5007(portadesign) groups=5007(portadesign),10(wheel),48(apache)
Tell me what is wrong, please...
The problem was caused by hg attempting to change the permissions of the file:
$ sudo hg update
$ ll ./4f196667cf5a2.jpg
./ -rwxrwxr-x 1 martin portadesign 15356 Feb 2 22:10 4f196667cf5a2.jpg
As can be seen, it added executable bit to the image. That is the only bit that hg acually tracks and there does not seem to be a "switch-off" option. The problem is that only an owner of the file can change its permissions.
Related
This question already has answers here:
Undo an accidental hg strip?
(3 answers)
Closed 3 years ago.
I have this Mercurial repository where I keep a counter:
$ echo 1 > count
$ hg add count
$ hg com -m 'incrementing to 1'
$ echo 2 > count
$ hg com -m 'incrementing to 2'
So far so good, but then I committed a mistake:
$ hg com -m 'incrementing to 3'
So I use hg strip to revert this last commit:
$ hg strip --keep -r -2
saved backup bundle to /home/adam/sandbox/count/.hg/strip-backup/bda856a578bf-ff2b025f-backup.hg
Unbeknownst to me, I have committed another, bigger mistake! I stripped the two topmost commits, and I just wanted to strip the topmost one:
$ hg log
changeset: 0:7b5533cf962a
tag: tip
user: Adam Victor Nazareth Brandizzi <brandizzi#gmail.com>
date: Wed May 15 08:00:27 2019 -0300
summary: incrementing to 1
How I get my commits back?
NOTE: this is a contrived example of a case were I needed to use hg strip. No need to wasting time pointing out there are alternatives etc.
As I've learned from this message in Mercurial's mailing list, the solution is quite straightforward. Note that when I ran hg strip --keep -r -2 I got this line in the output:
saved backup bundle to /home/adam/sandbox/count/.hg/strip-backup/bda856a578bf-ff2b025f-backup.hg
So, basically, Mercurial made a backup of the original history! Now I just need to pull from it:
$ hg pull /home/adam/sandbox/count/.hg/strip-backup/bda856a578bf-ff2b025f-backup.hg
pulling from /home/adam/sandbox/count/.hg/strip-backup/bda856a578bf-ff2b025f-backup.hg
searching for changes
adding changesets
adding manifests
adding file changes
added 2 changesets with 2 changes to 1 files
(run 'hg update' to get a working copy)
$ hg update
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
My file is back to the original state...
$ cat count
66
...as well as my history:
$ hg log
changeset: 2:fc4d1cc18a4b
tag: tip
user: Adam Victor Nazareth Brandizzi <brandizzi#gmail.com>
date: Wed May 15 08:00:51 2019 -0300
summary: incrementing to 3
changeset: 1:bda856a578bf
user: Adam Victor Nazareth Brandizzi <brandizzi#gmail.com>
date: Wed May 15 08:00:38 2019 -0300
summary: incrementing to 2
changeset: 0:7b5533cf962a
user: Adam Victor Nazareth Brandizzi <brandizzi#gmail.com>
date: Wed May 15 08:00:27 2019 -0300
summary: incrementing to 1
Now I can call the right strip command (hg strip --keep -r -1).
What if we do not have the backup file name anymore?
You may have lost the backup file name (it did happen to me!) but you can find it in $YOUR_REPO/.hg/strip-backup. If you have many backups, just list them sorted by time, descending:
$ ls -tl .hg/strip-backup/
total 4
-rw-rw-r-- 1 adam adam 754 May 15 08:10 bda856a578bf-ff2b025f-backup.hg
-rw-rw-r-- 1 adam adam 754 May 15 08:02 02ac79859dd0-0902f53b-backup.hg
The last one is probably the one you want.
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.
Folks, I need your help!
I tried to push my hg repository to bitbucket for the first time. It didn't work and I thought this was because the project is to huge. Therefore, I wanted to push only one single file.
Since I did "hg add *" before, I wanted to revoke this, and typed "hg remove *" and now it DELETED FILES ON MY COMPUTER. But not all of them, only some...
I need these files back, how do I do it? Please tell me they're not gone, please please please.
Thank you so much for your help!!
This is my command history:
518 hg commit commit_test.txt -m "first commit"
519 hg add commit_test.txt
520 hg commit -m "test"
521 ls -ll
522 ls -la
523 cd .hg/
524 ls
525 ls -la
526 pico hgrc
527 cd ..
528 hg status
529 hg add commit_test.txt~
530 hg add commit_test.txt
531 hg commit -m "blabla"
532 hg push
533 hg add commit_test.txt
534 hg commit -m "maaan"
535 hg status
536 hg remove *
537 hg status
538 hg commit -m "bla"
539 ls
540 hg add test.txt
541 hg commit -m "test"
542 hg push
543 hg revert
544 hg revert --all
545 history
546 hg add *
547 hg add -r *
548 hg help add
549 hg add -S *
550 cd gui_relabel/
551 hg add *
552 cd images/
553 hg add *
554 cd ..
555 hg revert all
556 hg revert *
557 history
Here is what hg log gives me:
$ hg log
changeset: 6:4726f671ae96
tag: tip
user: KG <...#gmail.com>
date: Wed Dec 04 12:21:30 2013 +0100
summary: test
changeset: 5:55b3158def38
user: KG <...#gmail.com>
date: Wed Dec 04 12:17:19 2013 +0100
summary: bla
changeset: 4:ae0dd836586d
user: KG <...#gmail.com>
date: Wed Dec 04 12:14:50 2013 +0100
summary: blabla
changeset: 3:0249fdc26fa7
user: KG <...#gmail.com>
date: Wed Dec 04 12:13:59 2013 +0100
summary: test
changeset: 2:40bdcf4d2104
user: KG <...#gmail.com>
date: Wed Dec 04 12:12:37 2013 +0100
summary: first commit test
changeset: 1:f9e20020ca1d
user: KG <...#gmail.com>
date: Sun Nov 10 14:54:46 2013 +0100
summary: first commit
changeset: 0:7a8edcee06ff
user: KG <...#gmail.com>
date: Mon Nov 04 20:36:41 2013 +0100
summary: blabla
Your files are not gone. Mercurial does not throw away data, that is one of the first rules of the system.
To explain what hg remove did to your files, let us look at the cases one by one. A file in your working copy can be in one out of a handful different states: it can be modified, added, removed, missing, unknown, ignored, or clean.
I've prepared a working copy that looks like this:
$ hg status --all
M a
A b
R c
! d
? e
I f
C g
The files a to g are in the seven states I mentioned above. We can now talk about what happens when you try to remove these files:
A modified file (a) is not removed:
$ hg remove a
not removing a: file is modified (use -f to force removal)
An added file (b) is also not removed:
$ hg remove b
not removing b: file has been marked for add (use forget to undo)
A removed file (c) is no longer present in the working copy, so nothing more happens.
A missing file (d) is no longer present in the working copy, so nothing more happens.
An untracked file (e) is not removed:
$ hg remove e
not removing e: file is untracked
An ignored file (f) is not removed (since it is not tracked):
$ hg remove f
not removing f: file is untracked
A clean file (g) is removed.
The only type of file that hg remove will actually remove from your working copy is a clean file. A clean file is already committed, so the content is safely stored in the repository. You can get it back with hg revert:
$ hg revert g
$ hg status --all
M a
A b
R c
! d
? e
I f
C g
The file g is back with the same content as it had before you removed it.
It looks like you could run
hg backout 5
You can read more about backout if you like
Is there some equivalent in Mercurial to NIX soft- or hard- links to directories or files.
Basically that a file (or directory) is linked to a file "somewhere else" and follows the version of that location (Unlike a regular branch I think, where one would have to merge)
Mercurial versions soft links that are internal to the repository just great. It'll detect them, record them, and create them for you. Is there a specific use case you're looking for? The closest thing to an link that reaches outside the repository is a subrepo, which is a pointer to a specific version of another repo.
Symlinks work
(df)Ry4ans-MacBook-Air:~ ry4an$ hg init olav
(df)Ry4ans-MacBook-Air:~ ry4an$ cd olav/
(df)Ry4ans-MacBook-Air:olav ry4an$ echo this > target
(df)Ry4ans-MacBook-Air:olav ry4an$ ln -s target link
(df)Ry4ans-MacBook-Air:olav ry4an$ ls -l
total 16
lrwxr-xr-x 1 ry4an staff 6B Feb 16 19:25 link# -> target
-rw-r--r-- 1 ry4an staff 5B Feb 16 19:25 target
(df)Ry4ans-MacBook-Air:olav ry4an$ hg commit -A -m "link and its target"
adding link
adding target
(df)Ry4ans-MacBook-Air:olav ry4an$ hg log -p
changeset: 0:42a41a431661
tag: tip
user: Ry4an Brase <ry4an-hg#ry4an.org>
date: Sat Feb 16 19:26:17 2013 -0500
summary: link and its target
diff -r 000000000000 -r 42a41a431661 link
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/link Sat Feb 16 19:26:17 2013 -0500
## -0,0 +1,1 ##
+target
\ No newline at end of file
diff -r 000000000000 -r 42a41a431661 target
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/target Sat Feb 16 19:26:17 2013 -0500
## -0,0 +1,1 ##
+this
(df)Ry4ans-MacBook-Air:olav ry4an$ hg update null
0 files updated, 0 files merged, 2 files removed, 0 files unresolved
(df)Ry4ans-MacBook-Air:olav ry4an$ ls -l
(df)Ry4ans-MacBook-Air:olav ry4an$ hg update tip
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
(df)Ry4ans-MacBook-Air:olav ry4an$ ls -l
total 16
lrwxr-xr-x 1 ry4an staff 6B Feb 16 19:26 link# -> target
-rw-r--r-- 1 ry4an staff 5B Feb 16 19:26 target
But hardlinks don't
$hg commit -Am "hardlinks target"
adding link
adding target
$hg log -p
changeset: 0:ec9407634133
tag: tip
user: Chris Wesseling <chris.wesseling#cwi.nl>
date: Wed Mar 13 23:14:44 2013 +0100
summary: hardlinks target
diff -r 000000000000 -r ec9407634133 link
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/link Wed Mar 13 23:14:44 2013 +0100
## -0,0 +1,1 ##
+foo
diff -r 000000000000 -r ec9407634133 target
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/target Wed Mar 13 23:14:44 2013 +0100
## -0,0 +1,1 ##
+foo
$ls -lin
total 8
276702 -rw-r--r-- 2 1204653 5900 4 13 mrt 23:14 link
276702 -rw-r--r-- 2 1204653 5900 4 13 mrt 23:14 target
$hg update null
0 files updated, 0 files merged, 2 files removed, 0 files unresolved
$hg update tip
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ls -lin
total 8
276719 -rw-r--r-- 1 1204653 5900 4 13 mrt 23:15 link
276721 -rw-r--r-- 1 1204653 5900 4 13 mrt 23:15 target
Path auditing on *nix
On *nix systems, hg Mercurial audits symbolic links ("symlinks") for referred path security.
For example, absolute and empty paths are considered unsafe and will therefore not be added to the repository.
Mercurial developers have not documented this feature. However, the source code contains a comment with a somewhat vague explanation:
class pathauditor(object):
'''ensure that a filesystem path contains no banned components.
the following properties of a path are checked:
- ends with a directory separator
- under top-level .hg
- starts at the root of a windows drive
- contains ".."
- traverses a symlink (e.g. a/symlink_here/b)
- inside a nested repository (a callback can be used to approve
some nested repositories, e.g., subrepositories)
'''
On Windows, symbolic links are not supported for various reasons, see:
https://www.mercurial-scm.org/bts/issue1825
https://www.mercurial-scm.org/bts/issue2579
I keep getting this error with HG (Mercurial), it seems like it's having a problem with the file, but i have permissions on the file, so i'm not sure why it's returning an error:
me#server:/repo$ hg up -v
resolving manifests
getting __init__.py
abort: Operation not permitted: /repo/__init__.py.orig
me#server:/repo$ ls -l /repo/__init__.py
-rw-rw-r-- 1 www-data www-data 3022 2012-03-22 14:13 /repo/__init__.py
me#server:/repo$ ls -ld /repo/
-rwxrwxr-x 3 www-data www-data 4096 2012-03-22 13:23 /repo/
here is another sample:
me#server:/repo$ ls -l /repo/modular.py.orig
-rw-rw-r-- 1 www-data www-data 34188 2012-03-29 12:50 /repo/modular.py.orig
me#server:/repo$ ls -l /repo/ -d
drwxrwxr-x 2 www-data www-data 4096 2012-03-29 12:50 /repo/
Any ideas how i can prevent this in the future?
I think it's saying it's unable to create the file /repo/__init__.py.orig. Check these permissions:
ls -l /repo/__init__.py.orig
and
ls -l /repo/
You need write access for both of those for user 'me'