summaryrefslogtreecommitdiff
path: root/pkgs/development/python-modules/termplotlib/gnuplot-subprocess.patch
diff options
context:
space:
mode:
authorVladimír Čunát <v@cunat.cz>2020-10-26 09:03:55 +0100
committerVladimír Čunát <v@cunat.cz>2020-10-26 09:19:25 +0100
commit1111911593b8bafbab4c280f53d728ee51522689 (patch)
tree4c465028513d5e25ec4c23bec34e00daae03fe5a /pkgs/development/python-modules/termplotlib/gnuplot-subprocess.patch
parent336bc8283bd4ef288e60c5fdb1b67196b9ea5c85 (diff)
parent89023c38fcef79ad135bf6070563be611c4c8d39 (diff)
Merge branch 'staging-next' into staging
I re-verified that the git-tree state looks good after the trouble addressed in commit 89023c38fcef (by the same approach - comparison to a "clean rebase"). I was actually a little surprised that simple git merge did the right thing this time. The one thing I can't fix is that some of staging commits are now reachable from master even though they're not really applied in there yet, but that's just temporary effect until the next merge to master. I certainly don't envy any archeology hitting these commit ranges (e.g. bisections).
Diffstat (limited to 'pkgs/development/python-modules/termplotlib/gnuplot-subprocess.patch')
0 files changed, 0 insertions, 0 deletions