You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was not able to find an open or closed issue matching what I'm seeing
To pick up a draggable item, press the space bar.
While dragging, use the arrow keys to move the item.
Press space again to drop the item in its new position, or press escape to cancel.
Is it possible to deploy Git with symbolic links in libexec/git-core instead of many hard copies of the git executable?
instead of many hard copies of the git executable?
This is incorrect. Those are not copies, those are hard links. It is true that Windows Explorer double-counts them, but they do not occupy more disk space than one copy + 127 directory entries pointing to the same start disk sector. You can verify this by running the following command:
$ ls -l /mingw64/bin/git.exe
-rwxr-xr-x 127 johannes 197121 2755352 Dec 15 09:52 /mingw64/bin/git.exe*
See that 127? That's the number of directory entries pointing at the same file contents.
@organds, Any suggestions as to where the best place(s) would be to highlight the information?
It is a question that does come up moderately frequently, so as some one who has been hit by the issue, maybe have a think about where you looked (or even if didn't 'look', why that was) so that we can educate folks and reduce the misunderstandings. Every little helps.
[Would it be worth adding a line to the 'Known Issues' of the Release notes file:///C:/Program%20Files/Git/ReleaseNotes.html, just the head the issue off at the pass]
@orgads yeah, no. I don't think that would be a good idea. First of all, this file would have to be generated only if the files really are hardlinks, and then that file would have to be left out e.g. when copying those files. That's just too fragile.
At some point, we have to bite the bullet and just accept that most users do not really understand their system and need the explanation. I just hope that the number of contributors who relieve the maintainer of explaining this (in favor of chasing much harder bugs, or in favor of trying to hammer down work hours to a normal level) will continue to increase.
@dscho wrote: just accept that most users do not really understand their system and need the explanation (that the "use links in libexec/git-core instead of many hard copies of the git executable" is already done via Windows hardlinks).
Would I be reading this right, that my suggestion of a short(ish) extra line in the 'known issues' section could be that explanation? It may only find 40% of the users but at least its a reduction in complaints... (Should I add it to my list of things to do on retiral;-)
Activity
dscho commentedon Dec 23, 2018
Only if you build Git yourself.
However:
This is incorrect. Those are not copies, those are hard links. It is true that Windows Explorer double-counts them, but they do not occupy more disk space than one copy + 127 directory entries pointing to the same start disk sector. You can verify this by running the following command:
$ ls -l /mingw64/bin/git.exe -rwxr-xr-x 127 johannes 197121 2755352 Dec 15 09:52 /mingw64/bin/git.exe*
See that 127? That's the number of directory entries pointing at the same file contents.
PhilipOakley commentedon Dec 23, 2018
@organds, Any suggestions as to where the best place(s) would be to highlight the information?
It is a question that does come up moderately frequently, so as some one who has been hit by the issue, maybe have a think about where you looked (or even if didn't 'look', why that was) so that we can educate folks and reduce the misunderstandings. Every little helps.
[Would it be worth adding a line to the 'Known Issues' of the Release notes file:///C:/Program%20Files/Git/ReleaseNotes.html, just the head the issue off at the pass]
orgads commentedon Dec 24, 2018
I see. So you have one extra executable: libexec/git-core/git.exe:
@PhilipOakley : Maybe add an empty file inside libexec/git-core named
___MOST-EXECUTABLES-ARE-HARDLINKS___
. That would have attracted my attention :)dscho commentedon Dec 26, 2018
@orgads yeah, no. I don't think that would be a good idea. First of all, this file would have to be generated only if the files really are hardlinks, and then that file would have to be left out e.g. when copying those files. That's just too fragile.
At some point, we have to bite the bullet and just accept that most users do not really understand their system and need the explanation. I just hope that the number of contributors who relieve the maintainer of explaining this (in favor of chasing much harder bugs, or in favor of trying to hammer down work hours to a normal level) will continue to increase.
PhilipOakley commentedon Jan 3, 2019
Would I be reading this right, that my suggestion of a short(ish) extra line in the 'known issues' section could be that explanation? It may only find 40% of the users but at least its a reduction in complaints... (Should I add it to my list of things to do on retiral;-)
dscho commentedon Jan 7, 2019
@PhilipOakley sounds good ;-)
ReleaseNotes: duplicated files are hard links
dscho commentedon Feb 27, 2019
Addressed via git-for-windows/build-extra#229
10 remaining items