Re: [lmi] Symlink .git/hooks [Was: git: committing content and mode changes together]

[Greg Chicares]

On 2016-11-04 21:47, Greg Chicares wrote:
> On 2016-11-04 20:00, Greg Chicares wrote:
> [...]
>> (2) Symlink a hooks directory:
>> 
>>   cd $(git rev-parse --show-toplevel)
>>   mkdir hooks
>>   ln --symbolic $(git rev-parse --show-toplevel)/hooks $(git rev-parse 
>> --show-toplevel)/.git/hooks
> 
> No, that would make hooks/pre-commit available as .git/hooks/hooks/pre-commit 
> .
>                                           two "hooks": ^^^^^ ^^^^^
> 
> And this:
> 
>   ln --symbolic $(git rev-parse --show-toplevel)/hooks $(git rev-parse 
> --show-toplevel)/.git
> 
> fails because .git/hooks already exists by default, so we want:
> 
>   mv .git/hooks .git/hooks-orig
>   ln --symbolic $(git rev-parse --show-toplevel)/hooks $(git rev-parse 
> --show-toplevel)/.git

Vadim--'nautilus' says that symlink is broken; does that seem to be a
'nautilus' defect, or is something really wrong? Here are the exact
steps I took. I started with a virgin default .git/hooks:

/opt/lmi/src/lmi[0]$ls .git/hooks                
applypatch-msg.sample  pre-commit         prepare-commit-msg.sample
commit-msg.sample      pre-commit.sample  update.sample
post-update.sample     pre-push.sample
pre-applypatch.sample  pre-rebase.sample

Then (as suggested above) I renamed that directory and created a
symlink:

/opt/lmi/src/lmi[0]$mv .git/hooks .git/hooks-orig
/opt/lmi/src/lmi[0]$ln --symbolic $(git rev-parse --show-toplevel)/hooks $(git 
rev-parse --show-toplevel)/.git

Just to be sure, I recall that 'ln' command in history and press Tab
to expand the $() parts (and then delete the expanded line instead
of re-executing it):

  ln --symbolic /opt/lmi/src/lmi/hooks /opt/lmi/src/lmi/.git

That's all right, AFAICT: I want a new directory lmi/hooks to be
treated by git as though it were lmi/.git/hooks . There's nothing
in it yet:

/opt/lmi/src/lmi[0]$ls .git/hooks
.git/hooks

I had created a 'pre-commit' script in my usual source directory
(i.e., the present working directory displayed in the zsh PROMPT),
and I want to copy it to the /hooks directory:

/opt/lmi/src/lmi[0]$cp -a pre-commit .git/hooks
cp: not writing through dangling symlink '.git/hooks'

...but this error message reminds me that the symlink's target
doesn't yet exist, so I create it:

/opt/lmi/src/lmi[1]$ls -l .git/hooks
lrwxrwxrwx 1 greg greg 22 Nov  5 12:09 .git/hooks -> /opt/lmi/src/lmi/hooks
/opt/lmi/src/lmi[0]$mkdir hooks

...and now 'cp' seems to work:

/opt/lmi/src/lmi[0]$cp -a pre-commit .git/hooks
/opt/lmi/src/lmi[0]$ls -l .git/hooks           
lrwxrwxrwx 1 greg greg 22 Nov  5 12:09 .git/hooks -> /opt/lmi/src/lmi/hooks
/opt/lmi/src/lmi[0]$ls .git/hooks 
pre-commit
/opt/lmi/src/lmi[0]$file .git/hooks 
.git/hooks: symbolic link to /opt/lmi/src/lmi/hooks
/opt/lmi/src/lmi[0]$file .git/hooks/pre-commit 
.git/hooks/pre-commit: POSIX shell script, ASCII text executable

Everything seems to be in order, and git definitely uses the hook,
because I've deliberately introduced errors that cause 'git commit'
to print "COMMIT ABORTED" and fail, and then 'git log' shows that
nothing was committed.

Searching for broken symlinks this way finds nothing:

/opt/lmi/src/lmi[0]$find -L . -type l -ls

and the ownership and permissions look okay to me:

/opt/lmi/src/lmi[0]$ls -l |grep hooks
drwxr-xr-x 2 greg greg   4096 Nov  5 12:54 hooks
/opt/lmi/src/lmi[0]$ls -l .git |grep hooks
lrwxrwxrwx  1 greg greg    22 Nov  5 12:09 hooks -> /opt/lmi/src/lmi/hooks
drwxr-xr-x  2 greg greg  4096 Nov  4 17:06 hooks-orig

Still, even if I restart 'nautilus':
  $nautilus --version
  GNOME nautilus 3.4.2
  $nautilus /srv/chroot/cross-lmi/opt/lmi/src/lmi/.git
'hooks' is displayed as a file rather than a directory, and its
type shows as "link (broken)". If I double-click it, I see:

  The Link "hooks" is Broken.
  Move it to Trash?
  This link cannot be used, because its
  target "/opt/lmi/src/lmi/hooks" doesn't
  exist.

This is a "wheezy" nautilus, and the symlink is in a "jessie"
chroot, but I don't see how that could make a difference.

'thunar' also sees the link as broken:
  $thunar /srv/chroot/cross-lmi/opt/lmi/src/lmi/.git
It displays a red 'X' icon, and its "Properties" dialog says
"Kind: broken link". That seems to rule out 'nautilus', and
also caching (I have other instances of 'nautilus' running, but
not of 'thunar').

Wait...I have a new hypothesis: the symlink target is an absolute
path, in a chroot, so it's actually relative to the chroot's root:

/opt/lmi/src/lmi[0]$ls -di /
21495811 /
/opt/lmi/src/lmi[0]$echo $SCHROOT_ALIAS_NAME 
cross-lmi
/opt/lmi/src/lmi[0]$readlink -f .git/hooks
/opt/lmi/src/lmi/hooks

...but on the host system (where 'nautilus' and 'thunar' run)
that absolute path doesn't exist:

/srv/chroot/cross-lmi/opt/lmi/src/lmi[0]$ls -di /
2 /
/srv/chroot/cross-lmi/opt/lmi/src/lmi[0]$readlink -f .git/hooks
/srv/chroot/cross-lmi/opt/lmi/src/lmi[1]$find -L . -type l -ls    
22806870    0 lrwxrwxrwx   1 greg     greg           22 Nov  5 12:09 
./.git/hooks -> /opt/lmi/src/lmi/hooks
/srv/chroot/cross-lmi/opt/lmi/src/lmi[0]$ls /opt/lmi/src/lmi/hooks
ls: cannot access /opt/lmi/src/lmi/hooks: No such file or directory

Is that the explanation?

What is the best general practice--to create symlinks with
absolute targets, or relative ones? I find conflicting advice:

http://unix.stackexchange.com/questions/105637/is-symlinks-target-relative-to-the-destinations-parent-directory-and-if-so-wh
| a good pratice is to always use absolute path
...
| I agree with the best practice as I've always used absolute paths
| for both the target and the destination. 

http://unix.stackexchange.com/questions/10370/make-a-symbolic-link-to-a-relative-pathname/10371#10371
   
| If you create a symbolic link to a relative path, it will store it
| as a relative symbolic link, not absolute like your example shows.
| This is generally a good thing. Absolute symbolic links don't work
| when the filesystem is mounted elsewhere.

I don't find these GNU/Linux file managers all that useful, so I
don't really much care whether 'nautilus' interprets this symlink
correctly. If I did, then I guess it would have to be relative. But
my only concern is whether the file managers' error messages were
pointing out a genuine latent problem.