Skip to content
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

Creates a git repo without being asked #69

Open
bates64 opened this issue Jan 31, 2024 · 14 comments
Open

Creates a git repo without being asked #69

bates64 opened this issue Jan 31, 2024 · 14 comments

Comments

@bates64
Copy link

bates64 commented Jan 31, 2024

I have a libdragon project as a subdirectory of a repo. libdragon make runs git init automatically, but I don't want it to because this would exclude it from the wider project.

The git submodule is handled at ../.gitmodules. This program should detect that it's already in a repo and not create a new one.

@anacierdem
Copy link
Owner

anacierdem commented Feb 8, 2024

First of all I agree that the tool should not unnecessarily try to initialize git, this is something I also want to get rid of as well. The core reason it needs git initialized is b/c we use .git folder to cache the current container id. If it does not exist, we need to do a roundtrip to docker cli.

I have tested this with a submodule and my experience is not the same as yours, Even though there are some rough corners, it does not initialize a secondary git tree. This is how I test this:

  • Create a new git repo
  • Add a submodule with git submodule add <other-repo>
  • Enter the submodule via cd other-repo
  • Run libdragon init

It does indeed runs git init but this is a noop inside a submodule and does not change anything. In the end there isn't a .git folder where the tool expects but it realizes this and just continues with a container search. This is the part where the tool should auto detect the correct git root, but this is unrelated to your issue.

Another case that you might have encountered is when you have a git repository, you create a subdirectory and try to initialize libdragon in it. In that case, git root is used to initialize the libdragon project. I agree that this is not the best behavior.

In any case, it does not create an unnecessary git tree and behind the scenes, it uses git rev-parse --show-toplevel to decide where to initialize a libdragon project.

I still plan to remove/change those git inits but if you can explain your use case better, maybe we can find a better alternative?

Edit: you can totally opt out of git init by providing a manual vendor strategy. Git is only necessary to manage libdragon vendoring and when you manage the libdragon files yourself, it is not needed.

@bates64
Copy link
Author

bates64 commented Feb 9, 2024

Thanks for the detailed response!

Your reproduction is a little different to mine. In my case I'm not initialising the subdirectory as a submodule, as I want it to be part of the wider git repo instead. But I do want libdragon as a submodule of the wider git repo.

Another case that you might have encountered is when you have a git repository, you create a subdirectory and try to initialize libdragon in it. In that case, git root is used to initialize the libdragon project. I agree that this is not the best behavior.

Yes, this is what I'm doing. libdragon init does seem to create an unnecessary git tree inside the subdirectory though...

you can totally opt out of git init by providing a manual vendor strategy.

I think this may be what I want. Is it a thing?

My use case is I'm working on a library where I want to provide an examples/with-libdragon/ directory that shows how to use my library with libdragon. I also intend to have an examples/with-libultra/. So I'd like to initialise and use libdragon inside that directory without examples/with-libdragon/ being its own git tree.

@anacierdem
Copy link
Owner

anacierdem commented Feb 9, 2024

Thank you for using the tool as well! More so for opening an issue 👍

libdragon init does seem to create an unnecessary git tree inside the subdirectory though...

Maybe we are not talking about the same thing here... With an "additional git tree", I was trying to emphasize that it won't create a secondary git database independent of the one it resides in, it will just attach to the one higher in the directory tree. But for sure it needs its own git tree for fetching the libdragon files. It should be possible to do it without attaching to git, but it would also mean loosing other functionality like auto-update and such.

I don't think manual vendoring matches your use case either. Let me try to explain on your directory structure:

root (this is a git root as well if I understand correctly?)
-- examples
---- with-libdragon
---- with-libultra

When you do a libdragon init inside, say in with-libdragon, it will create the following structure:

root (this is still the git root)
-- .libdragon (cli housekeeping)
-- libdragon (this will be a git submodule for the root git by default)
---- (here lives the vendored files)
-- examples
---- with-libdragon
---- with-libultra

Actually, it would look the same wherever you run libdragon init inside this tree.

So I'd like to initialise and use libdragon inside that directory without examples/with-libdragon/ being its own git tree.

it is not, but ./libdragon is. If this is not a problem for you, your setup should just work. Otherwise, I need to understand your concern better :)

Edit:

Can you write:

  • your exact steps
  • your resulting structure
  • your expected structure

so that we can work it out.

@anacierdem
Copy link
Owner

anacierdem commented Feb 9, 2024

@bates64 I think I get what you mean now, my above example is incomplete and it would also create another git db inside the folder you do libdragon init. I will try it and let you know 👍🏼

Actually, it would look the same wherever you run libdragon init inside this tree.

This is also probably incorrect.

@anacierdem
Copy link
Owner

@bates64 I tested it again with your setup, it works exactly like I initially thought, no extra git db. So I still need:

  • your exact steps
  • your resulting structure
  • your expected structure

@bates64
Copy link
Author

bates64 commented Feb 13, 2024

Of course. For various reasons the repo that I'm doing this in needs to be private so I'll invite you to a private repo

@bates64
Copy link
Author

bates64 commented Feb 13, 2024

In the repo:

cd examples/hello-world-libdragon
pnpm install
pnpm libdragon init

