Skip to content

Document how to build (and test) Git for Windows #3297

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jun 26, 2021

Conversation

dscho
Copy link
Member

@dscho dscho commented Jun 25, 2021

This adds a section in the README.md file, documenting the advice I gave privately to a few colleagues over the past few days (which made me realize that this institutionalized knowledge lives in only one brain so far, and this PR changes that).

@dscho dscho force-pushed the docs-about-testing-git-in-place branch 2 times, most recently from 49d647e to c7f4363 Compare June 25, 2021 15:00
@jeffhostetler
Copy link

Historically, I use a different method that what you've listed here. (Guess
I should have asked about this years ago. 😄 )

I prepend the worktree root to my PATH or use ./git.exe to run the command.

Then I always add --exec-path=/c/<worktree>/ to my command lines. (Tedious,
yes, but I didn't know about GIT_EXEC_PATH until you mentioned it yesterday.)
However, this method is better for debugging in VS because I can just type the
exec-path arg along with the command line that I'm testing/debugging and not
worry about the environment that VS inherited.

Maybe add this usage as another choice?

@jeffhostetler
Copy link

One more case. When building core Git (instead of GFW), is there a preferred solution?

@jeffhostetler
Copy link

Hey, I forgot to say it earlier. Thanks for taking time to do this!!! I think it will be very helpful to help new folks get started.

@derrickstolee
Copy link

I prepend the worktree root to my PATH or use ./git.exe to run the command.

Then I always add --exec-path=/c/<worktree>/ to my command lines. (Tedious,
yes, but I didn't know about GIT_EXEC_PATH until you mentioned it yesterday.)
However, this method is better for debugging in VS because I can just type the
exec-path arg along with the command line that I'm testing/debugging and not
worry about the environment that VS inherited.

This has definitely been my approach before. It is insufficient for testing with the Scalar functional tests (unless I go edit the functional tests to point to that specific version of git.exe and also add the --exec-path to the C# code that calls Git). Other third-party tools shelling to Git will be harder to modify.

Add a section instructing developers how to build, and how to test the
just-built executables in-place.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@dscho
Copy link
Member Author

dscho commented Jun 25, 2021

Historically, I use a different method that what you've listed here. (Guess
I should have asked about this years ago. 😄 )

:-)

I prepend the worktree root to my PATH or use ./git.exe to run the command.

How does this even work, given that this is missing all the .dll files required by git.exe to run? I guess you hard-linked (or copied) the respective .dll files?

When building core Git (instead of GFW), is there a preferred solution?

The easiest is what I would suggest as preferred solution, and I tried to order the options from easy to hard (in my very own judgemental way).

@dscho dscho force-pushed the docs-about-testing-git-in-place branch from c7f4363 to 2f88978 Compare June 25, 2021 21:27
@dscho
Copy link
Member Author

dscho commented Jun 25, 2021

@jeffhostetler @derrickstolee I force-pushed. Could you give this another look-over?

@jeffhostetler
Copy link

This looks good! Thanks for doing this!

@dscho dscho merged commit f1590a7 into git-for-windows:main Jun 26, 2021
@dscho dscho deleted the docs-about-testing-git-in-place branch June 26, 2021 20:27
@dscho dscho added this to the Next release milestone Jun 28, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants