This makes the git HTML manual reproducible.
It also removes the `git.info` manual, since this one is
basically entirely broken anyway. This likely happened
when we migrated from asciidoc to asciidoctor in #102020.
I don't suggest going back to asciidoc: that would
re-introduce a python2 dependency and another
reproducibility issue with the HTML docs.
Co-Authored-By: Dmitry Kalinkin <dmitry.kalinkin@gmail.com>
The install step for the darwin specific $out/etc/gitconfig file
assumed that $out/etc already existed. This assumption is no longer
true after f5e2ff1ed80dac74bfb0afa92f34641cce098a49 in #103421. This
change makes make sure the directory exists before adding to it.
Fixes:
= note: ld: warning: passed two min versions (10.12.0, 10.12) for platform macOS. Using 10.12.
ld: framework not found AppKit
clang-7: error: linker command failed with exit code 1 (use -v to see invocation)
###### Motivation for this change
Update to latest upstream version
###### Things done
* [ ] Tested using sandboxing ([nix.useSandbox](http://nixos.org/nixos/manual/options.html#opt-nix.useSandbox) on NixOS, or option `sandbox` in [`nix.conf`](http://nixos.org/nix/manual/#sec-conf-file) on non-NixOS linux)
* Built on platform(s)
* [x] NixOS
* [ ] macOS
* [ ] other Linux distributions
* [ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside [nixos/tests](https://github.com/NixOS/nixpkgs/blob/master/nixos/tests))
* [ ] Tested compilation of all pkgs that depend on this change using `nix-shell -p nix-review --run "nix-review wip"`
* [x] Tested execution of all binary files (usually in `./result/bin/`)
* [ ] Determined the impact on package closure size (by running `nix path-info -S` before and after)
* [ ] Ensured that relevant documentation is up to date
* [x] Fits [CONTRIBUTING.md](https://github.com/NixOS/nixpkgs/blob/master/.github/CONTRIBUTING.md).
###### Notify maintainers
cc @blitz @Ma27 @tfc @worldofpeace
I made a mistake merge. Reverting it in c778945806 undid the state
on master, but now I realize it crippled the git merge mechanism.
As the merge contained a mix of commits from `master..staging-next`
and other commits from `staging-next..staging`, it got the
`staging-next` branch into a state that was difficult to recover.
I reconstructed the "desired" state of staging-next tree by:
- checking out the last commit of the problematic range: 4effe769e2
- `git rebase -i --preserve-merges a8a018ddc0` - dropping the mistaken
merge commit and its revert from that range (while keeping
reapplication from 4effe769e2)
- merging the last unaffected staging-next commit (803ca85c20)
- fortunately no other commits have been pushed to staging-next yet
- applying a diff on staging-next to get it into that state
