Code Monkey home page Code Monkey logo

git-sdk-64's People

Contributors

allanmcrae avatar dennisameling avatar dependabot[bot] avatar dscho avatar jamill avatar rimrul avatar vdye avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

git-sdk-64's Issues

why does sdk-installer start git-bash.exe?

I want automated installations of git-sdk, and got quite far:

.\git-sdk-installer-1.0.8-64.7z.exe -o "C:\git-sdk-64" -y

installs nicely, but once its done setup-it-sdk.bat does

  @START /B git-bash.exe

... and that hangs all my automation. Its window isn't even visible when its started by my automation system. I just found that by noticing the process, then killing it and observed the installation to continue.

Can that line be removed?

Or can the "-y" flag from the installer skip it?

etc/DIR_COLORS should include mintty in the TERM list

In the etc/DIR_COLORS file shipped with Git-for-Windows, many terminal emulators are listed there indicating they support colors. But mintty, the default terminal emulator shipped with Git-for-Windows, is not there.

Because of this, "ls --color" doesn't show any color if the default "mintty" is used as the $TERM. It should be included in it.

sdk cd|init|build git does not work

I have just downloaded git sdk and after the terminal opened

FOO@BAR MINGW64 / (master)
$ sdk cd git
Could not change directory to 'git'

FOO@BAR MINGW64 / (master)
$ sdk init git

FOO@BAR MINGW64 / (master)
$ sdk build git

FOO@BAR MINGW64 / (master)
$ sdk cd git
Could not change directory to 'git'

sdk cd can't find refs/heads/master on fresh installs

When initially running sdk cd build-extra on a fresh install, it complains

error: refname refs/heads/master not found
fatal: Umbenennung des Branches fehlgeschlagen
Could not change directory to 'build-extra'

Umbenennung des Branches fehlgeschlagen means renaming the branch failed. The same thing happens on sdk cd git and sdk cd msys2-runtime. cd /usr/src/git (or /usr/src/build-extra or /usr/src/MSYS2-packages) followed by git pull origin main seems to fix the issue.

Can we use this version to use another shell in VS Code?

Hey,

As I wanted to use the Fish shell in Git Bash, I switched to this SDK version. I cannot find out if there's a helper to set up a MSYS2 shell, like bin/bash.exe in the standard Git for Windows installation.

Another different problem is that there is no way to change the default shell, as git-bash.exe hardcodes the login shell to Bash.

Can you help out with this?

`sdk create-desktop-icon` fails with "Could not save link"

During Git SDK for Windows installation (from git-sdk-installer-1.0.7-64.7z.exe file), and later when trying to run sdk create-desktop-icon I get the following error:

Could not save link
Error: System could not find the given path.

The Git SDK icon failed to appear on the desktop, either.

(the error message is loosely translated from the localized error message).

update-via-pacman ends with a `conflicting files` for the `scalar.exe` files

Not sure if this is the right repo to report the issue... Which has happened in two contexts in the last day or so.

Initially, when compiling (via sdk build git-and-installer) a PR to test it, I had this error. I renamed the files out of the way and re-tried - same error.

Now I tried the update-via-pacman.bat in a CMD window and got the same error. The results are below, with the boring bits trimmed.

I'm guessing that some update relating to scalar isn't quite synchronised yet and the conflict shouldn't happen. Just not sure where to look/start. Any clues?

