Supporting a custom path for the root .gitignore?

[wmstack]

Maintainer note: This discussion is really about providing ways to use platform specific storage locations for global git configuration.
See this comment to start.

---

It would be nice if instead of having to put a .gitignore in the root of a repository, we could put it somewhere else like cfg/git/ignore or .config/git/ignore instead. I kind of support that movement at nodejs/tooling#79, which aims to move a lot of the tooling to separate files. The issue is that if you don't like to use a tool, you can always avoid it, it is your choice. However, git is different. It is ubiquitous.

This flag would only be possible for the root .gitignore file. Why? The .gitignore file has a . at the start because it is not important enough to be visible, so it would better be put in a separate directory.

I know that git allows multiple .gitignore files in different subdirectories all over the code base, I don't mind that, most people don't have multiple .gitignore files.

The idea is just for the .gitignore file that is responsible for the root, to have a flag that lets gitoxide look somewhere else for the file.

[Byron]

I think you can do this today with ln -s .gitignore cfg/git/ignore. That way it's visible where you want while also being picked up by git in just the right place.

Note that gitoxide would not implement anything that wouldn't work in git unless it's clearly a bug on the side of git.

[Byron]

But according to the README, gitoxide does not intend to replicate git functionality perfectly.

This means there is no need to expose every feature of git no matter how obscure. If you find an indicating that gitoxide is willing to change file formats or do anything that would yield different results than git please let me know as there should be no ambiguity.

Supporting a custom location for .gitignore through the cli wouldn't break any existing codebase.

No, but it would break expectations as the custom location won't be picked up for people who use git on the repo, and ignore files would show up to easily be added to the repository whether intentionally or accidentally.

On glancing through the README, I see a lot of ideas that would be quite new, and that can't be done in git.

This ideas will not change the way basic git features work, and I consider excludes to be part of these basics. Building new tools and workflows on top of git is no problem - these are only available through custom binaries anyway and nobody expects git to be able to handle those.

I also want to mention that Cargo itself supports a flag --manifest-path to move theCargo.toml, and I feel like it is a good design to not hardcode those paths.

gitoxide supports adjusting the filename as it's something git itself supports internally. It doesn't seem to expose this on the command-line yet though. These means application authors can write tools that use these files differently. With the API provided in gitoxide it's straightforward to register 'global' ignore files which can exist in other locations if plumbing crates are used directly.
It's nothing, however, that git-repository exposes, so gitoxide provided tools will naturally not be able to do special things like that.
If there is demand it should be possible though to provide more open git-repository APIs for users to do these kinds of things, even though gix will never make use of it.

[wmstack]

If it breaks expectation for other users, it would only break expectations for developers that have intended that to begin with. As long as the developer says, do this, the user would remain happy. However, you know what breaks expectations? When you have to keep a .gitignore in the root of your filesystem, when every other app respects that your home directory is not a garbage bin for dotfiles. When every other app respects Microsoft's guidelines for local appdata locations.

Yes, there is a .vscode directory, but the Vscode Team is planning to remove it. The .config directory is for those linux-y apps (Scoop) that audaciously think that Windows adheres to the xdg_spec when it doesn't. See that .gitconfig file? A 120 people on stackoverflow would love it to be removed.

Point is, Git is not one to be emulatable in terms of configuration files or cross-platform portability. People that change the location of the .gitignore, it is there responsibility when it breaks expectation.

[Byron]

If it breaks expectation for other users, it would only break expectations for developers that have intended that to begin with. As long as the developer says, do this, the user would remain happy.

Agreed, that makes sense. From the perspective of 'gitoxide should support writing applications' it should provide some customizability beyond what git does, and I suppose it's just a matter of demand and cost if they would get implemented. Custom applications can do things differently and users of such applications would be aware and probably be very happy about these differences as well.

When you have to keep a .gitignore in the root of your filesystem, when every other app respects that your home directory is not a garbage bin for dotfiles.

In the spirit of the above there should be ways to affect where these files are read from and written to. Personally I'd consider it a win if custom applications would be able to read from the typical locations, but can add more to better adhere to platform conventions.

[wmstack]

Hmm, what do you think of gitoxide probing ~\Appdata\Roaming\Git[oxide]\<file> for the .gitconfig, and if doesn't find it, falls back to the ~\.gitconfig? Is that something ideal or do you think Ein or Gx are in no position to support probing the platform based configuration file first? Let us forget about project roots and instead focus on the home root.

This mechanism would be similar to how the XDG specification suggests that it is done, by probing $XDG_CONFIG_HOME before the $HOME directory. This makes it so that Ein or Gx work as drop in replacements for Git, because probing for the first path would fail, then the probing in the home directory would succeed. This has the advantage that Ein users gain freedom for moving their configuration files to adhere to platform conventions. This doesn't have the effect of affecting other users, because it only affects things like the global user.name and user.email fields of Git.

A potential problem could come about if users switch from Gitoxide back to git, in which case git wouldn't be able to locate their files in $XDG_CONFIG_HOME. However, this sort of problem would happen for every feature that Gitoxide adds for convenience on top of git.

[Byron]

Hmm, what do you think of gitoxide probing ~\Appdata\Roaming\Git[oxide]<file> for the .gitconfig, and if doesn't find it, falls back to the ~.gitconfig? Is that something ideal or do you think Ein or Gx are in no position to support probing the platform based configuration file first?

I think it wouldn't fall back, but read all of them. Having ein + gix include additional directories on Windows is something I'd consider a competitive advantage, assuming that ein will eventually be able to drive entire workflows of course.

A potential problem could come about if users switch from Gitoxide back to git, in which case git wouldn't be able to locate their files in $XDG_CONFIG_HOME. However, this sort of problem would happen for every feature that Gitoxide adds for convenience on top of git.

I agree, and think that the logic you rightfully brought up applies here too: users made the choice so they shouldn't be surprised if git doesn't pick up files from there without them explicitly adjusting their XDG_CONFIG_HOME environment variable in its invocations. It might help to indeed call this folder …/Roaming/ein to not convey the false impression this is related to git.