Update instructions and test helpers for git-daemon #1684

EliahKagan · 2023-10-01T21:54:50Z

On a current Cygwin system with git 2.39.0 (the latest version offered by the Cygwin package manager), git-daemon is present, with the Cygwin path /usr/libexec/git-core/git-daemon.exe. I believe this has been the case for a long time; as detailed below, Cygwin was not ever treated specially in the way that was assumed, yet no breakage resulted.

The cygwin-test.yml workflow does not take any special steps to allow git-daemon to work, but all tests have been passing in it even without skipping or xfailing tests that seem related to git-daemon.

The git_daemon_launched function in test/lib/helper.py invokes git-daemon directly (rather than through git daemon) only when is_win evaluates true. This only happens on native Windows systems, while Cygwin is treated the same as (other) Unix-like systems yet still works. So maybe Cygwin git-daemon was never a special case.

Whether or not it was, the message about git-daemon needing to be findable in a PATH search is also under an is_win check, and thus is never shown on Cygwin. So I've removed the Cygwin part of that message. (Because the path shown is a MinGW-style path, I have kept the wording about that being for MinGW-git, even though it is no longer needed to disambiguate the Cygwin case.)

The greatest value here is the simplification of the documentation and comments. But for consistency, and to make sure the code and comments don't disagree, I've removed the previous suppression of Cygwin special casing: now, Cygwin paths are allowed to be normalized using Cygwin path logic even when passed to git daemon as part of the tests. Both ways work on Cygwin in the tests actually being done.

The code change part of this PR only affects test code. Nothing in this pull request modifies anything in the git module.

On a current Cygwin system with git 2.39.0 (the latest version offered by the Cygwin package manager), git-daemon is present, with the Cygwin path /usr/libexec/git-core/git-daemon.exe. In addition, the cygwin-test.yml workflow does not take any special steps to allow git-daemon to work, but all tests pass in it even without skipping or xfailing tests that seem related to git-daemon. The git_daemon_launched function in test/lib/helper.py only invokes git-daemon directly (rather than through "git daemon") when is_win evaluates true, which only happens on native Windows systems, not Cygwin, which is treated the same as (other) Unix-like systems and still works. So maybe Cygwin git-daemon was never a special case. Whether or not it was, the message about git-daemon needing to be findable in a PATH search is also under an is_win check, and thus is never shown on Cygwin. So I've removed the Cygwin part of that message. (Because the path shown is a MinGW-style path, I have kept the wording about that being for MinGW-git, even though it is no longer needed to disambiguate the Cygwin case.)

Since the Cygwin git-daemon can be used.

EliahKagan · 2023-10-01T21:57:58Z

test/lib/helper.py

@@ -217,12 +215,11 @@ def git_daemon_launched(base_path, ip, port):
        )
        if is_win:
            msg += textwrap.dedent(
-                r"""
+                R"""


Using a capital R here instead of r causes some editors to display the string as truly raw, rather than as a regular expression. black permits both case variants, even though they mean the same thing to all Python implementations, to allow for this expressiveness. I found this made the string much easier to read in VS Code. However, you may nonetheless prefer this not be done, or that it be deferred until it can be more consistently applied across the codebase. I certainly have no objection to putting this back to r.

That's a super-interesting feature and I wasn't aware! I think there is great value in having (at least some) editors display the string in a more readable fashion, so yes, please keep making these improvements.

Byron

That's a great catch, thanks so much!

I see how running on Windows natively gets closer with every PR ❤️.

Byron · 2023-10-02T08:12:59Z

test/lib/helper.py

@@ -217,12 +215,11 @@ def git_daemon_launched(base_path, ip, port):
        )
        if is_win:
            msg += textwrap.dedent(
-                r"""
+                R"""


That's a super-interesting feature and I wasn't aware! I think there is great value in having (at least some) editors display the string in a more readable fashion, so yes, please keep making these improvements.

This removes the Windows-specific information in the warning message in git_daemon_launched. After the associated functionality was updated in gitpython-developers#1684 and the warning message was abridged accordingly, the functionality was updated again in gitpython-developers#1697, causing the message to be outdated and no longer helpeful (since having git-daemon.exe in a PATH directory is no longer necessary or useful), without any corresponding change to the message.

EliahKagan added 2 commits October 1, 2023 16:55

Allow base_daemon_path to be normalized for Cygwin

35e3875

Since the Cygwin git-daemon can be used.

EliahKagan marked this pull request as ready for review October 1, 2023 21:55

EliahKagan commented Oct 1, 2023

View reviewed changes

Byron approved these changes Oct 2, 2023

View reviewed changes

Byron merged commit f9a3b83 into gitpython-developers:main Oct 2, 2023
8 checks passed

EliahKagan deleted the daemon branch October 2, 2023 08:21

EliahKagan mentioned this pull request Oct 4, 2023

Improve scripts and tool configurations #1693

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Update instructions and test helpers for git-daemon #1684

Update instructions and test helpers for git-daemon #1684

EliahKagan commented Oct 1, 2023 •

edited

Loading

EliahKagan Oct 1, 2023

Byron Oct 2, 2023

Byron left a comment

Byron Oct 2, 2023

Update instructions and test helpers for git-daemon #1684

Update instructions and test helpers for git-daemon #1684

Conversation

EliahKagan commented Oct 1, 2023 • edited Loading

EliahKagan Oct 1, 2023

Choose a reason for hiding this comment

Byron Oct 2, 2023

Choose a reason for hiding this comment

Byron left a comment

Choose a reason for hiding this comment

Byron Oct 2, 2023

Choose a reason for hiding this comment

EliahKagan commented Oct 1, 2023 •

edited

Loading