C:\git-sdk-64>update-via-pacman.bat
Run Pacman
:: Synchronizing package databases...
 git-for-windows                                                              48.2 KiB  48.1 KiB/s 00:01 [#############################################################] 100%
 git-for-windows-mingw32                                                      17.2 KiB  21.4 KiB/s 00:01 [#############################################################] 100%
 mingw32                                                                    1721.8 KiB  1449 KiB/s 00:01 [#############################################################] 100%
 mingw64                                                                    1733.1 KiB  1617 KiB/s 00:01 [#############################################################] 100%
 ucrt64                                                                     1784.0 KiB   896 KiB/s 00:02 [#############################################################] 100%
 clang64                                                                    1724.3 KiB  1692 KiB/s 00:01 [#############################################################] 100%
 msys                                                                        403.1 KiB  2.43 MiB/s 00:00 [#############################################################] 100%
:: Starting core system upgrade...
 there is nothing to do
:: Starting full system upgrade...
resolving dependencies...
looking for conflicting packages...
warning: dependency cycle detected:
warning: mingw-w64-x86_64-libwebp will be installed before its mingw-w64-x86_64-libtiff dependency

Packages (140) [...]
..
...
Total Installed Size:  2678.92 MiB
Net Upgrade Size:        33.14 MiB

:: Proceed with installation? [Y/n]
(140/140) checking keys in keyring                                                                       [#############################################################] 100%
(140/140) checking package integrity                                                           [######################################################] 100%-
(140/140) loading package files                                                                [######################################################] 100%
(140/140) checking for file conflicts                                                          [######################################################] 100%
error: failed to commit transaction (conflicting files)
mingw-w64-x86_64-git: /mingw64/bin/scalar.exe exists in filesystem
mingw-w64-x86_64-git: /mingw64/libexec/git-core/scalar.exe exists in filesystem
Errors occurred, no packages were upgraded.
Pacman update failed
Press any key to continue . . .

The sdk build git-and-installer failures are below for comparison.

          ln -s "git-remote-http.exe" "$execdir/$p" 2>/dev/null || \
          cp "$execdir/git-remote-http.exe" "$execdir/$p" || exit; } \
done
make: Leaving directory '/usr/src/git'
:: Synchronizing package databases...
 git-for-windows        48.2 KiB  47.4 KiB/s 00:01 [#####################] 100%
 git-for-windows-...    17.2 KiB  20.3 KiB/s 00:01 [#####################] 100%
 mingw32              1721.5 KiB  1226 KiB/s 00:01 [#####################] 100%
phili@Philip-Win10 MINGW64 / (main)
$ sdk build  git-and-installer
make: Entering directory '/usr/src/git'
    BUILTIN all
make[1]: Entering directory '/usr/src/git/git-gui'
make[1]: Leaving directory '/usr/src/git/git-gui'
[.
.
.] 
mingw64              1733.0 KiB  2.07 MiB/s 00:01 [#####################] 100%
 ucrt64               1784.4 KiB  1849 KiB/s 00:01 [#####################] 100%
 clang64              1724.3 KiB  1332 KiB/s 00:01 [#####################] 100%
 msys                  403.0 KiB   270 KiB/s 00:01 [#####################] 100%
:: Starting core system upgrade...
 there is nothing to do
:: Starting full system upgrade...
resolving dependencies...
looking for conflicting packages...
warning: dependency cycle detected:
warning: mingw-w64-x86_64-libwebp will be installed before its mingw-w64-x86_64-libtiff dependency

Packages (139) autogen-5.18.16-4  binutils-2.39-1  curl-7.85.0-1  expat-2.4.9-1
               file-5.43-1  gdb-11.1-3  git-2.38.0-1  lemon-3.39.4-1
               less-608-1  libcurl-7.85.0-1  libexpat-2.4.9-1  libffi-3.4.3-1
               libgc-8.2.2-1  libgnutls-3.7.8-1  libgpgme-1.18.0-1
               libguile-3.0.8-2  libhogweed-3.8.1-1  libidn2-2.3.3-1
               libksba-1.6.2-1  liblz4-1.9.4-1  liblzma-5.2.7-1
[...]
               perl-TermReadKey-2.38-7  perl-XML-Parser-2.46-6
               perl-YAML-Syck-1.34-2  pinentry-1.2.1-1  python-3.10.6-1
               rsync-3.2.6-1  subversion-1.14.2-1  tig-2.5.7-1  tzcode-2022e-1
               xz-5.2.7-1  git-extra-1.1.600.cbd5e15-1

Total Download Size:    403.80 MiB
Total Installed Size:  2677.37 MiB
Net Upgrade Size:        33.16 MiB

:: Proceed with installation? [Y/n]
:: Retrieving packages...
 mingw-w64-i686-i...    21.8 MiB  3.56 MiB/s 00:06 [#####################] 100%
 mingw-w64-i686-p...    18.4 MiB  1207 KiB/s 00:16 [#####################] 100%
 mingw-w64-x86_64...    28.3 MiB  1739 KiB/s 00:17 [#####################] 100%
[...]
mingw-w64-i686-l...    45.0 KiB  78.9 KiB/s 00:01 [#####################] 100%
 mingw-w64-x86_64...    21.9 KiB   142 KiB/s 00:00 [#####################] 100%
 mingw-w64-x86_64...    27.9 KiB  92.8 KiB/s 00:00 [#####################] 100%
 perl-TermReadKey...    21.5 KiB  81.6 KiB/s 00:00 [#####################] 100%
 perl-Locale-Gett...    13.2 KiB  9.82 KiB/s 00:01 [#####################] 100%
 perl-Clone-0.45-...    11.6 KiB  9.43 KiB/s 00:01 [#####################] 100%
 mingw-w64-i686-l...    21.7 KiB  8.99 KiB/s 00:02 [#####################] 100%
 Total (139/139)       403.8 MiB  6.16 MiB/s 01:06 [#####################] 100%
(139/139) checking keys in keyring                 [#####################] 100%
(139/139) checking package integrity                                                                 [###########################################################] 100%
(139/139) loading package files                                                                      [###########################################################] 100%
(139/139) checking for file conflicts                                                                [###########################################################] 100%
error: failed to commit transaction (conflicting files)
mingw-w64-x86_64-git: /mingw64/bin/scalar.exe exists in filesystem
mingw-w64-x86_64-git: /mingw64/libexec/git-core/scalar.exe exists in filesystem
Errors occurred, no packages were upgraded.

phili@Philip-Win10 MINGW64 / (main)
$
remaned (via explorer) both to scalar0.exe

$ sdk build git-and-installer

--> same fail!

The README.md doesn't show on the home page

The repo home page says
"Help people interested in this repository understand your project by adding a README. "

The PR #8 by cooffe to add one was merged on 14 Jun 19 4ea8f3e but does not show.

I suspect (as I type) that it should have been merged to master, not (if I read the page correctly) git-for-windows:msys2-runtime-2.x

Thoughts?

How to remove welcome message from prompt?

Every time I start up a bash prompt it displays the message:

Welcome to the Git for Windows SDK!

The common tasks are automated via the sdk function;
See sdk help for details.

Also, whenever I restart Windows, a link to "Git SDK 64-bit" keeps getting added back to the desktop.

How can I both remove this welcome message and stop this link from being added to the desktop at login?

Investigate new `ci-artifacts` flakiness

As of https://github.com/git-for-windows/git-sdk-64/actions/runs/7895871817/job/21548925651, it seems that there is a flaky problem. The symptom looks like this:

    [...]
    LINK scalar.exe
strip  headless-git.exe git-daemon.exe git-http-backend.exe git-imap-send.exe git-sh-i18n--envsubst.exe git-shell.exe git-http-fetch.exe git-http-push.exe git-remote-http.exe git-remote-https.exe git-remote-ftp.exe git-remote-ftps.exe git.exe
D:\a\git-sdk-64\git-sdk-64\minimal-sdk\mingw64\bin\strip.exe: unable to copy file 'git.exe'; reason: Permission denied
make: *** [Makefile:2376: strip] Error 1
make: *** Waiting for unfinished jobs....
make: Leaving directory '/d/a/git-sdk-64/git'
Error: Process completed with exit code 2.

This problem usually goes away after re-running a couple of times (once I had to re-run 3 times to make it succeed).

The lucky thing is that the strip Makefile rule is apparently not used in git/git's own CI, therefore things don't fail there (which would be disastrous). So we do not need to drop everything and fix this Right Now, but it needs to be fixed.

Now, the commit corresponding to the first build that exhibited the problem is 863c871. Contrary to what I first thought, that commit did not update the MSYS2 runtime. That update came in the next commit.

Comparing the first failing job with the corresponding job of the previous build, I see in the Set up job step that the runner version changed, from v2.312.0 to v2.313.0. But I don't see any obvious culprit in that version's release notes.

Also in the Set up job step, I see a difference in the runner image (but not in the Windows version), but the corresponding diff also does not shed any light into the issue.

It is possible, of course, that the previous build succeeded on first attempt due to flakiness rather than by virtue of being non-flaky. More investigation is needed here.

make WINSSL default

Make the windows secure channel option the default in the installer for finding SSL certificates

SSH doesn't always work

I'm having troubles using ssh with git-sdk-64. Basically, if I try to connect to a server, I get a "Permission denied" error. If, on the other hand, I use a Powershell or even WSL I get the usual password prompt.
This problem only appears with a few servers, while doesn't appear on others (I still haven't figured out which kind of server).
Do you know what the problem could be?

Suggestion: add `mingw-w64-python-pygments` to the SDK, so GDB syntax-highlights source code

It would be nice if the GDB available in the SDK would color source code (i.e. with the list command or the in the TUI.). The easiest way to do that is simply to have the Python Pygments library installed; GDB should find it and use it (it's way easier than building GDB with the GNU source-highlight library, which - for me - seems to never results in a working build).

  1. Is this the right repo to open such an issue (build-extra does not have the "Issues" tab) ?
  2. I'm not sure of what the process of adding a package to the SDK would look like. I looked through the wiki but could not find the info (maybe I did not look hard enough!)

Python hangs in git bash terminal

Once I install Python 3.8 from the official website and run python command from git bash shell it hangs.
There for, i suggest to include Python in the aliases.sh script.

Failed to build from source

I downloaded the sdk and tried to build, but it failed:

$ sdk build git
....
....
git-compat-util.h:321:10: fatal error: openssl/ssl.h: No such file or directory
 #include <openssl/ssl.h>

Windows 7.
git is at e2d2aac684

Onboarded ``msgcat`` binary is broken

msgcat -o file.po file.po command produces syntax errors in .po files.

Turns

#: library/stdtypes.rst:419 library/stdtypes.rst:1171
#: library/stdtypes.rst:2397 library/stdtypes.rst:3615
msgid "\\(4)"
msgstr "\\(4)"

to

#: library/stdtypes.rst:419 library/stdtypes.rst:1171
#: library/stdtypes.rst:2397
 library/stdtypes.rst:3615
msgid "\\(4)"
msgstr "\\(4)"

which is syntactically wrong. However, on some files, it does keep it the correct way. The above example is from python/python-docs-tr (library/stdtypes.po).

It also adds whitespace at the top of the first msgid-msgstr pair.

# Python Documentation Turkish Translation
# Copyright (C) 2001-2023, Python Software Foundation
# This file is distributed under the same license as the Python package.
-#
+# 
msgid ""
msgstr ""

Using other binaries, however, doesn't produce any of these errors.

Only create desktop icon once, or ideally not at all

I'm not sure if this is a bug, or intended behavior. The desktop icon for git-sdk-64 is recreated every time I open a new shell (if I have previously deleted the icon). This is frustrating behavior and is contrary to how most applications create a desktop icon (optionally, during the installation process).

Commenting out the portion of the git-sdk.sh in profile.d is easy enough to do, but is it possible to remove this functionality to move it to an installation step instead?

Is `make doc` via the asciidoc meant to be working at the moment?

When I try to use make doc from the sdk to confirm that a documentation change is correct, I'm getting a failure that asciidoc isn't finding it's own asciidoc.conf file:

phili@Philip-Win10 MINGW64 /c/git-sdk-64/usr/src/git ((v2.27.0-rc0))
$ git checkout docfixup2
Previous HEAD position was efcab5b7a3 Git 2.27-rc0
Switched to branch 'docfixup2'
Your branch is ahead of 'origin/master' by 1 commit.
  (use "git push" to publish your local commits)

phili@Philip-Win10 MINGW64 /c/git-sdk-64/usr/src/git (docfixup2)
$ make V=1 doc
make -C Documentation all
make[1]: Entering directory '/c/git-sdk-64/usr/src/git/Documentation'
rm -f cmd-list.made && \
/usr/bin/perl ./cmd-list.perl ../command-list.txt  && \
date >cmd-list.made
rm -f doc.dep+ doc.dep && \
/usr/bin/perl ./build-docdep.perl >doc.dep+  && \
mv doc.dep+ doc.dep
make -C ../  GIT-VERSION-FILE
make[2]: Entering directory '/c/git-sdk-64/usr/src/git'
make[2]: 'GIT-VERSION-FILE' is up to date.
make[2]: Leaving directory '/c/git-sdk-64/usr/src/git'
make -C ../  GIT-VERSION-FILE
make[2]: Entering directory '/c/git-sdk-64/usr/src/git'
make[2]: 'GIT-VERSION-FILE' is up to date.
make[2]: Leaving directory '/c/git-sdk-64/usr/src/git'
rm -f git-add.html+ git-add.html && \
asciidoc -a git-asciidoc-no-roff -f asciidoc.conf -amanversion=2.26.2.windows.1.9.gdb3dacfacb -amanmanual='Git Manual' -amansource='Git' -b xhtml11 -d manpage -o git-add.html+ git-add.txt && \
mv git-add.html+ git-add.html
asciidoc: FAILED: configuration file asciidoc.conf missing
make[1]: *** [Makefile:363: git-add.html] Error 1
make[1]: Leaving directory '/c/git-sdk-64/usr/src/git/Documentation'
make: *** [Makefile:2506: doc] Error 2

phili@Philip-Win10 MINGW64 /c/git-sdk-64/usr/src/git (docfixup2)

If I copy the C:\git-sdk-64\etc\asciidoc\asciidoc.conf into the C:\git-sdk-64\usr\bin folder (where asciidoc is located) then the error moves onto not finding other files from the \etc\ folder.

The USE_ASCIIDOCTOR=1 make doc also fails:

Traceback (most recent call last):
        2: from C:/git-sdk-64/mingw64/bin/asciidoctor:23:in `<main>'
        1: from C:/git-sdk-64/mingw64/lib/ruby/2.7.0/rubygems.rb:294:in `activate_bin_path'
C:/git-sdk-64/mingw64/lib/ruby/2.7.0/rubygems.rb:275:in `find_spec_for_exe': can't find gem asciidoctor (>= 0.a) with executable asciidoctor (Gem::GemNotFoundEx
ception)

My sdk is up to date via the update-via-pacman.bat script.
I do keep bash and cmd separate.

Any suggestions? inc, is there a Documenation build (only) option for pushes to Github?

conflicting files: /etc/inputrc exists in both 'libreadline' and 'git-extra'

After a long time (a year or so) I attempt to update my SDK that I had seeded from git-sdk-64 years ago. This time

pacman -Syu

stops with the error

:: Proceed with installation? [Y/n]
(249/249) checking keys in keyring                 [#####################] 100%
(249/249) checking package integrity               [#####################] 100%
(249/249) loading package files                    [#####################] 100%
(249/249) checking for file conflicts              [#####################] 100%
error: failed to commit transaction (conflicting files)
/etc/inputrc exists in both 'libreadline' and 'git-extra'
Errors occurred, no packages were upgraded.

I wonder how it is possible that this project can have both packages libreadline and git-extra when there are conflicting files. Is there some magic knob to twist so that I can install both packages? Where to investigate further?

As a temporary workaround I have removed package git-extra, but now I cannot install it anymore due to the conflict.

(I would have posted this under build-extra, but it has no Issues section.)

Error: RPC failed every time I try to --recursive download the .git

I get this output
C:\Users\XXXXX\eclipse-workspace>git clone --recursive https://github.com/git-for-windows/git-sdk-64.git
Cloning into 'git-sdk-64'...
remote: Enumerating objects: 503776, done.
remote: Counting objects: 100% (1268/1268), done.
remote: Compressing objects: 100% (889/889), done.
error: RPC failed; curl 56 OpenSSL SSL_read: error:1408F119:SSL routines:ssl3_get_record:decryption failed or bad record mac, errno 0
error: 668 bytes of body are still expected
fetch-pack: unexpected disconnect while reading sideband packet
fatal: early EOF
fatal: fetch-pack: invalid index-pack output

Is the git-sdk-64.git built properly?

Removal of e-Tugra root certificate

Description
Certifi 2023.07.22 removes root certificates from "e-Tugra" from the root store. These are in the process of being removed from Mozilla's trust store.

e-Tugra's root certificates are being removed pursuant to an investigation prompted by reporting of security issues in their systems. Conclusions of Mozilla's investigation can be found here.

Informations

Manifest Path : mingw32/etc/ssl/certs/ca-bundle.trust.crt

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.