< Randolf>
I'm trying to squash my commits in Pull Request 12501 ( https://github.com/bitcoin/bitcoin/pull/12501 ), but when I attempt to do this the "git rebase -i HEAD~1" command seems to be working on the wrong Pull Request (which was already merged a while ago).
< Randolf>
I had trouble squashing my PR in the past, and I'm hoping someone can help me figure this out. Thanks in advance.
< Randolf>
It seems that git is trying to squash PR 12125.
< kallewoof>
Randolf: git status first line which branch does it say?
< Randolf>
The "git status" command returns: On branch master
< kallewoof>
Randolf: do git checkout patch-2, then git rebase -i HEAD~1
< Randolf>
Oh, okay, I'll try that then.
< Randolf>
Okay, so I actually have 3 commits now, so I used "git rebase -i HEAD~2" instead. But, even though I only had two commits to squash, which I recognized as mine, I'm now seeing that two files will be included even though I only changed one file. The other file's changes have nothing to do with my
< Randolf>
changes. Is this normal?
< Randolf>
It's almost as if there are three commits involved in this.
< kallewoof>
That sounds wrong. What does git log show?
< Randolf>
I'm just trying to find the logs. (I'm not quite sure what I'm looking for, but I don't see git.log.)
< kallewoof>
type: git log
< Randolf>
At the top of the screen I see this: commit adb0c9e509a3bf1ccbfca5c8d04e9e150af566f7 (HEAD -> patch-2)
< Randolf>
Followed by: Author: Jonas Schnelli <dev@jonasschnelli.ch>
< Randolf>
I'm "Randolf Richardson" though.
< Randolf>
Maybe if I delete and then clone it all in again.
< kallewoof>
wait, so this shows someone else's commit? git show HEAD
< Randolf>
Okay, so "git show HEAD" looks like my changes.
< Randolf>
But before mine I see this: Bugfix: respect user defined configuration file (-conf) when open conf. file from QT settings
< Randolf>
Then the next line is from my PR: [qt] Improved "custom fee" explanation in tooltip
< kallewoof>
Did you do 'git merge' by any chance?
< kallewoof>
Looks like you screwed up somewhere. Do this: git reset --hard origin/patch-2
< Randolf>
The "git checkout" stuff didn't work for me before, so I always had to use "git clone" to get the files in.
< Randolf>
I'll try that.
< kallewoof>
Getting spammy, let's do PMs.
< Randolf>
After "Rebasing (2/2)" I'm still seeing the wrong PR: [detached HEAD ac6368aa1] Merge #12489: Bugfix: respect user defined configuration file (-conf) in QT settings
< gribble>
https://github.com/bitcoin/bitcoin/issues/12489 | Bugfix: respect user defined configuration file (-conf) in QT settings by jonasschnelli · Pull Request #12489 · bitcoin/bitcoin · GitHub
< Randolf>
Thanks for all your help kallewoof. I appreciate it.
< Randolf>
provoostenator: I can help with updating them.
< Randolf>
What needs to be changed?
< provoostenator>
It should increase instructions on how to use the `bumpfee` RPC method.
< wumpus>
it's still valid as a worst-case fallback, I guess, if bumpfee doesn't work
< provoostenator>
That could go on top. The rest would be valid still.
< provoostenator>
Although I think ther'es a command to purge the mempool now.
< provoostenator>
And maybe there's a way to make it stop listening that doesn't involve confguring a fake proxy?
< wumpus>
-nolisten -noconnect would do it
< Randolf>
Well, we could leave the instructions for 0.13.2 on there as is, and add instructions for newer versions.
< provoostenator>
Anyway, I'm going to try these manual steps myself to motivate me to pay more attention to RBF related tickets...
< Randolf>
provoostenator: If you don't have edit access to that page, just let me know and I'd be happy to help with adding some instructions.
< Randolf>
...then we can also include wumpus' point with the older instructions and note that they can also serve as a worst-case fallback.
< provoostenator>
I would just relay on RPC methods that work for 0.16, maybe link back to an old version of the page. Too much text makes it look even more daunting than it is.
< provoostenator>
relay -> rely
< wumpus>
provoostenator: -persistmempool=0 will stop reading the mempool at startup (and writing it back), should be preferable to deleting the mempool file if it's supposed to be temporary, otoh that'd bring back the old mempool with the old transaction so I'm not sure
< Randolf>
provoostenator: That's a good idea.
< provoostenator>
wumpus: I don't think we should rely on launch flags, as those are really hard to use for QT users
< wumpus>
supporting 0.15+ should be ok, 0.16 is still way too new
< provoostenator>
But I guess the current instructions already do that...
< wumpus>
provoostenator: there's no other way
< provoostenator>
0.15 users probably didn't set the RBF flag anyway
< provoostenator>
But I agree the instructions should cover that version too.
< provoostenator>
I used the following approach: quit QT, start with -persistmempool=0 and immedidately disconnect using the network icon. Make new transaction as per 11&12. Maybe unneeded: copy raw transaction connect again and use sendrawtransaction. Quit and relaunch normally.
< wumpus>
meeting?
< Randolf>
provoostenator: If you can provide some specific instructions, then I'd be happy to put them up onto the wiki.
< Randolf>
wumpus: Oh, yeah, it is that time of the week! :)
< wumpus>
#startmeeting
< lightningbot>
Meeting started Thu Feb 22 19:01:09 2018 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
< Randolf>
For me, rc4 is still synchronizing the blockchain. It seems fine though.
< wumpus>
cfields: promag: thanks, it's getting better at least
< wumpus>
no new reported issues with it?
< wumpus>
then yay, I'd say let's tag final after the meeting
< BlueMatt>
regressions? no, issues still cropping up in 0.15.1 :/
< achow101>
hello
< achow101>
yay
< wumpus>
there's lots of already existing issues, but if we had to wait for all 599 of them to be closed before a release we should postpone it for a few years at least
< BlueMatt>
yes
< BlueMatt>
I was not suggesting delaying 0.16, only commenting
< wumpus>
or a billion years maybe, it seems the number is only ever increasing
< provoostenator>
Should I hold my finger on the gitian build trigger?
< promag>
wumpus: is there a merge queue? :P
< wumpus>
merge queue?
< wumpus>
I haven't been able to pay attention at least, if there's something ready for merge let me know (although right now I'm busy doing last minute checks for 0.16)
< bitcoin-git>
bitcoin/0.16 4b4d7eb Wladimir J. van der Laan: doc: Remove note about temporary file from release notes...
< promag>
ok, so in a couple of days we can clean some easy prs? there are a couple already with (ut)acks
< wumpus>
why in a couple of days?
< wumpus>
is there something special going on?
< jtimon>
right, you can tell him which ones now, even if he keeps checking 0.16 first
< promag>
oh no.. "couple of hours then"?
< wumpus>
if it's up to me I'd prefer merging non-easy PRs with enough utACKs
< wumpus>
* [new tag] v0.16.0 -> v0.16.0
< wumpus>
provoostenator: yep
< achow101>
yay! \o/
< sipa>
~w00000t
< Randolf>
In PR #12501 I've made an attempt to improve the wording in a tooltip (I don't consider this to be a high-priority fix). We're at a point now where I need to know whether transaction fees below the threshold are apportioned or simply counted as 1k as there seem to be two different opinions on the
< jonasschnelli_>
Oh. Did i miss the meeting again?!
< jonasschnelli_>
Thought its now
< jonasschnelli>
it's hard to participate when you are in UTC+8
< aj>
jonasschnelli: UTC+10 isn't easy either, though lack of DST is at least a win
< jonasschnelli>
aj: yes. indeed.
< bitcoin-git>
[bitcoin] Empact opened pull request #12512: Don't test against the mempool min fee information in mempool_limit.py (master...fix-min-fee-test) https://github.com/bitcoin/bitcoin/pull/12512