This writes examples/hello-world-libdragon/.gitmodules, which is unexpected, as .gitmodules already exists at the repo root. Additionally, it does git init (creates examples/hello-world-libdragon/.git) which I don't want either. I'd expect this command not to do anything since the submodule is already initialised and we are already in a git tree (at ../../).

FWIW here's the log

$ pnpm libdragon init 
Initializing a libdragon project at /path/to/examples/hello-world-libdragon
/path/to/examples/hello-world-libdragon/.libdragon exists. This is already a libdragon project, starting it...
Creating new container...
Successfully initialized docker container: /nifty_noether
Initialized empty Git repository in /path/to/examples/hello-world-libdragon/.git/
error: pathspec 'libdragon' did not match any file(s) known to git
Adding existing repo at 'libdragon' to the index
Installing libdragon to the container..

pnpm build (pnpm libdragon make) appears to exhibit similar bad behaviour.

@anacierdem
Copy link
Owner

This is all expected behavior. Let me try to explain:

This writes examples/hello-world-libdragon/.gitmodules, which is unexpected, as .gitmodules already exists at the repo root.

libdragon cli creates a submodule by default as documented in libdragon help init. Especially read the description of --strategy flag. For nested submodules, additional .gitmodules is expected. It is the way git encodes submodule information like the repository and branch. I originally thought it was creating an unnecessary .git folder.

Additionally, it does git init (creates examples/hello-world-libdragon/.git) which I don't want either.

This is also expected and well documented. Again, the default --strategy is submodule and it does require a git project to be able to do that. A git init is a safe operation and makes sure we have the git setup in place. Note that .git is not a folder in that case but references the super project.

(pnpm libdragon make) appears to exhibit similar bad behaviour.

libdragon make does not initialize git unless you run it in a non-libdragon project (i.e not initialized properly). This is also well documented in libdragon help make as:

Must be run in an initialized libdragon project.

If you run it in a non-libdragon project, it will just error out (unless you are using an old version, which attempted a libdragon init - output of libdragon version will help us with that)

I think in your use case, because you don't want the cli to do any git operations, you should simply run:

libdragon init --strategy=manual

and provide libdragon files yourself. You can point at them via --directory=<path to files>.

@bates64
Copy link
Author

bates64 commented Feb 13, 2024

Interesting, okay. I think there was confusion because

It is the way git encodes submodule information like the repository and branch. I originally thought it was creating an unnecessary .git folder.

there is a .gitmodules, just at the repo root ../../.gitmodules.

I'll try out the manual strategy and see how it fares, thank you.

@bates64
Copy link
Author

bates64 commented Feb 13, 2024

OK, cool, that works!

@bates64 bates64 closed this as completed Feb 13, 2024
@bates64
Copy link
Author

bates64 commented Feb 13, 2024

I maintain that the behaviour of the submodule strategy in this case is unexpected/wrong but given this solves my problem there's no issue 😄
Thanks for all the help.

@anacierdem
Copy link
Owner

@bates64 So would you expect the libdragon submodule to be registered on your parent project then, is that correct?

bates64 added a commit to bates64/hotload that referenced this issue Feb 15, 2024
@bates64
Copy link
Author

bates64 commented Feb 15, 2024

That's right, yeah. I'd expect a ../../.gitmodules like

[submodule "examples/hello-world-libdragon/libdragon"]
	path = examples/hello-world-libdragon/libdragon
	url = https://github.com/DragonMinded/libdragon
	branch = trunk

@anacierdem
Copy link
Owner

anacierdem commented Feb 15, 2024

I did a few more tests and I think I have found the exact way you use the tool, I haven't realized that you had an npm root at examples/hello-world-libdragon. That explains why I wasn't able to reproduce your state. In that case it definitely causes a secondary git init in there. If you didn't have an npm root there, you would see the project being initialized at your git root without any additional git trees. I don't exactly know why you initialize npm in examples/hello-world-libdragon but without that npm root, you'd see the libdragon files in your git root, which is still not what you'd want.

I think we might need all or some of the following for a better experience:

  • A mechanism to force the current directory to be a libdragon root so that you wouldn't need that npm root (which is an obscure feature - a relic from the past)
  • Even if it attaches to an npm root, it can still look for a git root to register the submodule to.

@anacierdem anacierdem reopened this Feb 15, 2024
anacierdem added a commit that referenced this issue Feb 16, 2024
The tool depends on git for managing the vendored libdragon copy. It used to run `git init` to make
sure there is a git repos initialized. This works if the p;roject root matched the git troot. This
was mostly the case but when there is an NPM root we were attaching to it to be npm project
compatible and if that root didin't match the git root, this was cresulting in an extra git root.

re #69
github-actions bot pushed a commit that referenced this issue Feb 16, 2024
## [11.0.3](v11.0.2...v11.0.3) (2024-02-16)

### Bug Fixes

* **init.js:** do not run git init unnecessarily ([0a5688f](0a5688f)), closes [#69](#69)
github-actions bot pushed a commit that referenced this issue Feb 17, 2024
## [11.0.3-beta.1](v11.0.2...v11.0.3-beta.1) (2024-02-17)

### Bug Fixes

* **init.js:** do not run git init unnecessarily ([0a5688f](0a5688f)), closes [#69](#69)
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

No branches or pull requests

2 participants