simon-git: putty (main): Simon Tatham

[Commits to Tartarus hosted VCS]

TL;DR:
  d96a4983 gitcommit.cmake: work around Windows pathname aliasing.

Repository:     https://git.tartarus.org/simon/putty.git
On the web:     https://git.tartarus.org/?p=simon/putty.git
Branch updated: main
Committer:      Simon Tatham <anakin at pobox.com>
Date:           2024-12-27 10:15:35

commit d96a4983be74f6450c7da3c856bc20eb8e7818ef
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=d96a4983be74f6450c7da3c856bc20eb8e7818ef;hp=193e2ec06375dad38cdba4815cb32cf24f3e39d4
Author: Simon Tatham <anakin at pobox.com>
Date:   Fri Dec 27 10:07:32 2024 +0000

    gitcommit.cmake: work around Windows pathname aliasing.
    
    The cmake script that determines the current git head commit, in order
    to bake it into the binaries for development builds from a git
    checkout, wasn't working reliably on Windows: sometimes it reported
    that the source directory didn't seem to be a git repository, when in
    fact it was.
    
    This occurred because gitcommit.cmake starts by trying to work out
    _whether_ the source directory is the top level of a git worktree at
    all, by the technique of running `git rev-parse --show-toplevel` (to
    print the top-level path of the git worktree _containing_ $PWD, if
    any) and comparing it with ${CMAKE_SOURCE_DIR}. But the comparison was
    done as a plain string, which leads to problems if more than one
    string can represent the same actual directory.
    
    On Windows, this can occur for two reasons that I know of. One reason
    is related to Windows itself: if you map a network file server path to
    a local drive letter, then the same directory is accessible as a UNC
    path (e.g. \\hostname\share\subdir) and via the drive letter (e.g.
    N:\subdir). And it can happen that CMAKE_SOURCE_DIR and git's output
    disagree on which representation to use, causing the string comparison
    to return a false negative.
    
    (This can also affect filesystems in a WSL instance, accessed from
    native Windows via \\wsl$\instance\path, because Windows implements
    that as a network file share even though the network in question is
    purely in the imagination of that one machine.)
    
    The other reason is related more specifically to git, because some
    versions of Windows git are built on top of MSYS or MINGW or that kind
    of shim layer, and model Windows drive letters as subdirectories of a
    Unixlike VFS root. So you might also find that the two strings
    disagree on whether you're in C:\Users\alice\src\putty or
    /c/Users/alice/src/putty.
    
    I think this commit should work around both of these problems. Reading
    the man page for `git rev-parse` more carefully, it has an option
    `--show-cdup`, which returns a _relative_ path from $PWD to the
    top-level directory of the worktree: that is, it will be a sequence of
    `../../..` as long as necessary, including length zero. So you can use
    that to directly query whether you're at the top of a git worktree: if
    `git rev-parse --show-cdup` returns the empty string and a success
    status, then you are. (If you're deeper in a worktree it will return a
    non-empty string, and if you're not in a worktree at all it will
    return a failure status and print an error message to stderr.)

 cmake/gitcommit.cmake | 36 +++++++++++++++++-------------------
 1 file changed, 17 insertions(+), 19 deletions(-)