< Luke-Jr>
the point is to avoid ever changing a commit once it has been published
< maaku>
Luke-Jr what do you propose instead?
< morcos>
Luke-Jr: yes can you please explain how that would work? i agree rebasing can introduce errors, but if we all have a chance to see the rebased commit and the merge is clean it seems there is less likely to be problems compared to only one person ever seeing the resolution of merge conflicts
< morcos>
or are you proposing that we would then separately review the merge commit before its actually merged?
< morcos>
For testing purposes, if you rebase then everyone will be testing the same thing that is going to be merged. Otherwise how will we know what the final code is going to look like.
< Luke-Jr>
maaku: merges were designed for this purpose
< Luke-Jr>
morcos: rebasing/revising is anti-decentralised development
< Luke-Jr>
morcos: when the merge substantially changes the code, I agree the changes need review again, just as if it had been rebased
< morcos>
Luke-Jr: any change, not just substantial
< morcos>
if someone is going to test, they need to be able to test the code thats going to exist
< Luke-Jr>
any change does not need re-review. for example, the gitian timestamp thing
< morcos>
i mean any merge conflict, might appear trivial but 2 people might resolve it in different ways
< morcos>
if i want to test 7192 now, how do i know i'm testing the same thing that you are going to end up merging
< morcos>
i don't
< morcos>
but if you rebase it so its a clean merge. the anyone that merges it into master will be testing the exact same code
< morcos>
which sure may contain a rebase or merge error, but at least we'll be testing it
< Luke-Jr>
rebase errors are not the problem with rebasing.
< Luke-Jr>
because rebasing is not intentional workflow in git
< morcos>
sorry, i didn't follow... what do you mean conflicts with?
< Luke-Jr>
morcos: for an example using real-world terms, say I merge the "Unify name" PR into Bitcoin LJR yesterday; and now I rebase it for Core master. Trying to merge this rebased branch into Bitcoin LJR will not work, even after I merge Core master into LJR, because the rebased branch conflicts with the pre-rebase branch
< morcos>
hmm.. ok I see what you mean. I guess it's not clear to me how that situation shows up in our work flow very often.
< Luke-Jr>
Actually, svn is even better than git-rebase in this regard :/
< btcdrak>
merging in pull-requests is ugly to the extreme and makes the main tree disgusting to look at. Just take a gander at Counterparty's source repositiories to see. It's a nightmare to determine what is going on. a PR branch can and should be rebased to make the patch clear and concise.
< btcdrak>
it is wrong to rebase the main tree (i.e. the working master branch and maintenance branches) of course, because that screws up history for everyone, but for patches before they are merged it absolutely makes sense.
< btcdrak>
most of the arguments I've read do not make the clear distinction between PR patches and the upstream repository, which is essential.
< maaku>
btcdrak: the flip argument is that fully decentralized development processes (with independent trees that merge back and forth freely, like linux does) offers a much easier development style
< maaku>
process be damned
< maaku>
er, *clean history be damned
< MarcoFalke>
Imo, it still makes sense to rebase when there is only one commit that can't be merged cleanly. But specifically the unifiy_prodname pull should not be rebased as it is rather huge and collected some tested ACK
< morcos>
sipa: speaking of benchmarks, did you see my comment yesterday about the slowdown in smartfees.py due to the Poisson/trickle change?
< morcos>
Overall the non-extended RPC tests only went from 6 min 9 sec to 9 min 30 sec
< morcos>
so that maybe not enough to do anythign about, but I wonder if just for speed of development testing it woudl be worth adding a chainparam to reduce the inv broadcast interval for regtest?
< sipa>
morcos: hmm
< sipa>
morcos: or just a configurable latency factor
< morcos>
sipa: hmm.. any advantage for mainnet nodes to use that. if you're a fast node you coudl turn it down a bit and if you're barely squeaking by you could turn it up?
< morcos>
let me see how much it speeds up rpc tests to make it 1 sec
< morcos>
sipa: with 1sec poisson its down to 6 min 37 sec for non-extended suite and 85 secs for smartfees
< morcos>
38 secs for smartfees with 0
< morcos>
sipa: your suggestion to forget wallet txs by conflicting with the genesis block? is that motivated by wanting to be able to save the state of whether its forgotten? Because introducing something else would mess with wallet serialization format?
< morcos>
I was tryign to understand why to hack it in there (or even whether that was a serious solution) and then I ran into that problem
< sipa>
morcos: it's sort of a hack; if you have a better solution, feel free :)
< morcos>
sipa: i think its important to remember that state so then when you restart you don't try to reaccept/broadcast any txs you've said to forget, so i'll go with that approach. i'm excited for jonas's new wallet? What the eta on that? March? :)
< jonasschnelli>
morcos: March would be very optimistic. :)
< btcdrak>
jonasschnelli: sounds like you need a dealine to work to :)
< jonasschnelli>
btcdrak: hah. Deadlines make it worse...
< jonasschnelli>
need to finish my hardware wallet stuff first... then i'll focus on the core-wallet
< btcdrak>
what hardware wallet are you working on?
< jonasschnelli>
digitalbitbox.com
< btcdrak>
great, so it will be the first segwit supporting hardware wallet then :)
< jonasschnelli>
1000 pieces are ready for shipping... finalizing the software now.
< jonasschnelli>
btcdrak: sure. the hardware wallet itself is just a secp256k1 signing device that can hold and derive keys.
< jonasschnelli>
+ some fancy crypto to verify your data-to-sign over a smartphone.
< phantomcircuit>
jonasschnelli, secure element or microcontroller in epoxy?
< phantomcircuit>
(looks pretty neat either way)
< jonasschnelli>
phantomcircuit: yes. Both.
< jonasschnelli>
Black epoxy... so, if you want to reset the bootloader or visually extract a seed,... it's going to be very difficult.
< jonasschnelli>
and it should be relatively side-channel attack proof, thanks to libsecp256k1