270 entries in 0.641s
PeterL: if the is are sister patches A and B, and you want to make C using both of them you just
regrind B to B', the only difference would be the one patch version file, and that difference would be readily vissible by diffing B and B', then make C ontop of B', works with current v IIUC
a111: Logged on 2018-01-05 23:40 asciilifeform: think, if EVERY patch requires global
regrind of all of world history, you ain't using v, may as well throw out all of the unnecessary equipment -- you're passing a monolithic turd around
mircea_popescu: trinque there's an ambiguity here i'm possibly responsible for though not intended : to "
regrind", ie to take a pile of patches and make them into one single patch ; as opposed to re-genesis, which is what happened with eg mpi.
mircea_popescu: whereas K would be wrong to attempt same, and instead should
regrind a whole new genesis, call it D, even if it is made up of the reunion of the As and Bs he uses.
a111: Logged on 2017-12-26 23:02 mircea_popescu:
http://btcbase.org/log/2017-12-26#1758790 << especially in the light of 1. move/rename 2. edit double-patch method this seems more and more like the right thing ; but then again what to do of regrinds ?
regrind should ideally be "one patch out of many"
mircea_popescu: if they are, and ONLY if they are, they can stfu and
regrind everything until i get bored of it.
mod6: then we have to
regrind stuff.
phf: mircea_popescu: it is (though there's an interruption in the chain that i need to
regrind) that doesn't help me though, because it's the whole thing, rather than parts.
phf: which reminds me that i need to
regrind my shiva swank patch, which is broken
ben_vulpes: didja throw wires, or pete_dushenski's
regrind of the getpeerinfo backport or any other strange into the tree?
trinque: looser variant only buys you "might get into alternate next-block, otherwise
regrind"
trinque: under current circumstances there are also cases where you will have to
regrind and rebroadcast your transaction
phf: and i don't think anyone cared enough to
regrind polarbeard's patches (actually come to think of it, he had to do it himself two or three times, at which point he gave up)
ben_vulpes: rebase/
regrind to move the patch in the tree and seal to...seal.
shinohai: working on a
regrind of funkensteins privkey patch
shinohai: Not bad here, on standby for the
regrind and other things we discussed. Lots of thinking on the new trilema from today.
phf: only issue with the
regrind approach is clerical. it's easy to keep track of "this new thing that i don't have", much harder to keep all the "this old thing that i have is now new thing" updates
mod6: And the problem is, if I
regrind & sign these patches now, it'd just have to do it again after these other two things are complete anyway.
mod6: and i guess furthermore, if it's needed for me to
regrind these four vpatches as a service for others...
mod6: so if i see the "dump priv key" patch out there on btcbase or found somewhere else (it's not included in the patches in thebitcoin.foundation's site), then i'd pull that vpatch down,
regrind it myself, and place it into patches where I can apply it myself as a "WILD" patch.
mod6: <+phf> asciilifeform: i did, he said something about "this being work in progress and don't want to commit" or somesuch << i could
regrind them, yeah. ideally, each who want to use these unexamined items should do so on their own accord, placing them in their patches directory as a "WILD" patch. Until the day when the foundation moves forward and folds them in after examination and testing.
☟︎ phf: trinque: i say, press to polarbeard_remove_shrink_debug_file, then patch -p1 < polarbeard_better_log_messages, then vpatch the result, then do same for polarbeard_add_getpeerinfo_rpc. that's sort of easiest, fastest way to
regrind assbot: Logged on 10-03-2016 20:46:17; funkenstein_: so when trinque asks me to
regrind, perhaps I should ask him for his tree
funkenstein_: so when trinque asks me to
regrind, perhaps I should ask him for his tree
☟︎ funkenstein_: <trinque> hey,
regrind your vpatch and I'll sign it <-- thanks trinque :) trouble is I'm not sure what base to
regrind from
trinque: ;;later tell funkenstein_ hey,
regrind your vpatch and I'll sign it
mod6: also, re:
regrind, this is for sure: when doing this task, it forces you to read and understand the patch that needs regrinding. nothing wrong with this as far as I can tell.
mod6: Since it's getting brought up... TO ALL CONTRIBUTORS: Thank you for your hard work and submissions. Please hang on to your vpatches, or send them to the BTC-Dev mailing list and we'll get to them post release for review &
regrind if accepted.
mod6: but again, shouldn't effect Mr. P. since he did all of this before the
regrind.
punkman: reading A->B->B(fixed) or A->B->B(
regrind) is still 3 patches each
thestringpuller:
regrind is alt-version of patch, why can't it be applied linearly? (or at least force such a workflow)
mircea_popescu:
regrind, to be perfectly clear, is the act of making a tree out of patches instead of keeping them linear. this is a known efficiency-of-search trope, and i shouldn't have to explain how distributing the patches out saves work when i'm pressing 3 years later and want to read the whole string of patches from genesis.
punkman:
regrind also creates work for readers
PeterL: why not just
regrind all the patches off the genesis and act like we fixed it in one blow?
mod6: ascii_butugychag: is this kinda what you were asking for yesterday? A vdiff of a pressed original patches (minus PVS fix) + shiva with pressed mod6's integrated patch + malleus
regrind + shiva ?
mod6: anyway, i created a new patch for PVS and did a
regrind on malleus (since this one depends on main.cpp)
mod6: since this one is new, and its not in a release, its not horrible. i'd prefer just to fix whatever might be wrong in there and resubmit &
regrind high/low
mod6: <+asciilifeform> we did it for the db locks fix << this is fair. would have to had to
regrind everything after last march :/