How to make Mercurial detect changes made to the target of a symlink - version-control

I have a project version-controlled by the Mercurial (project main). The project references (uses) some files from another project (sub) by a symbolic link in the main pointing to a file in sub. The symbolic link is added to the main's repository.
The problem is that Mercurial doesn't detect changes made to the target file at sub, not marking the symlink as 'M' (modified).
The situation is shown in the following example:
Create, init and commit initial repos:
$ mkdir crap
$ cd crap
$ mkdir main sub
$ cd sub
$ nano sub.txt
$ hg init
$ hg add sub.txt
$ cd ../main/
$ nano main.txt
$ ln -s ../sub/sub.txt ./sub.txt
$ ls -la
total 24
drwxrwxr-x 2 ruslan ruslan 4096 Jan 15 12:51 .
drwxrwxr-x 4 ruslan ruslan 4096 Jan 15 12:48 ..
-rw-rw-r-- 1 ruslan ruslan 20 Jan 15 12:51 main.txt
lrwxrwxrwx 1 ruslan ruslan 14 Jan 15 12:51 sub.txt -> ../sub/sub.txt
$ hg init
$ hg add main.txt sub.txt
$ hg commit -m "First"
$ cd ../sub
$ hg commit -m "Sub First"
$ hg status ./sub -A
C sub/sub.txt
$ hg status ./main -A
C main/main.txt
C main/sub.txt
now modify and commit the target in sub:
$ nano ./sub/sub.txt
$ hg status ./sub -A
M sub/sub.txt
$ hg commit ./sub -m "Modified"
$ hg status ./sub -A
C sub/sub.txt
now status of the main shows that the symlink that references the target is not marked as 'M':
$ hg status ./main -A
C main/main.txt
C main/sub.txt
modifying the sub again without the commit shows 'M' in sub but not in main:
$ nano ./sub/sub.txt
$ hg status ./sub
M sub/sub.txt
$ hg status ./main -A
C main/main.txt
C main/sub.txt
How can I properly make Mercurial detect changes in symlinks' targets?

You can't. For security reasons, Mercurial never traverses symbolic links.

You can use a hard link instead by omitting -s parameter when creating with ln.
I recommend appending .hardlink to be explicit and modifying your ls to highlight hardlinks.
On a windows machine I have used same approach using
Link Shell Extension utility; I donated to the author and you should do the same :).

Related

Prevent VSCode opening as root from WSL

