Documentation for git-cmd.exe
113 views
Skip to first unread message
Gregory Shields
Oct 3, 2019, 11:06:27 PM10/3/19
to git-for-windows
I've really tried, but cannot seem to find the documentation for git-cmd.exe. In particular, I'm interested in the command line switches.
Could someone point me to that?
Thanks.
gregory...@gmail.com
Oct 4, 2019, 5:04:50 AM10/4/19
to git-for-windows
I've really tried, but cannot seem to locate any documentation of git-cmd.exe. In particular, the command line switches.
Johannes Schindelin
Oct 4, 2019, 6:08:38 AM10/4/19
to Gregory Shields, git-for-windows
Hi Gregory,
Unfortunately, there isn't any, at the moment. The best thing for now is
the source code:
https://github.com/git-for-windows/MINGW-packages/blob/737f0ad83b16ee1e9771559bdf8a06ebf2493014/mingw-w64-git/git-wrapper.c#L510-L533
You might be interested, though, in starting a help page on `git-cmd`.
The best idea would be to copy-edit e.g.
https://github.com/git-for-windows/git/blob/v2.23.0.windows.1/Documentation/git.txt
next to the `git-wrapper.c` and integrate it into the packaging of the
`mingw-w64-git` package.
Tell you what, if you provide me with a `git-cmd.exe` based on that
`git.txt`, I will take care of the integration?
Thanks,
Johannes
the source code:
https://github.com/git-for-windows/MINGW-packages/blob/737f0ad83b16ee1e9771559bdf8a06ebf2493014/mingw-w64-git/git-wrapper.c#L510-L533
You might be interested, though, in starting a help page on `git-cmd`.
The best idea would be to copy-edit e.g.
https://github.com/git-for-windows/git/blob/v2.23.0.windows.1/Documentation/git.txt
next to the `git-wrapper.c` and integrate it into the packaging of the
`mingw-w64-git` package.
Tell you what, if you provide me with a `git-cmd.exe` based on that
`git.txt`, I will take care of the integration?
Thanks,
Johannes
Philip Oakley
Oct 4, 2019, 6:09:52 AM10/4/19
to git-for-windows
What were you trying to actually switch?
IIRC it is just a wrapper to start the cmd window such that git itself can be run with the right paths and directories setup.
Try the FAQs https://github.com/git-for-windows/git/wiki/FAQ on the wiki for a bit of insight (or the closed Issues on https://github.com/git-for-windows/git/issues?utf8=%E2%9C%93&q=is%3Aissue) and maybe https://github.com/git-for-windows/build-extra
Philip
PS If you can summarise the expected documentation from what you find, that adding it to the wiki would be a great help (even if it is only partial)
Johannes Schindelin
Oct 4, 2019, 9:21:16 AM10/4/19
to Philip Oakley, git-for-windows
Hi Philip,
On Fri, 4 Oct 2019, Philip Oakley wrote:
> What were you trying to actually switch?
>
> IIRC it is just a wrapper to start the cmd window such that git itself can
> be run with the right paths and directories setup.
That is partially true. But there is more to it:
- you can override the command to be run. This allows e.g. calling an
arbitrary command-line program, with all the environment variables set
up correctly to run _this_ particular Git.
For example, you can use it to call the Git for Windows SDK Bash in a
CMD window after installing that SDK to C:\git-sdk-64 via
`C:\git-sdk-64\git-cmd.exe --command=usr\bin\bash.exe -li`
- When allowing `git-cmd` to run the regular CMD "REPL", the `git`
command is overridden using `doskey` (equivalent to Bash's aliases),
to avoid picking up any `git.exe` or `git.bat` in the current
directory.
And that's just two aspects of it.
Ciao,
Johannes
> for a bit of *insight *(or the closed Issues on
> You received this message because you are subscribed to the Google Groups "git-for-windows" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to git-for-windo...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/git-for-windows/428d9016-0b99-479e-b8df-58698b1d9059%40googlegroups.com.
>
On Fri, 4 Oct 2019, Philip Oakley wrote:
> What were you trying to actually switch?
>
> IIRC it is just a wrapper to start the cmd window such that git itself can
> be run with the right paths and directories setup.
- you can override the command to be run. This allows e.g. calling an
arbitrary command-line program, with all the environment variables set
up correctly to run _this_ particular Git.
For example, you can use it to call the Git for Windows SDK Bash in a
CMD window after installing that SDK to C:\git-sdk-64 via
`C:\git-sdk-64\git-cmd.exe --command=usr\bin\bash.exe -li`
- When allowing `git-cmd` to run the regular CMD "REPL", the `git`
command is overridden using `doskey` (equivalent to Bash's aliases),
to avoid picking up any `git.exe` or `git.bat` in the current
directory.
And that's just two aspects of it.
Ciao,
Johannes
> for a bit of *insight *(or the closed Issues on
> https://github.com/git-for-windows/git/issues?utf8=%E2%9C%93&q=is%3Aissue)
> and maybe https://github.com/git-for-windows/build-extra
>
> Philip
>
> PS If you can summarise the expected documentation from what you find, that
> adding it to the wiki would be a great help (even if it is only partial)
>
> On Friday, October 4, 2019 at 4:06:27 AM UTC+1, Gregory Shields wrote:
> >
> > I've really tried, but cannot seem to find the documentation for
> > git-cmd.exe. In particular, I'm interested in the command line switches.
> > Could someone point me to that?
> >
> > Thanks.
> >
>
> --
> and maybe https://github.com/git-for-windows/build-extra
>
> Philip
>
> PS If you can summarise the expected documentation from what you find, that
> adding it to the wiki would be a great help (even if it is only partial)
>
> On Friday, October 4, 2019 at 4:06:27 AM UTC+1, Gregory Shields wrote:
> >
> > I've really tried, but cannot seem to find the documentation for
> > git-cmd.exe. In particular, I'm interested in the command line switches.
> > Could someone point me to that?
> >
> > Thanks.
> >
>
> You received this message because you are subscribed to the Google Groups "git-for-windows" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to git-for-windo...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/git-for-windows/428d9016-0b99-479e-b8df-58698b1d9059%40googlegroups.com.
>
Philip Oakley
Oct 4, 2019, 10:43:13 AM10/4/19
to Johannes Schindelin, git-for-windows
Hi Dscho,
commitments.
I'm just about to retry building the git.sln using a worktree to see how
the _4_ config file sources affect the test framework for the >4GiB
testing, which should be plenty of foot traps..
On 04/10/2019 14:20, Johannes Schindelin wrote:
> Hi Philip,
>
> On Fri, 4 Oct 2019, Philip Oakley wrote:
>
>> What were you trying to actually switch?
>>
>> IIRC it is just a wrapper to start the cmd window such that git itself can
>> be run with the right paths and directories setup.
> That is partially true. But there is more to it:
>
> - you can override the command to be run. This allows e.g. calling an
> arbitrary command-line program, with all the environment variables set
> up correctly to run _this_ particular Git.
>
> For example, you can use it to call the Git for Windows SDK Bash in a
> CMD window after installing that SDK to C:\git-sdk-64 via
> `C:\git-sdk-64\git-cmd.exe --command=usr\bin\bash.exe -li`
>
> - When allowing `git-cmd` to run the regular CMD "REPL", the `git`
> command is overridden using `doskey` (equivalent to Bash's aliases),
> to avoid picking up any `git.exe` or `git.bat` in the current
> directory.
>
> And that's just two aspects of it.
>
> Ciao,
> Johannes
>
Thanks, I've been falling behind a bit recently with too many other
> Hi Philip,
>
> On Fri, 4 Oct 2019, Philip Oakley wrote:
>
>> What were you trying to actually switch?
>>
>> IIRC it is just a wrapper to start the cmd window such that git itself can
>> be run with the right paths and directories setup.
> That is partially true. But there is more to it:
>
> - you can override the command to be run. This allows e.g. calling an
> arbitrary command-line program, with all the environment variables set
> up correctly to run _this_ particular Git.
>
> For example, you can use it to call the Git for Windows SDK Bash in a
> CMD window after installing that SDK to C:\git-sdk-64 via
> `C:\git-sdk-64\git-cmd.exe --command=usr\bin\bash.exe -li`
>
> - When allowing `git-cmd` to run the regular CMD "REPL", the `git`
> command is overridden using `doskey` (equivalent to Bash's aliases),
> to avoid picking up any `git.exe` or `git.bat` in the current
> directory.
>
> And that's just two aspects of it.
>
> Ciao,
> Johannes
>
commitments.
I'm just about to retry building the git.sln using a worktree to see how
the _4_ config file sources affect the test framework for the >4GiB
testing, which should be plenty of foot traps..
Gregory Shields
Oct 4, 2019, 5:19:46 PM10/4/19
to git-for-windows
Thanks very much, Jonannes. That source code does indeed appear to have what I was asking for.
I'd be happy to participate in updating the documentation, but can you be more explicit about what you're saying? I don't always understand things as well as I probably should, and I don't want to do anything stupid.
Here's what I understand from what you said:
- There's a source file, "git-wrapper.c", which can be used to find out what the command-line options are for "git-cmd.exe".
- There's a Help file, "git.txt", which I believe you're saying would be a good place to add documentation on "git-cmd.exe" command-line options. Or maybe you're just saying to use that file as a guide for styling a new file? This same text resides on my machine as "file:///C:/Git/mingw64/share/doc/git-doc/git.html" and can be viewed in my browser by typing the command "git help git" from Git Bash.
Since you mentioned starting a help page on `git-cmd`, it seems like you may be suggesting that I create a new text file named "git-cmd.txt".
When you say that I should copy-edit "git.txt" next to "git-wrapper.c", I'm not quite sure what you mean by "next to". I'm just trying to grasp exactly what it is I should do.
Finally, when you ask me to provide you with a "git-cmd.exe" based on "git.txt", can you be more explicit about what you are suggesting?
I'm not trying to be pedantic, just attempting to clarify. Also, I do appreciate you offering to take care of the integration, but I wonder whether you would be willing to give me a list of steps so that I could perform that task myself. If that's more hand-holding than you're up for, I totally understand, but I just thought it might be a good way for me to learn how to do it so that I could be more involved in the future.
Thanks again,
Gregory Shields
Johannes Schindelin
Oct 4, 2019, 6:24:53 PM10/4/19
to Gregory Shields, git-for-windows
Hi,
On Fri, 4 Oct 2019, Gregory Shields wrote:
> I'd be happy to participate in updating the documentation, but can you be
> more explicit about what you're saying? I don't always understand things as
> well as I probably should, and I don't want to do anything stupid.
>
> Here's what I understand from what you said:
>
> 1. There's a source file, "git-wrapper.c", which can be used to find out
> Or maybe you're just saying to use that file as a guide for styling a new
> file? This same text resides on my machine as
> "file:///C:/Git/mingw64/share/doc/git-doc/git.html" and can be viewed in my
> browser by typing the command "git help git" from Git Bash.
Yes.
> Since you mentioned starting a help page on `git-cmd`, it seems like you
> may be suggesting that I create a new text file named "git-cmd.txt".
Yes.
> When you say that I should copy-edit "git.txt" next to "git-wrapper.c", I'm
> not quite sure what you mean by "next to". I'm just trying to grasp exactly
> what it is I should do.
The `git-wrapper.c` file is not tracked in
https://github.com/git-for-windows/git, but in
https://github.com/git-for-windows/MINGW-packages, in the subdirectory
`mingw64-w64-git/`. That's where that `git-cmd.txt` should live, too.
And the `mingw-w64-git.mak` file that also lives there may need to be
adjusted to render the HTML for that file. Or maybe it should be copied
to `Documentation/` in the `build` step in `PKGBUILD` before running
`make -C Documentation git-cmd.html` or some such.
> Finally, when you ask me to provide you with a "git-cmd.exe" based on
> "git.txt", can you be more explicit about what you are suggesting?
That was a late-night mess up. I meant `git-cmd.txt`, but my fingers are
so well trained to write `git-cmd.exe` (and my eyes were too tired to
spot it before sending) that it came out completely confusing. My
apologies.
> I'm not trying to be pedantic, just attempting to clarify. Also, I do
> appreciate you offering to take care of the integration, but I wonder
> whether you would be willing to give me a list of steps so that I could
> perform that task myself. If that's more hand-holding than you're up for, I
> totally understand, but I just thought it might be a good way for me to
> learn how to do it so that I could be more involved in the future.
Oh, I am glad for every bit of help you can provide!
To build the thing, it might be best to get the Git for Windows SDK from
https://gitforwindows.org/#download-sdk and install it (beware, this
will take a while). Then you can build the package via `sdk build
mingw-w64-git`.
Once you have an initial build of the package (to prove that it works,
more than anything else), you can `sdk cd mingw-w64-git && cd src/git`
to start playing.
I'd first try to just copy-edit `Documentation/git.txt` and then build
the HTML with `make -C Documentation git-cmd.html`, then looking at the
output using `(cd Documentation && start git-cmd.html)`.
Once you are satisfied with the output, it is time to copy that file
into `/usr/src/MINGW-packages/mingw-w64-git/` and then edit the
`PKGBUILD` file in the same directory: it will need to be added to the
`sources` explicitly, and I think the best place to insert this `cp
../git-cmd.txt Documentation/ && make -C Documentation git-cmd.html`
would be the end of the `build` function (I _think_, use your
judgement).
Then you can see whether a `sdk build mingw-w64-git` produces an
appropripate `*-git-doc-html*.pkg.tar.xz` file (i.e. if it contains the
`git-cmd.html` file). It may not, in which case one of the `package_*()`
functions in the `PKGBUILD` file will need to be enhanced to copy the
file into the correct location within the `$pkgdir/` tree (I type this
from memory, so the exact variable name might be different, again, use
your judgement from reading the surrounding code).
Thanks,
Johannes
>
> Thanks again,
> Gregory Shields
>
> On Friday, October 4, 2019 at 5:08:38 AM UTC-5, Johannes Schindelin wrote:
> >
> > Hi Gregory,
> >
> > On Thu, 3 Oct 2019, Gregory Shields wrote:
> >
> > > I've really tried, but cannot seem to find the documentation for
> > > git-cmd.exe. In particular, I'm interested in the command line switches.
> > > Could someone point me to that?
> >
> > Unfortunately, there isn't any, at the moment. The best thing for now is
> > the source code:
> >
> > https://github.com/git-for-windows/MINGW-packages/blob/737f0ad83b16ee1e9771559bdf8a06ebf2493014/mingw-w64-git/git-wrapper.c#L510-L533
> >
> > You might be interested, though, in starting a help page on `git-cmd`.
> > The best idea would be to copy-edit e.g.
> >
> > https://github.com/git-for-windows/git/blob/v2.23.0.windows.1/Documentation/git.txt
> > next to the `git-wrapper.c` and integrate it into the packaging of the
> > `mingw-w64-git` package.
> >
> > Tell you what, if you provide me with a `git-cmd.exe` based on that
> > `git.txt`, I will take care of the integration?
> >
> > Thanks,
> > Johannes
> >
>
>
On Fri, 4 Oct 2019, Gregory Shields wrote:
> I'd be happy to participate in updating the documentation, but can you be
> more explicit about what you're saying? I don't always understand things as
> well as I probably should, and I don't want to do anything stupid.
>
> Here's what I understand from what you said:
>
> what the command-line options are for "git-cmd.exe".
> 2. There's a Help file, "git.txt", which I believe you're saying would
> be a good place to add documentation on "git-cmd.exe" command-line options.
Not quite.
> Or maybe you're just saying to use that file as a guide for styling a new
> file? This same text resides on my machine as
> "file:///C:/Git/mingw64/share/doc/git-doc/git.html" and can be viewed in my
> browser by typing the command "git help git" from Git Bash.
> Since you mentioned starting a help page on `git-cmd`, it seems like you
> may be suggesting that I create a new text file named "git-cmd.txt".
> When you say that I should copy-edit "git.txt" next to "git-wrapper.c", I'm
> not quite sure what you mean by "next to". I'm just trying to grasp exactly
> what it is I should do.
https://github.com/git-for-windows/git, but in
https://github.com/git-for-windows/MINGW-packages, in the subdirectory
`mingw64-w64-git/`. That's where that `git-cmd.txt` should live, too.
And the `mingw-w64-git.mak` file that also lives there may need to be
adjusted to render the HTML for that file. Or maybe it should be copied
to `Documentation/` in the `build` step in `PKGBUILD` before running
`make -C Documentation git-cmd.html` or some such.
> Finally, when you ask me to provide you with a "git-cmd.exe" based on
> "git.txt", can you be more explicit about what you are suggesting?
so well trained to write `git-cmd.exe` (and my eyes were too tired to
spot it before sending) that it came out completely confusing. My
apologies.
> I'm not trying to be pedantic, just attempting to clarify. Also, I do
> appreciate you offering to take care of the integration, but I wonder
> whether you would be willing to give me a list of steps so that I could
> perform that task myself. If that's more hand-holding than you're up for, I
> totally understand, but I just thought it might be a good way for me to
> learn how to do it so that I could be more involved in the future.
To build the thing, it might be best to get the Git for Windows SDK from
https://gitforwindows.org/#download-sdk and install it (beware, this
will take a while). Then you can build the package via `sdk build
mingw-w64-git`.
Once you have an initial build of the package (to prove that it works,
more than anything else), you can `sdk cd mingw-w64-git && cd src/git`
to start playing.
I'd first try to just copy-edit `Documentation/git.txt` and then build
the HTML with `make -C Documentation git-cmd.html`, then looking at the
output using `(cd Documentation && start git-cmd.html)`.
Once you are satisfied with the output, it is time to copy that file
into `/usr/src/MINGW-packages/mingw-w64-git/` and then edit the
`PKGBUILD` file in the same directory: it will need to be added to the
`sources` explicitly, and I think the best place to insert this `cp
../git-cmd.txt Documentation/ && make -C Documentation git-cmd.html`
would be the end of the `build` function (I _think_, use your
judgement).
Then you can see whether a `sdk build mingw-w64-git` produces an
appropripate `*-git-doc-html*.pkg.tar.xz` file (i.e. if it contains the
`git-cmd.html` file). It may not, in which case one of the `package_*()`
functions in the `PKGBUILD` file will need to be enhanced to copy the
file into the correct location within the `$pkgdir/` tree (I type this
from memory, so the exact variable name might be different, again, use
your judgement from reading the surrounding code).
Thanks,
Johannes
>
> Thanks again,
> Gregory Shields
>
> On Friday, October 4, 2019 at 5:08:38 AM UTC-5, Johannes Schindelin wrote:
> >
> > Hi Gregory,
> >
> > On Thu, 3 Oct 2019, Gregory Shields wrote:
> >
> > > I've really tried, but cannot seem to find the documentation for
> > > git-cmd.exe. In particular, I'm interested in the command line switches.
> > > Could someone point me to that?
> >
> > Unfortunately, there isn't any, at the moment. The best thing for now is
> > the source code:
> >
> > https://github.com/git-for-windows/MINGW-packages/blob/737f0ad83b16ee1e9771559bdf8a06ebf2493014/mingw-w64-git/git-wrapper.c#L510-L533
> >
> > You might be interested, though, in starting a help page on `git-cmd`.
> > The best idea would be to copy-edit e.g.
> >
> > https://github.com/git-for-windows/git/blob/v2.23.0.windows.1/Documentation/git.txt
> > next to the `git-wrapper.c` and integrate it into the packaging of the
> > `mingw-w64-git` package.
> >
> > Tell you what, if you provide me with a `git-cmd.exe` based on that
> > `git.txt`, I will take care of the integration?
> >
> > Thanks,
> > Johannes
> >
>
> --
> You received this message because you are subscribed to the Google Groups "git-for-windows" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to git-for-windo...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/git-for-windows/22f86a84-f245-4c4e-b7e6-d2f08edbe3ef%40googlegroups.com.
> You received this message because you are subscribed to the Google Groups "git-for-windows" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to git-for-windo...@googlegroups.com.
>
Gregory Shields
Oct 6, 2019, 2:01:19 AM10/6/19
to git-for-windows
Johannes:
I downloaded and ran git-sdk-installer-1.0.7-64.7z.exe.
Following the "Technical overview", I ran...
sdk init git
...which finished instantaneously and didn't do anything that I could see.
Maybe I need to navigate to C:\git-sdk-64\usr\src\git first, or something.
I see there's a .git directory and a config.mak file, but no source code.
I ran...
pacman -Syu
...and it said everything was up to date and "there is nothing to do" for both core system and full system upgrade.
However, there were a couple of warnings:
warning: grep: local (3.1-1) is newer than msys (3.0-2)
warning: libgc: local (8.0.0-1) is newer than msys (7.6.8-1)
I suspect those are no big deal.
I looked at the "Building Git" page under "Build Git", which says an initial "git clone" and "make" should have already occurred when running the SDK installer. I do remember seeing the cloning process happening as part of the install, yet as I mentioned above, I find no source code.
It sort of makes sense that there's no source code, though, because the SDK-64 console that popped up at the end of the install process shows the very last thing that happens is four empty repositories being created:
Initialized empty Git repository in C:/git-sdk-64/usr/src/git/.git/
Initialized empty Git repository in C:/git-sdk-64/usr/src/build-extra/.git/
Initialized empty Git repository in C:/git-sdk-64/usr/src/MINGW-packages/.git/
Initialized empty Git repository in C:/git-sdk-64/usr/src/MSYS2-packages/.git/
So just on the face of it, it seems that the installer cloned the repo and then later initialized it to empty. I think I'm confused.
Looking at step 2, I decided to look for "mingw64_shell.bat", but didn't find it, maybe because the source code didn't get downloaded. I do wonder, though, if running that batch file is necessary or how it's any different than just running git-bash.exe.
Well, it seems like I need your help in figuring out where I am and how to proceed. Do I need to explicitly clone the source code?
Thanks,
Gregory Shields
> To unsubscribe from this group and stop receiving emails from it, send an email to git-for...@googlegroups.com.
Philip Oakley
Oct 6, 2019, 8:39:44 AM10/6/19
to git-for-windows
Hi Gregory.
Most of what you say sounds 'normal'. Yes the repos are either bare or just an init.
The sdk commands can feel sparse try the `sdk help` for a litle bit of extra info. IIRC `sdk sd git` should do any fetch updates while changing to the directory.
Or you can simply cd to the directory and do your own fetch/checkout as required.
If you are a Visual Studio user then also look at origin/vs/master which contains a git.sln file. As long as your install options weren't bash-only then it should compile straight away (but does download a few dependencies)
Hope that helps.
Philip
Gregory Shields
Oct 9, 2019, 9:38:19 PM10/9/19
to git-for-windows
Thank you, Philip. I appreciate your guidance.
I actually am a Visual Studio user, so I'll give that a try and report back.
Regards,
Gregory Shields
Philip Oakley
Oct 10, 2019, 5:54:15 AM10/10/19
to Gregory Shields, git-for-windows
Hi Gregory,
I'm just going through a careful 'review' of the compilation process for
the vs/master build, so if you have any feedback on even the smallest
little niggle then that would help.
I believe that when Dscho proved out the initial builds he was using the
install option that is one beyond the 'recommended' (the one with the
warning;-) so that after install all the *nix stuff was available via
the cmd/bash window. (I'd previously kept the bash/mintty separate from
the CMD stuff)
Also I'm doing a compilation is an added worktree, rather than the mani
worktree which has shown some issues I haven't got to the bottom of
(mainly because of the way that the GIT_DIR string is created (mixed
unix/windows parts, from root, so it becomes 'not found').
If you are extending Git with extra commands (such as a test helper)
then there are extra steps needed that currently need the sdk to rebuild
(make) the commandlist.h and then re-'generate' the vcproj .sln file to
include that particular new 'cmd_xxx` version.
However a simple rebuild of the existing master does appear to work
straight out of the tin. Which is good.
Philip
see issue #2352 (and #2351 etc)
> <https://github.com/git-for-windows/build-extra/releases/download/git-sdk-1.0.7/git-sdk-installer-1.0.7-64.7z.exe>.
> <https://github.com/git-for-windows/git>, but in
> https://github.com/git-for-windows/MINGW-packages
> <https://github.com/git-for-windows/MINGW-packages>, in
> <https://groups.google.com/d/msgid/git-for-windows/22f86a84-f245-4c4e-b7e6-d2f08edbe3ef%40googlegroups.com>.
> <mailto:git-for-windo...@googlegroups.com>.
> <https://groups.google.com/d/msgid/git-for-windows/27069881-3a13-44db-abb1-5ef0d79da408%40googlegroups.com?utm_medium=email&utm_source=footer>.
I'm just going through a careful 'review' of the compilation process for
the vs/master build, so if you have any feedback on even the smallest
little niggle then that would help.
I believe that when Dscho proved out the initial builds he was using the
install option that is one beyond the 'recommended' (the one with the
warning;-) so that after install all the *nix stuff was available via
the cmd/bash window. (I'd previously kept the bash/mintty separate from
the CMD stuff)
Also I'm doing a compilation is an added worktree, rather than the mani
worktree which has shown some issues I haven't got to the bottom of
(mainly because of the way that the GIT_DIR string is created (mixed
unix/windows parts, from root, so it becomes 'not found').
If you are extending Git with extra commands (such as a test helper)
then there are extra steps needed that currently need the sdk to rebuild
(make) the commandlist.h and then re-'generate' the vcproj .sln file to
include that particular new 'cmd_xxx` version.
However a simple rebuild of the existing master does appear to work
straight out of the tin. Which is good.
Philip
see issue #2352 (and #2351 etc)
> https://github.com/git-for-windows/MINGW-packages
> <https://github.com/git-for-windows/MINGW-packages>, in
>
> >
>
> --
> You received this message because you are subscribed to the Google
> Groups "git-for-windows" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to git-for-windo...@googlegroups.com
> >
>
> --
> You received this message because you are subscribed to the Google
> Groups "git-for-windows" group.
> To unsubscribe from this group and stop receiving emails from it, send
> <mailto:git-for-windo...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/git-for-windows/27069881-3a13-44db-abb1-5ef0d79da408%40googlegroups.com
> <https://groups.google.com/d/msgid/git-for-windows/27069881-3a13-44db-abb1-5ef0d79da408%40googlegroups.com?utm_medium=email&utm_source=footer>.
Johannes Schindelin
Oct 10, 2019, 8:11:17 AM10/10/19
to Gregory Shields, git-for-windows
Hi Gregory,
If you are confused by anything, and would love to get help, please do
not hesitate to ask for it.
The `sdk` function is defined here:
https://github.com/git-for-windows/build-extra/blob/eaf656f0cc8fdf2e7219299e0ea987dddaa9b1e5/git-extra/git-sdk.sh#L22-L381
(including the text that is printed upon `sdk help`), so all of this is
quite improvable.
Ciao,
Johannes
On Wed, 9 Oct 2019, Gregory Shields wrote:
> Thank you, Philip. I appreciate your guidance.
>
> I actually am a Visual Studio user, so I'll give that a try and report back.
>
> Regards,
> Gregory Shields
>
> On Sunday, October 6, 2019 at 7:39:44 AM UTC-5, Philip Oakley wrote:
> >
> > Hi Gregory.
> >
> > Most of what you say sounds 'normal'. Yes the repos are either bare or
> > just an init.
> >
> > The sdk commands can feel sparse try the `sdk help` for a litle bit of
> > extra info. IIRC `sdk sd git` should do any fetch updates while changing to
> > the directory.
> > Or you can simply cd to the directory and do your own fetch/checkout as
> > required.
> >
> > If you are a Visual Studio user then also look at origin/vs/master which
> > contains a git.sln file. As long as your install options weren't bash-only
> > then it should compile straight away (but does download a few dependencies)
> >
> > Hope that helps.
> >
> > Philip
> >
> > On Sunday, October 6, 2019 at 7:01:19 AM UTC+1, Gregory Shields wrote:
> >>
> >> Johannes:
> >>
> >> I downloaded and ran git-sdk-installer-1.0.7-64.7z.exe
> >> <https://github.com/git-for-windows/build-extra/releases/download/git-sdk-1.0.7/git-sdk-installer-1.0.7-64.7z.exe>
> >> .
> To unsubscribe from this group and stop receiving emails from it, send an email to git-for-windo...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/git-for-windows/27069881-3a13-44db-abb1-5ef0d79da408%40googlegroups.com.
>
If you are confused by anything, and would love to get help, please do
not hesitate to ask for it.
The `sdk` function is defined here:
https://github.com/git-for-windows/build-extra/blob/eaf656f0cc8fdf2e7219299e0ea987dddaa9b1e5/git-extra/git-sdk.sh#L22-L381
(including the text that is printed upon `sdk help`), so all of this is
quite improvable.
Ciao,
Johannes
On Wed, 9 Oct 2019, Gregory Shields wrote:
> Thank you, Philip. I appreciate your guidance.
>
> I actually am a Visual Studio user, so I'll give that a try and report back.
>
> Regards,
> Gregory Shields
>
> On Sunday, October 6, 2019 at 7:39:44 AM UTC-5, Philip Oakley wrote:
> >
> > Hi Gregory.
> >
> > Most of what you say sounds 'normal'. Yes the repos are either bare or
> > just an init.
> >
> > The sdk commands can feel sparse try the `sdk help` for a litle bit of
> > extra info. IIRC `sdk sd git` should do any fetch updates while changing to
> > the directory.
> > Or you can simply cd to the directory and do your own fetch/checkout as
> > required.
> >
> > If you are a Visual Studio user then also look at origin/vs/master which
> > contains a git.sln file. As long as your install options weren't bash-only
> > then it should compile straight away (but does download a few dependencies)
> >
> > Hope that helps.
> >
> > Philip
> >
> > On Sunday, October 6, 2019 at 7:01:19 AM UTC+1, Gregory Shields wrote:
> >>
> >> Johannes:
> >>
> >> I downloaded and ran git-sdk-installer-1.0.7-64.7z.exe
> >> .
> To view this discussion on the web visit https://groups.google.com/d/msgid/git-for-windows/27069881-3a13-44db-abb1-5ef0d79da408%40googlegroups.com.
>
Gregory Shields
Oct 10, 2019, 11:40:09 PM10/10/19
to git-for-windows
Hello, Philip.
I'm just going through a careful 'review' of the compilation process for
the vs/master build, so if you have any feedback on even the smallest
little niggle then that would help.
I had to install the "VC++ 2015.3 v140 toolset (x86,x64)" optional feature. Or at least I believe that's what it was I had to install.
Aside from that, I just have an error dialog that pops up every time I open up the Solution in VS2017 (or VS2019).
I believe that when Dscho proved out the initial builds he was using the
install option that is one beyond the 'recommended' (the one with the
warning;-) so that after install all the *nix stuff was available via
the cmd/bash window. (I'd previously kept the bash/mintty separate from
the CMD stuff)
I don't think I'm understanding really what you mean here.
Also I'm doing a compilation is an added worktree, rather than the mani
worktree which has shown some issues I haven't got to the bottom of
(mainly because of the way that the GIT_DIR string is created (mixed
unix/windows parts, from root, so it becomes 'not found').
I used your idea on this and created a worktree to hold the vs/master branch on my computer.
If you are extending Git with extra commands (such as a test helper)
then there are extra steps needed that currently need the sdk to rebuild
(make) the commandlist.h and then re-'generate' the vcproj .sln file to
include that particular new 'cmd_xxx` version.
If ever I go down that road, I'm sure I'll need help with it.
However a simple rebuild of the existing master does appear to work
straight out of the tin. Which is good.
I did manage to get the Solution to build in VS2017. However, the files I'm interested in at the moment aren't in that branch.
Thanks again.
Gregory Shields
> an email to git-for...@googlegroups.com
> <mailto:git-for-windows+unsub...@googlegroups.com>.
Gregory Shields
Oct 10, 2019, 11:53:07 PM10/10/19
to git-for-windows
Hello, Johannes.
If you are confused by anything, and would love to get help, please do
not hesitate to ask for it.
Well, when I installed the SDK, I was able to get the files for the repositories contained in C:\git-sdk-64\usr\src. However, I'm quite sure that I won't be able to push changes directly to origin on those. Therefore, it seems to me that those local repos in C:\git-sdk-64\usr\src won't be of much use. I mean wouldn't I rather need to fork them and clone my forks to my computer and do pull requests from that?
Maybe you can help me understand the intent of creating the repos under C:\git-sdk-64\usr\src.
The `sdk` function is defined here:
https://github.com/git-for-windows/build-extra/blob/eaf656f0cc8fdf2e7219299e0ea987dddaa9b1e5/git-extra/git-sdk.sh#L22-L381
(including the text that is printed upon `sdk help`), so all of this is
quite improvable.
Yeah, I wasn't able to make any of those work, although it's probably because I don't know what I'm doing.
Thanks,
Gregory Shields
> To view this discussion on the web visit https://groups.google.com/d/msgid/git-for-windows/27069881-3a13-44db-abb1-5ef0d79da408%40googlegroups.com.
>
Philip Oakley
Oct 11, 2019, 7:04:30 AM10/11/19
to Gregory Shields, git-for-windows
Hi Gregory,
0. I trimmed all the trailing tat. On the main (upstream) git list they
don't use top posting because of that...
1. I vaguely have a recollection of a dialog like that. I think it was
when I started VS a 2nd time (so had two running) for the same .sln. In
that (half remembered) case, I simply closed the new VS instance and
went beck to the old prior instance, which had detected the code update,
and reloaded the project and everything ran fine after that.
2. bas/cmd install 'issues'. During regular install you are given 3
options for mixing bash (unix terminal) with CMD (Window terminal). The
bash only install means that the VS compilation (git.exe) isn't seen so
ugh. The bash in cmd ("recommended") option updates the path so that the
compiled git.exe is seen (nice). While the third option (scary
'warning') means that not only is the compiled git seen from cmd, but
also the unix commands such as 'less' and 'sh', so everything works,
except when there is name collision for a command (such as IIRC 'find' -
see warning). IIUC this last option gives the smoothest operation and
testing, as long as you don't fall into those command collision traps.
3. Using a worktree. hmm. at the moment, because I was testing with the
'recommended' install, there were issues with using the worktree
approach for having the VS version 'to the side' of the regular git
worktree checkout of you main branch. You may find that during your
initial tests that it's easiest to just checkout into the main worktree.
[But..]
4. if the files you are interest in are not in the current upstream
(git) master, then you can do a tweak of checking out shears/next or
shears/pu (which follow the upstream), and then cherry pick the last
commit from vs/master which should simply add the .sln file (or any of
the other 'dubious' ways of copying that file ;-). You should have that
.sln that compiles, and the updated files that match that 'solution'.
4b. if you have 'added' a command to the solution then a little more is
needed, either locally modify the VS project solution properties to
include it, or leap through the sdk hoops to use the scripts that
'make's the command list and then re-generate the .sln file (the VS
properties route maybe easier if you know your way around that).
5. Great that you managed to compile. the simplest test is to run `git
version` and see it it has the `.MSVC` appended to the version string.
C:\Users\phili>cd \git-sdk-64\usr\src\VisualStudioGit
C:\git-sdk-64\usr\src\VisualStudioGit>git version
git version 2.23.0.windows.1.33.g1541e3db21.MSVC
Hope that helps clarify some points.
On 11/10/2019 04:40, Gregory Shields wrote:
> Hello, Philip.
>
> I'm just going through a careful 'review' of the compilation
> process for
> the vs/master build, so if you have any feedback on even the smallest
> little niggle then that would help.
>
> I had to install the "VC++ 2015.3 v140 toolset (x86,x64)" optional
> feature. Or at least I believe that's what it was I had to install.
> Aside from that, I just have an error dialog that pops up every time I
> open up the Solution in VS2017 (or VS2019).
>
> <http://gregoryshields.net/Junk/IntelliCodeCppPackage.png>
[snip!]
0. I trimmed all the trailing tat. On the main (upstream) git list they
don't use top posting because of that...
1. I vaguely have a recollection of a dialog like that. I think it was
when I started VS a 2nd time (so had two running) for the same .sln. In
that (half remembered) case, I simply closed the new VS instance and
went beck to the old prior instance, which had detected the code update,
and reloaded the project and everything ran fine after that.
2. bas/cmd install 'issues'. During regular install you are given 3
options for mixing bash (unix terminal) with CMD (Window terminal). The
bash only install means that the VS compilation (git.exe) isn't seen so
ugh. The bash in cmd ("recommended") option updates the path so that the
compiled git.exe is seen (nice). While the third option (scary
'warning') means that not only is the compiled git seen from cmd, but
also the unix commands such as 'less' and 'sh', so everything works,
except when there is name collision for a command (such as IIRC 'find' -
see warning). IIUC this last option gives the smoothest operation and
testing, as long as you don't fall into those command collision traps.
3. Using a worktree. hmm. at the moment, because I was testing with the
'recommended' install, there were issues with using the worktree
approach for having the VS version 'to the side' of the regular git
worktree checkout of you main branch. You may find that during your
initial tests that it's easiest to just checkout into the main worktree.
[But..]
4. if the files you are interest in are not in the current upstream
(git) master, then you can do a tweak of checking out shears/next or
shears/pu (which follow the upstream), and then cherry pick the last
commit from vs/master which should simply add the .sln file (or any of
the other 'dubious' ways of copying that file ;-). You should have that
.sln that compiles, and the updated files that match that 'solution'.
4b. if you have 'added' a command to the solution then a little more is
needed, either locally modify the VS project solution properties to
include it, or leap through the sdk hoops to use the scripts that
'make's the command list and then re-generate the .sln file (the VS
properties route maybe easier if you know your way around that).
5. Great that you managed to compile. the simplest test is to run `git
version` and see it it has the `.MSVC` appended to the version string.
C:\Users\phili>cd \git-sdk-64\usr\src\VisualStudioGit
C:\git-sdk-64\usr\src\VisualStudioGit>git version
git version 2.23.0.windows.1.33.g1541e3db21.MSVC
Hope that helps clarify some points.
On 11/10/2019 04:40, Gregory Shields wrote:
> Hello, Philip.
>
> I'm just going through a careful 'review' of the compilation
> process for
> the vs/master build, so if you have any feedback on even the smallest
> little niggle then that would help.
>
> I had to install the "VC++ 2015.3 v140 toolset (x86,x64)" optional
> feature. Or at least I believe that's what it was I had to install.
> Aside from that, I just have an error dialog that pops up every time I
> open up the Solution in VS2017 (or VS2019).
>
Philip Oakley
Oct 11, 2019, 10:18:32 AM10/11/19
to Gregory Shields, git-for-windows
Hi Gregory,
To answer some of the questions for Johannes (who do almost all the hard
work..)
1a. We use the C:\git-sdk-64\usr\src location convention to avoid
spaces in top directory names and to more readily match *nix conventions
below.
1b. You should set up your push configurations for your branches, such
as `branch.<name>.pushRemote` so that you will fetch from the expected
upstream, but push any changes you made back to your own remote.
However, it's even better if you create your own branch on top of that
fetched local branch, so you don't have that confusion about ownership
of contributions.
That is, each branch can set up it's own source and destinations for
fetch, pull(merge), and push options.
2. you should have both your local repository, and a fork on the hosting
platform of your choice. Thus you end up with three repositories, one
local, and two remote, with one of the remotes being your 'upstream'
(reference) repository, and the other being your personal 'publishing'
repository (that term is only mentioned twice in the docs, but let's use
it).
Your publishing repo is the place where you are able to save backups
(i.e. simple push copies) and also show work to others (if you tell them
the 'good' branch). It also allows you to create Pull Requests that folk
can pull from or your hoster can integrate the PR as well.
3. the sdk functions are just a script that helps automate a few
commands you can do manually. Use dscho's link to help with the manual
commands until you grok what they do.
Hope that helps.
Philip
On 11/10/2019 04:53, Gregory Shields wrote:
> Hello, Johannes.
>
> If you are confused by anything, and would love to get help,
> please do
> not hesitate to ask for it.
>
> Well, when I installed the SDK, I was able to get the files for the
> repositories contained in C:\git-sdk-64\usr\src. However, I'm quite
> sure that I won't be able to push changes directly to origin on those.
> Therefore, it seems to me that those local repos
> in C:\git-sdk-64\usr\src won't be of much use. I mean wouldn't I
> rather need to fork them and clone my forks to my computer and do pull
> requests from that?
>
> Maybe you can help me understand the intent of creating the repos
> under C:\git-sdk-64\usr\src.
>
> The `sdk` function is defined here:
> https://github.com/git-for-windows/build-extra/blob/eaf656f0cc8fdf2e7219299e0ea987dddaa9b1e5/git-extra/git-sdk.sh#L22-L381
> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fgit-for-windows%2Fbuild-extra%2Fblob%2Feaf656f0cc8fdf2e7219299e0ea987dddaa9b1e5%2Fgit-extra%2Fgit-sdk.sh%23L22-L381&sa=D&sntz=1&usg=AFQjCNHSrn8fPd9z7keO1gH9SUF7JLNLBw>
To answer some of the questions for Johannes (who do almost all the hard
work..)
1a. We use the C:\git-sdk-64\usr\src location convention to avoid
spaces in top directory names and to more readily match *nix conventions
below.
1b. You should set up your push configurations for your branches, such
as `branch.<name>.pushRemote` so that you will fetch from the expected
upstream, but push any changes you made back to your own remote.
However, it's even better if you create your own branch on top of that
fetched local branch, so you don't have that confusion about ownership
of contributions.
That is, each branch can set up it's own source and destinations for
fetch, pull(merge), and push options.
2. you should have both your local repository, and a fork on the hosting
platform of your choice. Thus you end up with three repositories, one
local, and two remote, with one of the remotes being your 'upstream'
(reference) repository, and the other being your personal 'publishing'
repository (that term is only mentioned twice in the docs, but let's use
it).
Your publishing repo is the place where you are able to save backups
(i.e. simple push copies) and also show work to others (if you tell them
the 'good' branch). It also allows you to create Pull Requests that folk
can pull from or your hoster can integrate the PR as well.
3. the sdk functions are just a script that helps automate a few
commands you can do manually. Use dscho's link to help with the manual
commands until you grok what they do.
Hope that helps.
Philip
On 11/10/2019 04:53, Gregory Shields wrote:
> Hello, Johannes.
>
> If you are confused by anything, and would love to get help,
> please do
> not hesitate to ask for it.
>
> Well, when I installed the SDK, I was able to get the files for the
> repositories contained in C:\git-sdk-64\usr\src. However, I'm quite
> sure that I won't be able to push changes directly to origin on those.
> Therefore, it seems to me that those local repos
> in C:\git-sdk-64\usr\src won't be of much use. I mean wouldn't I
> rather need to fork them and clone my forks to my computer and do pull
> requests from that?
>
> Maybe you can help me understand the intent of creating the repos
> under C:\git-sdk-64\usr\src.
>
> The `sdk` function is defined here:
> https://github.com/git-for-windows/build-extra/blob/eaf656f0cc8fdf2e7219299e0ea987dddaa9b1e5/git-extra/git-sdk.sh#L22-L381
>
> (including the text that is printed upon `sdk help`), so all of
> this is
> quite improvable.
>
> Yeah, I wasn't able to make any of those work, although it's probably
> because I don't know what I'm doing.
>
> Thanks,
> Gregory Shields
>
> Ciao,
> Johannes
>
[snip]
> (including the text that is printed upon `sdk help`), so all of
> this is
> quite improvable.
>
> Yeah, I wasn't able to make any of those work, although it's probably
> because I don't know what I'm doing.
>
> Thanks,
> Gregory Shields
>
> Ciao,
> Johannes
>
Johannes Schindelin
Oct 11, 2019, 4:20:08 PM10/11/19
to Gregory Shields, git-for-windows
Hi,
On Thu, 10 Oct 2019, Gregory Shields wrote:
> If you are confused by anything, and would love to get help, please do
> > not hesitate to ask for it.
> >
> Well, when I installed the SDK, I was able to get the files for the
> repositories contained in C:\git-sdk-64\usr\src. However, I'm quite sure
> that I won't be able to push changes directly to origin on those.
> Therefore, it seems to me that those local repos in C:\git-sdk-64\usr\src
> won't be of much use. I mean wouldn't I rather need to fork them and clone
> my forks to my computer and do pull requests from that?
But that's totally possible, you can fork the repositories on GitHub and
then add a remote (but not `origin`) for those.
> Maybe you can help me understand the intent of creating the repos
> under C:\git-sdk-64\usr\src.
It seemed a good idea at the time, and I've had no reason to change this
;-)
> The `sdk` function is defined here:
> >
> > https://github.com/git-for-windows/build-extra/blob/eaf656f0cc8fdf2e7219299e0ea987dddaa9b1e5/git-extra/git-sdk.sh#L22-L381
> > <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fgit-for-windows%2Fbuild-extra%2Fblob%2Feaf656f0cc8fdf2e7219299e0ea987dddaa9b1e5%2Fgit-extra%2Fgit-sdk.sh%23L22-L381&sa=D&sntz=1&usg=AFQjCNHSrn8fPd9z7keO1gH9SUF7JLNLBw>
work (i.e. show logs)?
Ciao,
Johannes
> > an email to git-for...@googlegroups.com <javascript:>.
> To view this discussion on the web visit https://groups.google.com/d/msgid/git-for-windows/e3bc6bd9-cd60-44c5-9371-95ca146b1d88%40googlegroups.com.
>
On Thu, 10 Oct 2019, Gregory Shields wrote:
> If you are confused by anything, and would love to get help, please do
> > not hesitate to ask for it.
> >
> Well, when I installed the SDK, I was able to get the files for the
> repositories contained in C:\git-sdk-64\usr\src. However, I'm quite sure
> that I won't be able to push changes directly to origin on those.
> Therefore, it seems to me that those local repos in C:\git-sdk-64\usr\src
> won't be of much use. I mean wouldn't I rather need to fork them and clone
> my forks to my computer and do pull requests from that?
then add a remote (but not `origin`) for those.
> Maybe you can help me understand the intent of creating the repos
> under C:\git-sdk-64\usr\src.
;-)
> The `sdk` function is defined here:
> >
> > https://github.com/git-for-windows/build-extra/blob/eaf656f0cc8fdf2e7219299e0ea987dddaa9b1e5/git-extra/git-sdk.sh#L22-L381
> > (including the text that is printed upon `sdk help`), so all of this is
> > quite improvable.
> >
> Yeah, I wasn't able to make any of those work, although it's probably
> because I don't know what I'm doing.
Maybe you can be more specific what did not work, and _how_ it didn't
> > quite improvable.
> >
> Yeah, I wasn't able to make any of those work, although it's probably
> because I don't know what I'm doing.
work (i.e. show logs)?
Ciao,
Johannes
> > > To view this discussion on the web visit
> > https://groups.google.com/d/msgid/git-for-windows/27069881-3a13-44db-abb1-5ef0d79da408%40googlegroups.com.
> >
> > >
> >
>
> > https://groups.google.com/d/msgid/git-for-windows/27069881-3a13-44db-abb1-5ef0d79da408%40googlegroups.com.
> >
> > >
> >
>
> --
> You received this message because you are subscribed to the Google Groups "git-for-windows" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to git-for-windo...@googlegroups.com.
> You received this message because you are subscribed to the Google Groups "git-for-windows" group.
> To view this discussion on the web visit https://groups.google.com/d/msgid/git-for-windows/e3bc6bd9-cd60-44c5-9371-95ca146b1d88%40googlegroups.com.
>
Reply all
Reply to author
Forward
0 new messages