by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    David Macek
    @elieux
    This is actually beyond my current knowledge, @suntong. I don't use LFS and I don't even remember seeing a password GUI from Git, but I could be mistaken.
    suntong
    @suntong
    That's OK @elieux, thanks again for all your helps.
    antonylineesh
    @antonylineesh1
    Hi
    Nate Hansen
    @nwhansen
    Hello and Welcome
    awmorgan
    @awmorgan
    why is the git 2x slower when running it from within an sdk shell?
    David Macek
    @elieux
    How do you measure?
    Johannes Schindelin
    @dscho
    With that little information to go on I can only wager a really wild guess: git config --global core.fscache true might "fix" this.
    awmorgan
    @awmorgan
    I have a large repository with multiple remotes and the .git directory is about 7G. My windows for git version is: git version 2.14.1.windows.1, and when I run time git status it was real: 4.778s the first time, then 2.887s the second time. In the git sdk shell has this version of git: git version 2.27.0.windows.1. When I run git status in the same repo the time is:
    real 0m5.218s, real 0m4.968s. real 0m4.904s. Both sdk and non-sdk shells have core.fscache=true. So it is ~5s for git status in sdk and ~2.9 for git status in non-sdk git bash. It was odd that the first time in the non-sdk it was 4.778s then reduced quite significantly to 2.887s the 2nd and subsequent times. Maybe that is the cache. If so it seems like the maybe the fscache is not working in the sdk shell. Just guessing.
    David Macek
    @elieux
    Having different versions of Git doesn't sound right.
    awmorgan
    @awmorgan
    git for windows and git sdk are installed in separate locations. Which means they can have different versions I think. I had an existing git for windows install with 2.14.1.windows.1 and yesterday installed the sdk so there are now 2 versions depending on which shell you open. Did I do something wrong?
    David Macek
    @elieux
    Just that it's not completely fair to say the difference is SDK to non-SDK when there's also a version difference.
    I didn't realize that one could install the SDK separately, so I take that original back somewhat.
    awmorgan
    @awmorgan
    gotcha. I was not expecting a more recent version to be slower though.
    David Macek
    @elieux
    It'd be nice to upgrade your non-SDK version to reduce the number of variables.
    Yeah, that's the less probable scenario, but still possible.
    awmorgan
    @awmorgan
    how do you have your system setup? I'm just trying to get a windows bash shell with the git for windows version of git because it's faster than the version in msys2 but also with pacman which the git for windows install doesn't have.
    David Macek
    @elieux
    awmorgan
    @awmorgan
    I will have a look at that. Thank you. Do you know why the msys2 project and git for windows projects don't get along? Wondering why msys2 doesn't take whatever changes git for windows has to posix dll or whatever tweaks.
    David Macek
    @elieux
    There's a history around that if you wanna read it, but the summary is a combination of communication issues and possibly a difference of opinions on how some things need to work.
    Johannes Schindelin
    @dscho
    The short of it (from the Git for Windows maintainer's point of view) is: I would love to have more active contributors that would help make this a supported use case.
    awmorgan
    @awmorgan
    I'm trying to diagnose the performance difference between the version of git that comes with the SDK and the non-SDK version. When I run GIT_TRACE=1 git status, the SDK version (2.27.0) it prints out an extra line for every operation compared to the non-SDK version (2.14.1). The extra line in the SDK trace printout is 18:58:30.157173 exec-cmd.c:237 trace: resolved executable dir: C:/git-sdk-64/mingw64/libexec/git-core. This 'resolved executable dir' is not coming out from the non-SDK 2.14.1 version. 2.14.1 is the faster version and 2.27.0 is the slower version. Is there a way to get checkout the 2.14.1 version into into the SDK? The SDK repo has 1 commit so I'm guessing the SDK installer did a shallow clone for some reason.
    David Macek
    @elieux
    Is it possible the SDK build is just unoptimized?
    Johannes Schindelin
    @dscho

    I'm guessing the SDK installer did a shallow clone for some reason.

    You guessed correctly! You can "fix" that via git -C / fetch --unshallow

    And yes, you should be able to check out a past revision. Two challenges with that:
    1. figure out which revision to check out (git -C / log --stat var/lib/pacman/local/mingw-w64-x86_64-git-2\* should help), and
    2. you cannot check out a different revision while the Git SDK Bash is running (as it uses files that would need to be overwritten). I typically use a regular Git Bash for that, to avoid this issue.
    David Macek
    @elieux
    mingw-w64-git is contained in the SDK, @dscho?
    I thought we were talking about the one built automatically from source on first run.
    awmorgan
    @awmorgan

    @dscho I did the fetch --unshallow, then searched the log with the command you posted: log --stat var/lib/pacman/local/mingw-w64-x86_64-git-2*. I am searching for 2.14.1.windows.1. The closest match that I found was 634b9e9d3feaaa3cddf6119be2fb2ab273a7833a which had .../mingw-w64-x86_64-git-2.14.1.1.82d9b3f3b2-1/mtree. I checked out 634b9e9d3feaaa3cddf6119be2fb2ab273a7833a and did version on the sdk /usr/bin/git and it is not the right version so I must be still doing something wrong.

    MINGW64 /c/git-sdk-64 (detached)
    $ git log -1 --oneline
    634b9e9d3f (HEAD) Update 20170810-182827
    MINGW64 /c/git-sdk-64 (detached
    )
    $ /c/git-sdk-64/usr/bin/git.exe version
    git version 2.13.3
    MINGW64 /c/git-sdk-64 (detached)
    $ git version
    git version 2.14.1.windows.1
    MINGW64 /c/git-sdk-64 (detached
    )
    $

    David Macek
    @elieux
    By the way, /usr/bin/git is definitely expected to be slower.
    which git tells where the Git you're running comes from.
    awmorgan
    @awmorgan

    since I could not figure out how to checkout 2.14.1.windows.1 into the SDK, I installed Git for Windows 2.27 so now I have 2.27.0.windows.1 installed in both the SDK and non-SDK directories:

    C:\git-sdk-64\mingw64\bin\git.exe <= 2.27.0.windows.1
    C:\Program Files\Git\mingw64\bin\git.exe <= 2.27.0.windows.1

    the version in SDK is still slower than the non-SDK for some reason.

    SDK bash shell, git status times:
    real 0m5.126s
    real 0m5.036s
    real 0m5.051s
    real 0m5.042s

    non-SDK bash shell, git status times:
    real 0m3.644s
    real 0m3.666s
    real 0m3.583s
    real 0m3.603s

    I did a sha256sum on both versions to check @elieux theory that the SDK version might be an un-optimized build and they are the same (at least the git.exe program is the same in both versions, not sure about all the other git bits). Both were: 8ab826897cb96bd9de16fec8e907706cc860ee3b93939c6328e7f7ed11e9a885

    There something in the SDK bash shell environment that is causing git status to be slower.

    Also note that I was getting times around 2.6s for 2.14.1.windows.1 which is about a whole second faster than what I'm now getting with 2.27.0.windows.1 non-SDK.

    in both SDK and non-SDK core.fscache=true

    awmorgan
    @awmorgan
    I verified 'which git' in both SDK and non-SDK are using the same: /mingw64/bin/git. I was wrong when trying to check the version on /usr/bin/git. @elieux thanks for pointing that out.
    David Macek
    @elieux
    It's entirely possible some shell-related stuff is set up differently in"Git Bash" and the SDK shell.
    Johannes Schindelin
    @dscho
    @elieux I think we no longer automatically build and install Git upon installing the Git for Windows SDK (we might still build it, but I don't think we ever installed it).
    David Macek
    @elieux
    Okay.
    But it's correct that both git and mingw-w64-git are part of the SDK?
    Johannes Schindelin
    @dscho
    Yes.
    /usr/bin/git.exe is required to build any packages that check out Git branches or tags.
    David Macek
    @elieux
    With the risk of being redirected to find it out in the tickets, I ask if Git for Windows is doing something shady with /bin.
    Brent Arias
    @brentarias
    I have created a git submodule on a branch feature/AL-5518. I've pushed both the repo and submodule for my coworkers. Now the first coworker wants to see the code. Am I right that the proper procedure is to (1) fetch the new branch "normally" and switch to it then (2) issue this command git submodule update --init? I don't need recursion.
    David Macek
    @elieux
    Sounds good, @brentarias.
    Johannes Schindelin
    @dscho
    @elieux Git for Windows is doing something shady with /bin: it installs redirectors there, for sh.exe, bash.exe and git.exe. Essentially, all three of them are the Git wrapper.
    If you call sh or bash from there, they will of course spawn the real Bash, which (by virtue of using the MSYS2 runtime) will overlay /usr/bin on top of /bin and you won't see the redirectors anymore.
    David Macek
    @elieux
    What's the use case?
    Johannes Schindelin
    @dscho
    That some super ancient Git setups that finally made the jump to Git for Windows v2.x assumed that C:\Program Files\Git\bin\sh.exe -lc <command> would work.
    David Macek
    @elieux
    Okay. It's not bringing me joy to have those files, but I guess they don't cause any trouble.
    Johannes Schindelin
    @dscho
    Instead, they actually help our automation, as it is now much easier to call shell scripts from a PowerShell task in a Pipeline.
    David Macek
    @elieux
    What's wrong with adding \usr to that command?
    Johannes Schindelin
    @dscho
    That it defaults to MSYSTEM=<unspecified>?
    I want it to default to MINGW64 in 64-bit setups and MINGW32 in 32-bit setups.
    David Macek
    @elieux
    Okay, makes sense.