When opening VSCode in a folder using code . using my current user, I notice that then it was started as root. The steps that I'm making are to validate this behaviour are:
$ whoami
>> franciscoserrano
$ mkdir test-dir && ll
>> drwxr-xr-x 2 franciscoserrano franciscoserrano 4.0K Jan 18 19:04 test-dir
$ cd test-dir
$ code .
(right after this, inside VSCode's terminal) $ pwd && whoami
/home/franciscoserrano/projects/test-dir
root
Another weird thing is that the VSCode terminal seems to load the .zshrc of my user, this is still inside VSCode terminal:
$ pwd
>> /home/franciscoserrano/projects/test-dir
$ whoami && cd
>> root
$ pwd
>> /home/franciscoserrano
Is this intended? Why making $ cd changes to a directory that is not from the user that outputs $ whoami? How do I force VSCode to open as the same user as in WSL?
Another detail: when creating files inside the same folder, using the VSCode GUI, those are also created as root:
-rw-r--r-- 1 root root 0 Jan 18 19:18 hello.c
Running the following command on the windows side fixes this issue for me:
ubuntu2204.exe config --default-user <wsl-user>

Get branch name from nodeid in mercurial

How can I source the branch name from node ID in Mercurial?
I have tried hg id nodeid but that doesn't work
But hd id nodeid does work, provided you spell the node identifier with the -r or --rev option:
$ hg id -r 2
db6f6e1d8715 (sidebr) tip
Note that if the branch name is default it is suppressed, as usual.
To get just the branch name, and avoid suppressing the name default, add the -b option:
$ hg id -b -r 1
default
Note that you can get more than one piece of information:
$ hg id -i -b -n -r 1
d05b1df8b8f6 1 default
(The order is always hash, rev, branch when using these options, regardless of the order of the -i / --id, -n / --num, and -b / --branch options. Adding -t / --tags and/or -B / --bookmarks adds the tags and the bookmarks in that order, again regardless of option order.)

How to make RPM not to overwrite files when installing new packages?

Engineer Engelbert, a fierce OpenSuSE 11-sp4 user, is in possession of two RPM packages with the same contents:
rpm -qlp ~/onemy_ls_0.0.1_x86_64.rpm | tee a
/.osc/_apiurl
/.osc/_files
/.osc/_meta
/.osc/_osclib_version
/.osc/_package
/.osc/_project
/my_ls/my_ls.sh
rpm -qlp ~/my_ls_0.0.1_x86_64.rpm | tee b
/.osc/_apiurl
/.osc/_files
/.osc/_meta
/.osc/_osclib_version
/.osc/_package
/.osc/_project
/my_ls/my_ls.sh
diff a b | wc
0 0 0
Engineer Engelbert has realized that he can install both packages with no warning from RPM:
rpm -e my_ls-0.0.1-1 ; rpm -i ~/my_ls_0.0.1_x86_64.rpm
rpm -e onemy_ls-0.0.1-1 ; rpm -i ~/onemy_ls_0.0.1_x86_64.rpm
Engineer Engelbert is self-assured about his choices. He knows that's probably a good design choice from rpm developers. So, he checked the man page, certain that there would be an option for not allowing rpm packages to overwrite files in the system. But all the install options he found were:
install-options
[--aid] [--allfiles] [--badreloc] [--excludepath OLDPATH]
[--excludedocs] [--force] [-h,--hash]
[--ignoresize] [--ignorearch] [--ignoreos]
[--includedocs] [--justdb] [--nodeps]
[--nodigest] [--nosignature] [--nosuggest]
[--noorder] [--noscripts] [--notriggers]
[--oldpackage] [--percent] [--prefix NEWPATH]
[--relocate OLDPATH=NEWPATH]
[--repackage] [--replacefiles] [--replacepkgs]
[--test]
He hesitated and found strange that there is --replacefiles, but not --keepfiles. That suggested him that keep would be the default behavior. So, he created an script:
rpm -e onemy_ls-0.0.1-1
rpm -e my_ls-0.0.1-1
rm -rf /my_ls/
rpm -i ~/my_ls_0.0.1_x86_64.rpm
ls -lh /my_ls -d
sleep 120
rpm -i ~/onemy_ls_0.0.1_x86_64.rpm
ls -lh /my_ls -d
That showed that the files were actually overwritten:
drwxr-xr-x 2 root root 4.0K Aug 16 17:07 /my_ls
drwxr-xr-x 2 root root 4.0K Aug 16 17:09 /my_ls
After a research, Engineer Engelbert couldn't still find the answer.Now he is in the middle of a flamewar about packaging systems, and, as asked by somebody, he needs your help:
How to make rpm not to overwrite files when installing new packages?
Note - Engineer Engelbert knows that he should create better rpm packages with conflicts management, you don't need to explain him that. He is mostly worried about being sure that his packages won't conflict with other proprietary unpublished packages racing for the same paths in the system.
Note - using fpm, you can regenerate Engineer Engelbert's RPMs:
mkdir -p first_pkg/my_ls/
echo ls > first_pkg/my_ls/my_ls.sh
fpm -s dir -t rpm -n onemy_ls -v 0.0.1 -C first_pkg/ -p onemy_ls_VERSION_ARCH.rpm
fpm -s dir -t rpm -n my_ls -v 0.0.1 -C first_pkg/ -p my_ls_VERSION_ARCH.rpm
Yes: rpm will overwrite all files contained in a *.rpm that are not marked with %config and there is no option to disable that behavior.

How to do 'fossil' commands on relative directory?

I want to keep my linux config in fossil scm system.
Here is what I did at initial stage.
$ cd /
$ fossil new b.fsl
$ fossil open b.fsl
$ fossil add etc/group
$ fossil add boot/grub/menu.lst
$ fossil ci -m 'init commit'
I want do do things like (operate like hg/git).
$ cd etc
$ fossil status group
$ fossil add motd
It will show error message:
fossil: current directory is not within an open checkout
So, my temp dirty solution is
$ cd /
$ fossil status etc/group
$ fossil add etc/motd
$ fossil add /etc/motd # this line will cause problem
For my git/hg experiences, it should work.
$ cd /
$ hg init
$ hg add etc/group boot/grub/menu.lst
$ hg ci -m 'init commit'
$ cd etc
$ hg status group # it works
$ hg add motd # it works too
Before the command
$ fossil new b.fsl
Type the command
$ cd etc
If you want the fossil repo stored in another folder, change the commands
$ fossil new b.fsl
$ fossil open b.fsl
to
$ fossil new path_to_repo/b.fsl
$ fossil open path_to_repo/b.fsl
All mentioned commands "add" and "status" and all fossil commands related to the checkout must be executed when the current directory is set somewhere inside the directory tree of the checkout.
You can't specify the checkout directory yourself as a command line option.
It seems there is a bug (or intentionally introduced feature) in fossil that prevents it searching for the open checkout file (".fslchkout" or "FOSSIL") up to the root directory. That is why in this case you must be in the root directory when you execute commands on this checkout.
Of course all executions of fossil in this case must be with root privileges. Otherwise, even in the root directory you will get "not within checkout" error.
This situation is covered in great detail in the User Guide, which I recommend wholeheartedly.
http://www.fossil-scm.org/schimpf-book/home
In particular, see version 2.0 of the fossilbook.pdf, in section 2, entitled "Single Users", the section starting with:
I have a directory called FOSSIL in which I keep all my repositories, Fossil doesn’t care but it helps me to keep them all in one place so I can back them up.
The first command there shows how to call relative directories:
$ fossil new ../FOSSIL/FossilBook.fossil

gitweb not seeing repository because it can't see the HEAD file?

I'm trying to get gitweb setup on a CentOS 6.2 server with git/gitweb 1.7.1 and httpd 2.2.15 installed.
gitweb's default project root (verified in the CGI script) is /var/lib/git, so I've created that and a bare git repository in there:
$ ls -laF /var/lib/git
total 12
drwxrwxr-x. 3 git git 4096 Feb 8 16:37 ./
drwxr-xr-x. 15 root root 4096 Feb 8 14:20 ../
drwxrwxr-x. 7 git git 4096 Feb 8 15:37 foo/
$ git init --bare --shared foo
Initialized empty shared Git repository in /var/lib/git/foo/
$ ls -lF foo
total 32
drwxrwsr-x. 2 git git 4096 Feb 8 17:16 branches/
-rw-rw-r--. 1 git git 126 Feb 8 17:16 config
-rw-rw-r--. 1 git git 73 Feb 8 17:16 description
-rw-rw-r--. 1 git git 23 Feb 8 17:16 HEAD
drwxrwsr-x. 2 git git 4096 Feb 8 17:16 hooks/
drwxrwsr-x. 2 git git 4096 Feb 8 17:16 info/
drwxrwsr-x. 4 git git 4096 Feb 8 17:16 objects/
drwxrwsr-x. 4 git git 4096 Feb 8 17:16 refs/
$ cat foo/HEAD
ref: refs/heads/master
However on viewing http://localhost/git/, I see "404 No projects found".
I've debugged through the script and can see that it's finding /var/lib/git/foo, but Perl's -e operator fails on /var/lib/git/foo/HEAD. At the same place in the file, a backticked call to ls shows that the file is visible there, but I cannot make Perl -e see the file.
Any idea what might be making this fail? This makes no sense to me.
EDIT: note that SELinux extensions on this CentOS box appear to be disabled:
$ sudo sestatus
SELinux status: disabled
EDIT: moving everything from /var/lib/git to /git hasn't helped. I've changed the apache user to have a real shell, logged in as that user, and verified that it has access to all the directories and files in question.
It was in fact SELinux. Even though SELinux reported it was disabled, it was somehow preventing access to some files for CGI scripts running under httpd. Enabling SELinux and setting it to permissive mode, it started working.
This seems highly non-intuitive and frustrates me, but at least it's working.
I'm still thinking it's an issue with permissions... but I could be wrong. Have you ensured that all of the parent directories leading up to your /var/lib/git directory are permission-accessible?
Someone else had a similar problem here and it might be worth trying a completely different directory... maybe even /opt.