The comment at the top of git-and-tools/default.nix said:
/* All git-relates tools live here, in a separate attribute set so that users
* can get a fast overview over what's available.
but unfortunately that hasn't actually held up in practice.
Git-related packages have continued to be added to the top level, or
into gitAndTools, or sometimes both, basically at random, so having
gitAndTools is just confusing. In fact, until I looked as part of
working on getting rid of gitAndTools, one program (ydiff) was
packaged twice independently, once in gitAndTools and once at the top
level (I fixed this in 98c3490196).
So I think it's for the best if we move away from gitAndTools, and
just put all the packages it previously contained at the top level.
I've implemented this here by just making gitAndTools an alias for the
top level -- this saves having loads of lines in aliases.nix. This
means that people can keep referring to gitAndTools in their
configuration, but it won't be allowed to be used within Nixpkgs, and
it won't be presented to new users by e.g. nix search.
The only other change here that I'm aware of is that
appendToName "minimal" is not longer called on the default git
package, because doing that would have necessitated having a private
gitBase variable like before. I think it makes more sense not to do
that anyway, and reserve the "minimal" suffix only for gitMinimal.
Although this can be added to `extraOptions` I figured that it makes
sense to add an option to explicitly promote this feature in our
documentation since most of the self-hosted gitea instances won't be
intended for common use I guess.
Also added a notice that this should be added after the initial deploy
as you have to register yourself using that feature unless the install
wizard is used.
This prevents issues when gitea adds new locales etc. And if they
change locale values in future versions. Or if you rollback to a
previous version of gitea it might be a good idea to use the previous
locale files.
The hooks directory contains now one level deep subdirectories which
need to be updated as well.
If you use gitea via ssh, ~/.ssh/authorized_keys also needs to be
updated because of the hardcoded path to gitea in the "command" option.
Using gitea over ssh had two isses:
1. No shell was set for the user
2. Gitea tried to write logs to
/nix/store/x83q12kyd9gw1pay036dxz2dq0apf17h-gitea-1.3.2-bin/log when
serving the ssh usage.
