The README.md doesn't show on the home page
PhilipOakley opened this issue · 5 comments
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?
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
Yes.
@dscho I made a good pull request. Can you review it and accept it please ? Thanks in advance.
The readme simply says that it's "mirroring" the SDK.
I'd have expected the readme to explain how to use/update the sdk (e.g. the link https://github.com/git-for-windows/git/wiki/Technical-overview, from our home page). And, if this is a mirror, the primary location (but I think this is the location...).
Mainly I'm here now because I was getting myself confused about the difference between updating the SDK via the update-via-pacman.bat method, and fetching updates from here (I'm still at 685647a), and how to handle any divergence...
In particular make doc isn't working for me because asciidoc can't find its config file, which is in /etc/ ...
explain how to use/update the sdk (e.g. the link https://github.com/git-for-windows/git/wiki/Technical-overview, from our home page).
It is unfortunately not all that easy.
On a very basic level, it should be totally okay to update via git pull (in a Git Bash, with all Git SDK Bash instances closed) all the time.
To make this nicer for GitHub, you should run the first git pull with the --unshallow option: fetches into shallow clones are really expensive server-side.
Side note: for that reason, I am considering to modify the Git SDK installer to use partial clones instead of shallow clones. (If you feel like taking up that project, I would be delighted.)
Alternatively, and maybe a lot easier on GitHub, would be to require updates to be performed via update-via-pacman.bat and not worry about git status showing tons of modified/deleted/untracked files.
If we were to make this the recommended (or only) way to update the SDK, we should actually delete .git/ at the end of the Git SDK installer.
For some time, pacman -Syu used to be quite unstable, it would frequently time out. That is the main reason why I left the .git directory in there, and why I myself use it to update my own copy of the SDK.
The main problem with git pull arises when you install packages that are not tracked in git-sdk-64. Then, a git pull would have to be accompanied by a subsequent pacman -Su (without -y).
I tried to remedy this situation a bit by teaching the commit-msys2.sh script in build-extra the ignore -a **command: essentially, it will add entries in the .git/info/exclude file (which is like .gitignore, but untracked) for all the packages you have installed on top of what is tracked. The idea is to run it after every call to pacman -Su; That way, git status won't show untracked files unless you really have any files that do not belong to any installed package.
And, if this is a mirror, the primary location (but I think this is the location...).
The Git repository is a mirror in the sense that it is not exactly the authoritative source of truth: the Pacman repositories are. It is a "mirror", but not a "mirror of another Git repository".
updating the SDK via the
update-via-pacman.batmethod, and fetching updates from here (I'm still at 685647a), and how to handle any divergence...
Whenever I get into such a situation, I run git fetch && git reset --soft FETCH_HEAD && git stash or something like that (from a Git Bash, with all instances of Git SDK Bash closed, of course).
In particular
make docisn't working for me because asciidoc can't find its config file, which is in /etc/ ...
Please note that we build Git for Windows' documentation using AsciiDoctor, i.e. USE_ASCIIDOCTOR = YesPlease.
Please feel free to provide this information wherever you think is most suitable, whether in a README.md in git-sdk-64 or in the Git for Windows wiki.
Yes, it's been on my back-list for far too long.
😞