< kallewoof>
Is there a way to undo a git checkout -B <existing branch>? I just did it, in the reverse order, and undid all my work. :/
< sipa>
git reflog
< fanquake>
^
< sipa>
that'll give you a history of commits andnbranches you went through
< kallewoof>
Thanks... I think checking out HEAD@{6} got me back where I wanted to be
< sipa>
awesome
< provoostenator>
Or the lazy version if Github is still up to date and you trust them: git reset --hard origin/my-precious-branch
< provoostenator>
* origin -> your github remote
< kallewoof>
prob is, i checked out from master into a new branch, did a bunch of stuff, and then screwed up when I meant to do git checkout -B OVERWRITE_THIS by instead checking out OVERWRITE_THIS branch and doing git checkout -B MYCHANGES...
< kallewoof>
I think my brain decided that checkout -B meant "checkout whatever is on the branch and use that as the new head for this branch"..
< wumpus>
shall I tag v0.19.1?
< wumpus>
I guess I forgot about it a bit and no one reminded me. I don't think anything critical has come up with rc2?
< instagibbs>
ah. Slightly different abstraction than I was thinking
< sipa>
for hardened paths you'd still need a pubkey per derivation as well
< luke-jr>
MarcoFalke: how does the boost bug tested in #18232 affect us?
< gribble>
https://github.com/bitcoin/bitcoin/issues/18232 | test: Check that wait_until returns if time point is in the past by MarcoFalke · Pull Request #18232 · bitcoin/bitcoin · GitHub
< MarcoFalke>
luke-jr: I don't think it affects us
< MarcoFalke>
Well, it might if you change your time zone or system time. But I think Bitcoin Core does not support that anyway?!
< MarcoFalke>
Or if you schedule something with a timestamp in the past. I think we don't do that either
< luke-jr>
then why test it?
< luke-jr>
no reason to create hurdles to tests passing, if they don't affect us..
< MarcoFalke>
It does happen in unit tests or functional test, because there we schedule things in the past (for testing reasons)
< luke-jr>
hmm
< luke-jr>
well, we still should be able to test on current systems IMO
< MarcoFalke>
Yeah, which is why the mockscheduler test is disabled
< MarcoFalke>
I think the only feasible solution is to remove boost
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #18232: WIP test: Check that wait_until returns if time point is in the past (master...2002-debugBoost) https://github.com/bitcoin/bitcoin/pull/18232
< luke-jr>
or handle the exception?
< MarcoFalke>
How would you handle it and then proceed with execution?
< MarcoFalke>
The next call would throw the same exception
< MarcoFalke>
And if the exception is handled in the scheduler, it seems overkill to modify Bitcoin Core code for purly (unit) testing needs
< MarcoFalke>
*purely
< * MarcoFalke>
lunch
< luke-jr>
MarcoFalke: if the exception is thrown, check manually if the time is past; if not, rethrow
< luke-jr>
if so, nothing more to do
< MarcoFalke>
Jup, in that case it would need to be handled in the scheduler, which I'd rather not for the reason just mentioned
< nothingmuch>
MarcoFalke: i think the currently disabled test can be made robust to the failure by deducting a delta that doesn't go too far into the past, i'm attempting that now
< nothingmuch>
the mockforward test, that is
< MarcoFalke>
I know. But that still doesn't *solve* the problem
< MarcoFalke>
If you reboot your machine and have the tests already compiled it will still fail, even with a minimal delta
< nothingmuch>
oh!
< nothingmuch>
i didn't realize that =(
< MarcoFalke>
Basically any delta that is larger than the time it took you to start your machine
< nothingmuch>
oh, ok that's how i understood it before... just to make sure - the time of compilation itself doesn't factor in, right? it's that if the compilation is fast?
< nothingmuch>
what i was going to do is just compute a delta for mockforward that is enough to be in the past, but no further in the past than the start of the test
< MarcoFalke>
The boost::internal_clock (whatever that is) starts to count when you start your computer
< MarcoFalke>
if boot+compile takes 2 minutes, the clock will show 2 minutes
< jonasschnelli>
cfields_: whats sigs would it take if there is no tag? Just the head of the 0.19 branch?
< cfields_>
jonasschnelli: it tries to checkout a ref with the same name as the release. So 'git reset --hard v0.19.1' (or something like that) would just fail.
< cfields_>
ok, gitian builders: detached sigs for v0.19.1 are up
< instagibbs>
luke-jr, unless I have serious misunderstandings, erlay shouldn't really effected anymore than flooding relay with respect to diverse network policies
< instagibbs>
it's basically a batching of INVs you would have sent your peer, then compact exchange of that difference
< bitcoin-git>
[bitcoin] luke-jr reopened pull request #15600: lockedpool: When possible, use madvise to avoid including sensitive information in core dumps or forked process memory spaces (master...lockedpool_dontdump) https://github.com/bitcoin/bitcoin/pull/15600