fix(forge): init a git repo at root during init unless explicitely stated #9695
Conversation
0xvv
force-pushed
the
fix-git-submodules
branch
2 times, most recently
from
4f7dba2 to
739b81a
Compare
0xvv
force-pushed
the
fix-git-submodules
branch
from
739b81a to
19cd229
Compare
0xvv
requested review from
DaniPopes,
klkvr,
mattsse,
grandizzy,
yash-atreya and
zerosnacks
as code owners
|
I am not sure I like the way git submodules is desired to be used in #3962 (could become beefy and hard to maintain) but rather have different projects / deps with their own foundry.toml file and submodules. @zerosnacks @yash-atreya wdyt? |
|
I'm supportive of this change, I too would expect that when I run Only suggestion I would have is changing the flag name to cc @yash-atreya do you see any issues on how this may interfere with your recent PRs? |
| // submodules are registered at root | ||
| let gitmodules = root.join(".gitmodules"); | ||
| let gitmodules = fs::read_to_string(gitmodules).unwrap(); | ||
| assert!(gitmodules.contains( | ||
| " | ||
| path = foundry-folder/lib/forge-std | ||
| url = https://github.com/foundry-rs/forge-std | ||
| " | ||
| )); | ||
| }); | ||
|
|
There was a problem hiding this comment.
I'm not sure how this fixes #3962 since the top-level .gitmodules file is still being modified even though you've created a subfolder in which the project resides, i.e., the foundry folder.
The core issue here concerns how git submodules work and how .gitmodules must always be at the git root. Not sure if this is feasible since it would break git submodule command that keeps the .gitmodules file updated and always assumes it's at the root-level.
See: https://git-scm.com/docs/gitsubmodules and https://git-scm.com/docs/gitmodules.
Maybe I'm missing something.
There was a problem hiding this comment.
@0xvv did you get the chance to take a look at this? ^^
There was a problem hiding this comment.
@yash-atreya I think I don't understand your point.
I changed the default behavior to not modify the parent .gitmodules, which is the behavior in other comparable tools and fixes #3962. The .gitmodules thus resides at the root of the newly created forge repo with the new dependencies as expected even if already contained in a git repository. The newly created forge repo can then become a module of the parent git repo.
And I added the option to use an existing parent repo and .gitmodules if we are already in a git repository. Again the modules are declared at the root of the repository that contains the forge, it's just n levels above the forge folder. This is the existing behavior which I think we should move away from as a more modular approach seems better suited to me here but I left it as an option for flexibility and legacy behavior support.
I don't think this would prevent anything regarding submodules management because either way you would be at the root of the git repository.
Let me know if I'm missing anything
|
@0xvv bump on the previous comment, please flag if you're stuck or need any support from us. |
Motivation
Fixes: #3962
Solution
Force initialization of a git repo at the root of the foundry folder unless there already is one or the flag
--use-parent-gitis present and there is indeed a parent git repo.The
--use-parent-gitflag replicates the current behavior in case some people prefer it.Tested the reproductions steps of the issue after to be sure.
The fix in
forge initleads to the expected behavior forforge install