< * sipa>
just learned how to rebase a branch that has merges
< sipa>
(where the merges have merge conflicts)
< btcdrak>
sipa: what dark magic is this?
< sipa>
first use git rebase -i -p <base commit>
< btcdrak>
TIL: -p
< sipa>
that will complain whenever the merge commit is to be merged, as it has merge conflicts
< sipa>
(and rebase -p can't deal with reapplying merge resolution)
< sipa>
then use git checkout -p <original merge commit id>
< sipa>
wait, first use git add -P, to mark all merge conflicts as resolved (you're lying, they aren't)
< sipa>
and then use git checkout -p <original merge commit id>, which applies all changes between the current tree and the tree after that commit
< sipa>
sorry, git add -A
< sipa>
grr
< sipa>
that git checkout -p will show you all the differences between the current tree (which includes the <<< === >>> markers from conflicts you haven't actually resolved) and the result of the original merge commit
< sipa>
which you all accept
< sipa>
except the changes that are due to changes made earlier in history
< sipa>
as you don't want those reset to the original
< NicolasDorier>
sipa: are you here ? I noticed strange incoherence between the BIP and CMPTBLK implementation, I'm wondering if I've not missed something
< NicolasDorier>
I've added some comment during my review, but either I'm completely misunderstanding something or the BIP and implementation is completely off
< phantomcircuit>
NicolasDorier, something something dont ask to ask
< phantomcircuit>
:P
< NicolasDorier>
what does it mean ? :p
< NicolasDorier>
so basically my problem is
< NicolasDorier>
SENDCMPCT should have a boolean which indicate in which mode the peer want to receive new blocks
< NicolasDorier>
either with INV or with CMPCT BLK
< sipa>
indeed, and a version number
< NicolasDorier>
problem is, in the PR, this boolean is used to indicate whether the sender provide or not CMPCTBLK
< NicolasDorier>
ok I'll continue my review on your branch instead
< sipa>
i think the two assignments to preferheadersandids and providesheadersandids just need to be swapped
< NicolasDorier>
it is also a bit confusing: I fail to understand if preferHeadersAndIds means that we use the "high bandwidth (without inv)" or the "low bandwidth" one
< sipa>
that's exactly what it means
< NicolasDorier>
it can also mean that it does not support CMPCTBLK at all
< sipa>
no, that's providesheadersandids
< NicolasDorier>
an enum with 3 values would be easier imhi
< sipa>
providesheadersandids is something that affects our request logic
< sipa>
preferheadersandids is something that affects our send logic
< NicolasDorier>
sipa: on send logic we have 3 cases, legacy, high bandwidth and low bandwidth. PreferHeadersAndIds is a boolean
< NicolasDorier>
oh
< NicolasDorier>
oh no I get it
< NicolasDorier>
because low bandwidth still use INV, it is not different from legacy
< NicolasDorier>
ok, thanks... continuing my review I think it is clearer now
< sipa>
indeed; the difference is that the peer will respond with a getdata MSG_COMPCT_BLOCK rather than MSG_COMPCT_BLOCK
< sipa>
eh
< sipa>
rather than MSG_BLOCK
< sipa>
but that's not our worry
< NicolasDorier>
yes make sense thanks!
< * MarcoFalke>
looks at travis merge commit hash 4222221c0000... and wonders about the odds
< sipa>
MarcoFalke: i have considered grinding commit hashes in segwit to be consecutive numbers :p
< * MarcoFalke>
wonders what happens if someone merges https://github.com/bitcoin/bitcoin/pull/7510 via the GitHub GUI. (The pull conflicts with master but GitHub shows no conflicts... o0 )
< sipa>
MarcoFalke: dragons
< MarcoFalke>
GitHub unicorn
< MarcoFalke>
They have figured out AI that can solve conflicts for you
< sipa>
we should invent a programming language in which every sequence of ascii characters is a valid program
< sipa>
no more merge conflicts
< sipa>
the result may however not be code you want to run
< sipa>
<<< should mean "format disk"
< btcdrak>
babies speak that but they forget it when they grow up so cant teach the adults