< kallewoof>
jojeyh: I think your question is more suited for #bitcoin though, btw.
< jojeyh>
kallewoof, thx i was wondering if someone had already done it
< jojeyh>
aye
< pierre_rochard>
Does anyone know of software / a script that can say “if you merge this pull request, then pull requests X, Y, and Z will have to be rebased”? Google didn’t turn anything up so I’m interested in writing one
< Randolf>
pierre_rochard: The folks on the #github channel have been helpful to me in the past. I suspect there's a good chance someone there might know of something like you describe if it exists.
< pierre_rochard>
I’ll ask them, thanks Randolf!
< Randolf>
You're welcome.
< Alohaaaa>
Hello
< wumpus>
pierre_rochard: ajtowns[m] did some work in that direction (a script to figure out which PRs collide with which others) from what I remember
< pierre_rochard>
wumpus: thanks, maybe https://github.com/ajtowns/bitcoin-prs is it and he hasn’t pushed the code up yet. ajtowns[m] I’m happy to help out
< murrayn>
argh. had an open PR, and made a mistake push. easy way to undo that?
< wumpus>
murrayn: yes, go to git reflog, find the old commit id
< wumpus>
murrayn: force-push that to the branch
< murrayn>
wumpus, will that undo the push? or create a new push that undoes the bad push?
< murrayn>
just curious
< wumpus>
isn't that the same?
< murrayn>
well
< murrayn>
i'd rather just go back in time obviously.
< murrayn>
than to document fixing a fuckup
< wumpus>
well by finding the old commit id you're going back in time
< murrayn>
ok, we'll see
< wumpus>
to me it seems entirely philosophical wehther you consider that a new push of an old state, or re-doing an old push, or restoring the previous push
< murrayn>
hmm
< wumpus>
also you can do git reset --hard <commit> (on the branch) first to do it locally, then force-push the branch to the remote branch, if that's easier to understand
< murrayn>
wumpus, just trying to understand: so after the reset, is the --force necessary?
< murrayn>
wumpus, or just git push
< wumpus>
yes, the force is necessary as you're pushing a commit that is not a child of the current branch
< murrayn>
ah
< wumpus>
it doesn't change, from regard of github, what you do locally
< murrayn>
wumpus, thank you sir.
< murrayn>
seems to have worked.
< wumpus>
cool
< wumpus>
I've invited eklitzke (as frequent contributor) to the bitcoin and bitcoin-core orgs
< kallewoof>
if you literally want to go back to say '5 mins ago' you can also do: git reset --hard mynicebranch@{"5 minutes ago"}
< wumpus>
kallewoof: ah yes, git understands time referencs, I forgot about that :)
< kallewoof>
wumpus: I only learned about it a few weeks ago. I actually used it already, once. :) Very cool feature.
< contrapumpkin>
esotericnonsense: hah, after a day of running -reindex, it popped up the exact same error message at the same place :P
< Randolf>
contrapumpkin: Might there be a bad sector on your hard disk?
< bitcoin-git>
bitcoin/master ae5bcc7 Wladimir J. van der Laan: Merge #10694: Remove redundant code in MutateTxSign(CMutableTransaction&, const std::string&)...
< provoostenator>
#12666 made me curious: when do we use packages like UniValue from the OS, vs. compiling it from the src dir? And why even bother with the former?
< wumpus>
for libraries that are part of consensus (secp256k1,leveldb) there's a good reason to bundle it, for leveldb especially as we have some custom patches to it
< mrannanay>
wumpus : Thanks!
< wumpus>
for univalue the case is somewhat weaker, but based on it being a rarely-packaged library
< wumpus>
not bundling it would give people a lot of pain
< sipa>
luke-jr: none of that applies; univalue is effectively developed by us
< wumpus>
finding it, building it, manually installing it. We save that for berkeleydb 4.8 :-)
< luke-jr>
well, if we didn't depend on 1.0.4 specifically now, 1.0.2 is pretty widespreadly packaged
< wumpus>
unilvalue is virtually only used by us
< wumpus>
yes, bundling makes it possible to develop it in parallel
< wumpus>
without having to support tons of combinations
< sipa>
i think the arguments in those documents very much apply to not bundling bdb, boost, glibc, ...
< bitcoin-git>
bitcoin/master 02de6a6 João Barbosa: Assert cs_main is held when accessing mapBlockIndex
< bitcoin-git>
bitcoin/master c651df8 João Barbosa: Lock cs_main while loading block index in AppInitMain
< bitcoin-git>
bitcoin/master f814a3e João Barbosa: Fix cs_main lock in LoadExternalBlockFile...
< luke-jr>
we're also not the upstream for univalue. jgarzik is.
< provoostenator>
But why aren't univalue, secp256k1, etc part of the Depends system? Maybe there should be a way to build /depends skipping installed packages?
< wumpus>
I'd really prefer not to change this - it works, people are used to it
< luke-jr>
it's probably good enough as is; bumping the required version here and there is no big deal
< sipa>
provoostenator: look up how subtrees work
< luke-jr>
sipa: his point is that using depends would be superior to subtrees
< sipa>
yes, and i disagree with that
< provoostenator>
Subtrees as opposed to submodules?
< sipa>
we want exact control over the source code used for some things
< luke-jr>
sipa: we could have exact control over it with depends too
< sipa>
yes, but we'd lose it for non-depends builds
< provoostenator>
(I've had nothing but headaches dealing with git submodules, so not blaming anyone for not using them)
< luke-jr>
not necessarily
< sipa>
subtrees give us this property always
< luke-jr>
anyhow, unless someone is going to put the work into migrating it over, no point wasting time discussing in depth IMO
< wumpus>
also there is no special incantation needed to check things out
< wumpus>
it's simply in one tree
< provoostenator>
wumpus: I'm fine with not changing it even if it was better :-)
< wumpus>
it's perfect like this IMO
< provoostenator>
I didn't realize "git subtree" was a command, that's nice. Is there a way to check if it matches the original repo (other than git diff)?
< sipa>
provoostenator: yes, we have a script that does that :)
< sipa>
you need access to the original repo, of course
< wumpus>
./contrib/devtools/git-subtree-check.sh
< provoostenator>
"git-subtree-check.sh src/univalue" doesn't seem happy, I guess I need to add some hints to check the right fork?
< provoostenator>
Looks like it's checked by default (I did some trial and error sabotage on my local machine).
< arubi>
bip173 lists tc1qw508d6qejxtdg4y5r3zarvary0c5xw7kg3g4ty as being invalid due to "invalid human-readable part", is it just that "tc" is not one of "bc", "tb", or "bcrt" or is there anything else to it? seems that apart from that it does encode a valid p2wpkh
< sipa>
arubi: yup
< arubi>
cool, cheers
< sipa>
invalid hrp
< arubi>
right, in my mind hrp could be anything, but I see why it's not a "segwit address"
< sipa>
BIP173 only specifies bc and tb, so anything else is invalid
< Chris_Stewart_5>
arubi: I believe the lightning people repurpose it. Don't know how the author feels about that usage though :-)
< sipa>
but it's certainly valid bech32... just not a valid segwit address
< sipa>
Chris_Stewart_5: bech32 is designed to be generally useful :)
< arubi>
right, so as long as some implementation keeps to its own hrp, we should all be fine
< sipa>
(though they violate the spec by exceeding 90 characters)
< aj>
sipa: did you get a chance to read the mail i sent about soft-fork compatible sig aggregation? see any obvious problems, or worth sending to bitcoin-dev do you think?