| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Since this is probably never the desired case and has led to actual
issues, see the comments at:
https://github.com/NixOS/nixpkgs/commit/af1313e91552e42a4419b396b3026319c60fc17f
This might also happen when pulling a patch from GitHub or a similar web
interface without explicitly selecting the "raw" format.
|
| |
|
|
|
|
|
|
|
| |
Excludes and includes are implemented by passing the parameters to the
respective flags of `filterdiff`. Those were passed unescaped until now.
Since those flags expect patterns (similar to shell globs), something
like `/some/path/*` might be used to exclude or include all files in
some path. Without escaping the shell would expand the `*`, leading to
unexpected behaviour.
|
| |
|
|
|
|
|
|
| |
be non-empty.
This commit was originally introduced as part of #41420 and then
reverted with the rest of that PR. However there was no reason to revert
his particular commit.
|
| | |
|
| |
|
|
| |
be non-empty.
|
| |
|
|
|
|
| |
We still ensure the old and new ones start, respectfully, with `a/` and
`b/`. Use with `stripLen` to ensure tha the old `a/` and `/b` are gone
if a new prefix is added.
|
| |
|
|
|
| |
Before this fix, it seemed to be trying to merge our postFetch with the
patch normalization logic, but accidentally clobbering the whole thing
with the passed-in value.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Sometimes patches start without a leading prefix. We default to strip
one prefix or path component from patches (-p1) in the patchPhase in
stdenv.
As all patches should therefore be in this format, fetchpatch should
have an option to normalize patch paths. This commit introduces a new
argument to fetchpatch called addPrefixes that adds one patch prefix to
the old and new paths in a patch before putting it into the store.
|
| |
|
|
|
|
|
|
|
|
| |
Comes in handy if we want to make additional modificiations to the
output file. While I wasn't sure whether to invoke the passed postFetch
directly before the patch or afterwards, I thought it would be better
afterwards because "postFetch of fetchpatch" at least to my intuition
would sound that after whatever "fetchpatch" does - it comes afterwards.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| | |
|
|
|
fetchpatch is fetchurl that determinizes the patch.
Some parts of generated patches change from time to time, e.g. see #1983 and
http://comments.gmane.org/gmane.linux.distributions.nixos/12815
Using fetchpatch should prevent the hash from changing.
Conflicts (auto-solved):
pkgs/development/libraries/haskell/gitit/default.nix
|