1 2015-09-15 00:44:58 <bedeho> When a transaction is serialized, isthe txid in the outpoints supposed to be reversed, or just left as is in memory/wire?
  2 2015-09-15 00:53:13 <btcftw> what c++ std does core use?  c++-11?
  3 2015-09-15 00:53:20 <therealplato> gmaxwell bad_duck i will happily comment on github issue or PR discussing signing with URI
  4 2015-09-15 00:59:56 <buZz> btcftw: -not- c++11
  5 2015-09-15 01:00:06 <buZz> older
  6 2015-09-15 01:00:12 <buZz> maybe 99 even, not sure
  7 2015-09-15 01:03:08 <btcftw> ok thx... was going to try something using std::chrono::steady_clock but I guess not
  8 2015-09-15 01:03:32 <btcftw> I think there's something in boost I can use
  9 2015-09-15 01:26:13 <bedeho> When a transaction is serialized, isthe txid in the outpoints supposed to be reversed, or just left as is in memory/wire?
 10 2015-09-15 01:26:40 <dcousens> bedeho: you ask this question a lot, whats troubling oyu?
 11 2015-09-15 01:26:42 <dcousens> you*
 12 2015-09-15 01:26:45 <dcousens> its left as is
 13 2015-09-15 01:26:48 <dcousens> as we discussed yesterday
 14 2015-09-15 01:26:54 <jgarzik> +1
 15 2015-09-15 01:41:22 <bedeho> dcousens, yes, Im having serious trouble with this
 16 2015-09-15 01:46:24 <dcousens> for actual use,  it is used in its *non*-reversed format,  usually this will be at a level where it is represented by a raw byte buffer, and not by its hex string.
 17 2015-09-15 01:53:22 <dcousens> bedeho: does that help?
 18 2015-09-15 01:55:47 <bedeho> dcousens, so its a case by case basis thing then I take it, do you have any idea if a serialized tx sent to bitcoind RPC would have reversed prevTxIds?
 19 2015-09-15 01:55:57 <bedeho> its serialized, but its also a hex string, so..?
 20 2015-09-15 01:56:32 <dcousens> bedeho: if your querying the RPC, use the reversed string,  if your sending a serialized tx,  send it (in hex) as though it was to be used internally
 21 2015-09-15 01:56:46 <dcousens> a transaction is only serialized in 1 way
 22 2015-09-15 01:58:00 <bedeho> so then its always reversed in serialization then, regardless of purpose?
 23 2015-09-15 01:58:51 <bedeho> given that the hex version sent to rpc is just toHex() translation based on serialization
 24 2015-09-15 01:59:23 <dcousens> bedeho: what?
 25 2015-09-15 01:59:58 <dcousens> bedeho: the transaction is sent as-is to the RPC
 26 2015-09-15 02:00:08 <dcousens> its only transaction ids, on their own, that are reversed
 27 2015-09-15 02:00:49 <dcousens> if they are embedded in a transaction,  classify that as internal usage,  and write it as though it came directly from sha256
 28 2015-09-15 02:01:09 <dcousens> Its confusing, but, the distinction is pretty clear when you start using these APIs
 29 2015-09-15 02:01:19 <bedeho> lets take it over PM, thanks for taking the time
 30 2015-09-15 02:22:06 <RainMan28> Does Andreas Schildback idle in here?
 31 2015-09-15 02:55:32 <midnightmagic> RainMan28: he is there sometimes
 32 2015-09-15 16:36:14 <bedeho> do op_return outputs have to have at least 547 satoshies (or whatever it is), to not trigger the dust limit?
 33 2015-09-15 16:41:07 <gmaxwell> No.
 34 2015-09-15 16:41:23 <gmaxwell> Since they're provably unspendable the utxo-pollution motivation does not apply.
 35 2015-09-15 16:43:52 <jonasschnelli> bedeho: https://github.com/bitcoin/bitcoin/blob/master/src/primitives/transaction.h#L148
 36 2015-09-15 16:45:48 <bedeho> gmaxwell, jonasschnelli : ty
 37 2015-09-15 17:29:06 <jgarzik> Trolling for review and ACKs of morcos's Do not use hard-coded AllowFree for free transactions. #6131 https://github.com/bitcoin/bitcoin/pull/6131
 38 2015-09-15 17:32:31 <jgarzik> ditto Improve usage of fee estimation code #6134 https://github.com/bitcoin/bitcoin/pull/6134
 39 2015-09-15 17:33:37 <phantomcircuit> morcos, jgarzik there seems to be an issue with trying to send free transactions at all, specifically the policies implemented by miners today are inconsistent on this front
 40 2015-09-15 17:34:03 <phantomcircuit> eligius likely allows high priority free transactions, where as f2pool appears to be simply ordering by fee
 41 2015-09-15 17:34:06 <jgarzik> phantomcircuit, that inconsistency is inevitable
 42 2015-09-15 17:34:14 <jgarzik> yep
 43 2015-09-15 17:34:38 <phantomcircuit> jgarzik, long term the incentives are strongly in favor of the simple profit maximizing approach
 44 2015-09-15 17:34:43 <phantomcircuit> short term who knows
 45 2015-09-15 17:37:14 <jgarzik> phantomcircuit, Well - at an even higher level, miners pick and choose their own transaction selection policy, which can also include private agreements to mine zero-fee transactions for a flat contractual rate (e.g. miners confirmed transactions for BitPay customers that fail to include adequate fee for whatever reason)
 46 2015-09-15 17:37:39 <jgarzik> so just assume you'll never know and never get 100% right, and go from there :)
 47 2015-09-15 17:38:02 <jgarzik> IMO the pull request creates less-worse behavior than before
 48 2015-09-15 17:38:08 <phantomcircuit> are we using a bloom filter to avoid requesting the same transaction over and over again if it's rejected?
 49 2015-09-15 17:38:29 <phantomcircuit> gavinandresen, i seem to remember you working on that
 50 2015-09-15 17:39:41 <phantomcircuit> jgarzik, it certainly seems to use smarter behavior; im skeptical that long term those kinds of agreements make sense but it's certainly something to keep in mind
 51 2015-09-15 17:39:56 <phantomcircuit> those kinds of agreements are potentially very dangerous as well
 52 2015-09-15 17:39:57 <sipa> jgarzik: thanks fot pinging a bunch of older pull requests, I'm commenting on a few
 53 2015-09-15 17:42:33 <Luke-Jr> ;;bc,blocks
 54 2015-09-15 17:42:34 <gribble> {"blockcount":374673}
 55 2015-09-15 17:48:38 <gmaxwell> phantomcircuit: the deduping was merged not that long ago. it's in git master.  (sorry not finding the commit with a quick look)
 56 2015-09-15 17:49:27 <phantomcircuit> gmaxwell, seems to be b46e7c24e58efd06f60ae0f9ab85a53283e23059
 57 2015-09-15 17:50:33 <jgarzik> sipa, I work from the bottom up :)
 58 2015-09-15 18:02:50 <btcdrak> is there any historical reason why openssl was chosen over cryptopp for bitcoin core?
 59 2015-09-15 18:04:32 <sipa> btcdrak: ask satoshi :)
 60 2015-09-15 18:05:11 <sipa> in part of 0.3.x and maybe a bit later, cryptopp was used for mining  actually
 61 2015-09-15 18:05:26 <sipa> in retrospect, ecdsa in cryptopp is much slower than openssl
 62 2015-09-15 18:07:01 <gmaxwell> sipa: cryptopp is also hard to audit like openssl but for totally different reasons.
 63 2015-09-15 18:07:04 <gmaxwell> :)
 64 2015-09-15 18:07:26 <gmaxwell> E.g. I found concurrency safty bugs in cryptopp that you could only ever find pretty much by reading the asm output. :P
 65 2015-09-15 18:08:34 <phantomcircuit> oy
 66 2015-09-15 18:10:12 <nwilcox> gmaxwell: Is there a ticket for that?
 67 2015-09-15 18:11:09 <jgarzik> Trolling for ACKs, [Qt] allow possibility to add a comment to a WalletTx #5905 https://github.com/bitcoin/bitcoin/pull/5905
 68 2015-09-15 18:25:24 <jgarzik> Trolling for ACKs, [RPC] add possibility to extend the JSONRPC URI schemas #6006 https://github.com/bitcoin/bitcoin/pull/6006
 69 2015-09-15 18:28:08 <jgarzik> Trolling for ACKs, add bip32 pub key serialization #6215 https://github.com/bitcoin/bitcoin/pull/6215
 70 2015-09-15 18:42:06 <phantomcircuit> jgarzik, ehhhh in general i think using the comments stuff in the wallet is ill advised
 71 2015-09-15 18:42:17 <jonasschnelli> phantomcircuit: reason?
 72 2015-09-15 18:42:24 <phantomcircuit> i've seen to many people using them for critical accounting functions it's sad
 73 2015-09-15 18:42:38 <jonasschnelli> Yes. This is a point.
 74 2015-09-15 18:42:52 <btcdrak> OT: is everyone (devs) still hanging around Montreal or gone home?
 75 2015-09-15 18:43:09 <jonasschnelli> btcdrak: i'm at the airport, flying back to CH
 76 2015-09-15 18:43:30 <jonasschnelli> phantomcircuit: there is an open issue for that: https://github.com/bitcoin/bitcoin/issues/2086
 77 2015-09-15 18:43:47 <jgarzik> However that road was traveled a long time ago.  It is better to fix the inconsistency and offer a feature that people do find useful, rather than avoid it because people might misuse it.
 78 2015-09-15 18:43:57 <jgarzik> Comment and memo fields are quite normal for this class of software.
 79 2015-09-15 18:44:06 <jonasschnelli> Argeed...
 80 2015-09-15 18:44:17 <jonasschnelli> The only bad thing is: they are not encrypted in wallet.dat
 81 2015-09-15 18:44:23 <jonasschnelli> Can be critical
 82 2015-09-15 18:44:25 <phantomcircuit> btcdrak, there's still people around, mostly not available until evening
 83 2015-09-15 18:44:36 <jonasschnelli> :)
 84 2015-09-15 18:45:46 <phantomcircuit> jgarzik, most accounting software today also has automated cloud backups for exactly this reason
 85 2015-09-15 18:45:52 <btcdrak> jgarzik: how would you propel the refactoring efforts? I think we really need to get the bulk code moves done, it's been dragging on for over a year and no end in sight, no even clear idea where it's going (to me).
 86 2015-09-15 18:46:04 <phantomcircuit> im thinking we're unlikely to be adding that to the core wallet :)
 87 2015-09-15 18:46:50 <jgarzik> btcdrak, like I noted on list -- and tried to do with P2P message processing PR -- accelerated the bulk moves and getting them over with is one potential "rip the bandaid off" path
 88 2015-09-15 18:47:03 <phantomcircuit> btcdrak, ping jtimon to ask about the goals there
 89 2015-09-15 18:47:12 <jgarzik> collecting many bulk moves in a time-constrained window is better for all developers
 90 2015-09-15 18:47:28 <jgarzik> then a drip drip drip that randomly N developers downstream
 91 2015-09-15 18:47:35 <jgarzik> *randomly breaks
 92 2015-09-15 18:47:52 <btcdrak> jgarzik: but that is obvious, but I dont really see (maybe my own blindness) where it's going. I totally agree with you, and I've brought it up a lot over the last year.
 93 2015-09-15 18:48:29 <jgarzik> Several complained to me at the conf about it.  Anyway, got to run :/  bbiah
 94 2015-09-15 18:48:58 <btcdrak> it's almost like there is a "we must go slowly" without proper reason. Code-only bulk moves are cheap (easy to review and merge quickly). it breaks the back out of the change and then everyone can re-orientate.
 95 2015-09-15 18:49:54 <btcdrak> jgarzik: even blockstream will suffer the pain soon if with Element
 96 2015-09-15 18:50:33 <phantomcircuit> jgarzik, i think we all agree that we would get a lot more done with that model, but i dont think that's a safe model for a consensus system
 97 2015-09-15 18:50:39 <btcdrak> Bitcoin Core diverges way too much. The disruption cannot be overstated.
 98 2015-09-15 18:52:06 <btcdrak> A few weeks ago I suggested to wumpus we have a refactoring week and get lots of those changes. If we can just agree on a whiteboard of roughly where things are going and do *code-only moves*, it really cant hurt.
 99 2015-09-15 18:52:45 <phantomcircuit> btcdrak, iirc code only moves have actually caused bugs in the past
100 2015-09-15 18:53:00 <phantomcircuit> if they dont change the binary i dont have any issue with them
101 2015-09-15 18:53:09 <phantomcircuit> but if they do we should be much more mindful
102 2015-09-15 18:53:15 <btcdrak> phantomcircuit: well, that's because code only moves are often not when you get down to it...
103 2015-09-15 18:53:26 <phantomcircuit> yes thats my point :P
104 2015-09-15 18:55:12 <btcdrak> If I were maintainer, I would outright reject refactoring that stepped even an inch out of line. move only means just that, even if that commit breaks building, then the next commit adds the necessary headers etc. That way it's so easy to review and step through. graphical diff tools make those kinds of diffs super easy to review too.
105 2015-09-15 18:58:49 <jgarzik> phantomcircuit, it's not code-only moves in isolation, it's a stream of them over time in random places
106 2015-09-15 19:00:08 <phantomcircuit> jgarzik, no i understand the problem and i do agree that it would be useful to have the code move pull requests to happen in a shorter window as a sprint
107 2015-09-15 19:00:26 <phantomcircuit> but it's generally very difficult to get enough people around at the same time to do all the review for all of these
108 2015-09-15 19:02:17 <jgarzik> phantomcircuit, I think the key decision is mainly which bits to move into which physical files for storage.  Procedurally that minimizes future patch size & breakage.
109 2015-09-15 19:02:30 <jgarzik> the patches themselves can be generated quickly once that decision is made
110 2015-09-15 19:07:44 <btcdrak> additionally, code only moves dont need a ton of review if they really are move only. Verification is mechanical
111 2015-09-15 19:08:14 <phantomcircuit> jgarzik, maybe? the problem is that code moves really do require close to the same amount of review
112 2015-09-15 19:08:22 <phantomcircuit> outside of a few really trivial cases
113 2015-09-15 19:08:30 <btcdrak> in fact, PRs that move code should only move code and have no other refactoring in them.
114 2015-09-15 19:08:44 <phantomcircuit> btcdrak, absolutely
115 2015-09-15 19:10:42 <btcdrak> in projects I have maintained we would have "code moves", "code style fixed" and "code refactoring" as separate PRs entirely. The first two are super easy to review and merge, the last kind takes the normal laborious code review but is a lot easier because diffs remain concise (because no chunks of code move)
116 2015-09-15 19:12:04 <phantomcircuit> btcdrak, yes, the addr/tx trickle patch is unnecessarily complex right now
117 2015-09-15 19:12:20 <phantomcircuit> it needs to be re done as "delete the old logic" "implement new logic"
118 2015-09-15 19:12:32 <phantomcircuit> as the logic is essentially completely replaced
119 2015-09-15 19:18:43 <kanzure> while i too would like the "band-aid all-at-once refactoring" approach, it was my understanding that this hasn't happened before because there wasn't enough available manpower to sufficiently grok everything and refactor correctly?
120 2015-09-15 19:19:29 <kanzure> perhaps it would be helpful if people stopped rebasing
121 2015-09-15 19:19:44 <kanzure> and instead did merge commits
122 2015-09-15 19:19:48 <kanzure> where they fix the conflicts
123 2015-09-15 19:20:30 <kanzure> this way, you can pull in those merge commit fixes into your other branch and then apply the other work on top of that (although this might be more work- although slightly easier- than constant painful rebases)
124 2015-09-15 19:20:57 <btcdrak> kanzure: that's not a good workflow and makes for a horrible git history.
125 2015-09-15 19:21:07 <btcdrak> topic branches shoudl never be merged, only rebased.
126 2015-09-15 19:21:31 <kanzure> btcdrak: heh i disagree, if you push a branch then you should never rebase it. to do otherwise is to step on everyone else's toes and moves the ground from under them.
127 2015-09-15 19:21:39 <kanzure> btcdrak: i agree that rebasing can be used to make concise history
128 2015-09-15 19:22:56 <kanzure> "horrible git history" isn't quite accurate- most default visualization tools will not easily make sense of the history, but if you compare branches against each other or follow parents then it's easier. but yeah, by default it is harder to make sense of when you aren't using rebase everywhere.
129 2015-09-15 19:23:00 <btcdrak> kanzure that's a common misconception. your patch history is there to communicate a story so others can look at your code years later and see what happened, and why. cleaning up your own patch history is absolutely what git intends. What you should not do, is rebase the upstream repository.
130 2015-09-15 19:23:24 <kanzure> every branch is "upstream" to someone- that's why it was made public, after all.
131 2015-09-15 19:23:26 <btcdrak> when I talk about topic branches, those are contributor patches
132 2015-09-15 19:24:08 <btcdrak> and until a contributor patch is merged, it's not final, it's a story you can rewrite.
133 2015-09-15 19:25:30 <kanzure> actually i think you can get "incremental merge" benefits with rebasing too, as long as you rebase and have multiple commits; but this wont make all possible merge problems easier for downstream users of that branch.
134 2015-09-15 19:26:28 <btcdrak> Look at an example of a project that does allow merges of upstream into topic branches which then get merged into upstream and you'll see what a disgusting mess it is. Counterparty* repositories.
135 2015-09-15 19:26:37 <kanzure> but anyway-- i'm more interested in my question re: "refactoring requires more effort than we have available, thus why nobody has submitted a single big patch for fastmerge/fastreview".
136 2015-09-15 19:26:49 <kanzure> btcdrak: i never claimed that non-rebasing makes for cleaner history :-)
137 2015-09-15 19:27:35 <phantomcircuit> kanzure, for patch sets that are expected to be maintained long term and never merged it makes sense to merge instead of rebase
138 2015-09-15 19:27:47 <kanzure> why's that
139 2015-09-15 19:27:58 <phantomcircuit> because it really is upstream for someone else then
140 2015-09-15 19:27:59 <btcdrak> kanzure: I think the refactoring thing is really easy to solve if we can get a few devs on IRC to agree on "where stuff can go", then it can just be done. If it's code-only moves with warts and all, review will be a cinch.
141 2015-09-15 19:28:53 <kanzure> phantomcircuit: ok, but not because it "makes merging easier for downstream users resolving merge conflicts"?
142 2015-09-15 19:29:24 <kanzure> i mean, "easier" as in easier merge conflicts, or easier-to-resolve merge conflicts, compared to rebasing-related conflicts
143 2015-09-15 19:29:39 <kanzure> btcdrak: oh okay, i was overestimating the size of the problem then.
144 2015-09-15 19:30:19 <phantomcircuit> kanzure, in general if you're trying to get something merged upstream rebasing is really necessary
145 2015-09-15 19:30:36 <phantomcircuit> if you're not then it doesn't much matter and might actually be cleaner to have merge commits
146 2015-09-15 19:31:33 <zooko> Are you guys doing that thing that git users do where you argue about whether to have a complete history of all events vs. to have a coherent history with clean, meaningful steps?
147 2015-09-15 19:31:38 <zooko> Because if so: choose both!
148 2015-09-15 19:31:39 <btcdrak> Another I like merge commits for a patch set is they clearly demark a new featureset or bugfix set, (which may consist of several commits).
149 2015-09-15 19:31:47 <kanzure> zooko: no we skipped that argument
150 2015-09-15 19:31:50 <btcdrak> zooko :-)
151 2015-09-15 19:31:58 <zooko> Oh, sorry then. I'm no help. :-)
152 2015-09-15 19:55:03 <Luke-Jr> btcdrak: merge commits is much better than rebasing. basically the only reason to rebase is due to git's poor UI when displaying them :/
153 2015-09-15 19:56:01 <btcdrak> Luke-Jr: take a look at Counterparty repositories :-P
154 2015-09-15 19:56:10 <Arnavion> or the TypeScript repository
155 2015-09-15 19:56:25 <Arnavion> Any PR that lasts longer than a few days will start containing merges from master
156 2015-09-15 19:56:45 <Arnavion> At one point ISTR gitk showed fifteen parallel vertical lines
157 2015-09-15 19:57:07 <Luke-Jr> btcdrak: the "look" is a git problem
158 2015-09-15 19:57:27 <Luke-Jr> btcdrak: for an alternative, see how Bazaar does it. everything looks nice.
159 2015-09-15 19:57:41 <Luke-Jr> basically defaulting to --first-parent and nicer merge messages
160 2015-09-15 19:58:23 <jgarzik> In general, kanzure is right - the ideal git workflow is merges, not rebase w/ forced push.   Most people prefer a nicer squash prior to upstream merge for cleaner git history.  It's a tradeoff in the realm of personal preference...
161 2015-09-15 19:58:34 <jgarzik> As long as git bisect works correctly in upstream tree I'm pretty happy...
162 2015-09-15 19:58:41 <jgarzik> bbias
163 2015-09-15 19:58:52 <Arnavion> Rebasing doesn't mean you also want to squash
164 2015-09-15 19:58:53 <Luke-Jr> git bisect would work better with merges I think
165 2015-09-15 19:59:03 <Luke-Jr> it would also make forks easier to maintain
166 2015-09-15 19:59:20 <Luke-Jr> (which we really should encourage)
167 2015-09-15 19:59:27 <Arnavion> Just that the responsibility of fixing conflicts is with the branch author, not the merger
168 2015-09-15 19:59:49 <Luke-Jr> Arnavion: the branch author can do the merge
169 2015-09-15 19:59:55 <Arnavion> or they can rebase
170 2015-09-15 20:00:09 <Luke-Jr> yes, but rebase breaks history etc
171 2015-09-15 20:00:14 <Arnavion> No it doesn't
172 2015-09-15 20:00:19 <Luke-Jr> yes it does
173 2015-09-15 20:00:22 <Arnavion> As I said, rebasing doesn't mean you have to squash
174 2015-09-15 20:00:30 <Arnavion> It means you move the branch on top of where you want to merge it
175 2015-09-15 20:00:31 <btcdrak> Luke-Jr: we're not talking about breaking history of upstream
176 2015-09-15 20:00:45 <Arnavion> and then do a simple merge commit with no conflicts
177 2015-09-15 20:00:59 <btcdrak> Arnavion: exactly this
178 2015-09-15 20:01:10 <Luke-Jr> Arnavion: if there would be conflicts, then rebase loses history
179 2015-09-15 20:01:21 <Luke-Jr> btcdrak: "upstream" does not exist
180 2015-09-15 20:01:46 <Luke-Jr> in terms of this debate
181 2015-09-15 20:01:49 <Starduster> ^+1  <jgarzik>
182 2015-09-15 20:02:24 <Arnavion> I can understand that rebasing loses history of the initial development
183 2015-09-15 20:02:33 <Arnavion> That's what you mean, right Luke-Jr?
184 2015-09-15 20:02:40 <Luke-Jr> yes
185 2015-09-15 20:03:05 <Arnavion> Right
186 2015-09-15 20:03:19 <btcdrak> Luke-Jr: but it does. We're talking about contributors submitting topic branch patch sets upstream. Those should be rebased. If patchsets merge upstream into the topic branch several times, then the patch set is merged into upstream it's just disgusting.
187 2015-09-15 20:03:20 <Luke-Jr> to be fair, there is a potential for rebase and squash to be done with low-level merges, but git doesn't support this nicely either :/
188 2015-09-15 20:03:26 <jgarzik> The history of initial development is typically not useful and often not in usefully reviewable chunks.
189 2015-09-15 20:03:29 <Luke-Jr> (although it doesn't solve reordering
190 2015-09-15 20:03:45 <jgarzik> "skeleton" "fix" "fill in more" "ok it works" "more fixes" "feedback fixes" ...
191 2015-09-15 20:03:47 <Luke-Jr> jgarzik: no need to review it - just to review what is being merged
192 2015-09-15 20:04:16 <jgarzik> Luke-Jr, disagreement completely - just like you review steps in an equation, proper change composition is important
193 2015-09-15 20:04:16 <Luke-Jr> btcdrak: it's disgusting *because of* git, not because it's a bad workshop
194 2015-09-15 20:04:18 <Luke-Jr> workflow*
195 2015-09-15 20:04:26 <jgarzik> the series of transformations is very important
196 2015-09-15 20:04:29 <jgarzik> as well as the end result
197 2015-09-15 20:04:46 <Luke-Jr> jgarzik: most of that can be done without losing history
198 2015-09-15 20:05:13 <Luke-Jr> anyhow, I don't care enough to push for this. I disagree on what is ideal, but it's not worth spending time arguing over.
199 2015-09-15 20:05:23 <Arnavion> I would say that the initial history and the change's review becomes worthless once you have to resolve a merge conflict in the merge commit
200 2015-09-15 20:05:47 <Arnavion> Because the merge conflict can cross multiple files from the individual commits in the original change
201 2015-09-15 20:06:23 <Starduster> Arnavivion: indeed...
202 2015-09-15 20:06:32 <Luke-Jr> disagree
203 2015-09-15 20:06:39 <Starduster> explain
204 2015-09-15 20:06:41 <Arnavion> Your review process would be "C1 looks good. C2 looks good. C3 looks good. Mergecommit touches stuff in all of C1, C2, C3 - need to re-review those while keeping the merge conflict changes in my head."
205 2015-09-15 20:06:48 <btcdrak> jgarzik: eloquently put
206 2015-09-15 20:07:03 <zooko> You folks *are* arguing that thing that I said.
207 2015-09-15 20:07:12 <zooko> You walk into the Great Library of Whoville.
208 2015-09-15 20:07:31 <zooko> On the left, there are stacks containing the complete transcripts of all the town council meetings, tax records, correspondance, diaries, etc.
209 2015-09-15 20:07:44 <zooko> On the right, there are stacks containing the multi-volume history of the town, written by a good historian.
210 2015-09-15 20:07:52 <zooko> This debate is about which one to throw out into the dumpster in the back.
211 2015-09-15 20:07:55 <zooko> I would suggest "neither".
212 2015-09-15 20:08:01 <jgarzik> All this is simply reinventing ground that other open source projects solved long ago...
213 2015-09-15 20:08:02 <btcdrak> zooko: and what we really need to do is pressgang wumpus and jtimons into a code-only move refactoring week.
214 2015-09-15 20:08:14 <Luke-Jr> Arnavion: the ideal merge would be C1' merging C1, C2' merging C2, and C3' merging C3
215 2015-09-15 20:08:22 <Luke-Jr> optionally combining them when you want to squash
216 2015-09-15 20:08:51 <Arnavion> Luke-Jr: Huh? I'm talking about a situation where I sent you a PR containing C1, C2, C3, and a week later when you're ready to merge it to master it has conflicts with the current master
217 2015-09-15 20:09:05 <Arnavion> Are you saying you would merge each commit individually?
218 2015-09-15 20:09:08 <Luke-Jr> Arnavion: then you make C1', C2', C3'
219 2015-09-15 20:09:14 <Luke-Jr> yes, that would be ideal
220 2015-09-15 20:09:17 <jgarzik> ugh
221 2015-09-15 20:09:19 <btcdrak> inb4 someone invents tonal-merge commits
222 2015-09-15 20:09:41 <Luke-Jr> and git should hide C1,C2,C3 and only show the merged ones
223 2015-09-15 20:09:51 <Luke-Jr> by default
224 2015-09-15 20:10:17 <zooko> The reason people incorrectly think that they need to throw out one of the stacks is that when you walk in and ask the library "Where is branch B1?", they have to direct you to one place.
225 2015-09-15 20:10:23 <Arnavion> Luke-Jr: Does any VCS offer that functionality automatically?
226 2015-09-15 20:10:26 <zooko> But that doesn't mean you have to throw out the other place.
227 2015-09-15 20:10:46 <btcdrak> I still think git is like magic, when you come from CVS/subversion where branches are folders in a tree and not contexts.
228 2015-09-15 20:10:47 <Arnavion> Luke-Jr: I mean "Merging each commit individually and asking for resolving conflicts."
229 2015-09-15 20:10:53 <Luke-Jr> Arnavion: not sure; darcs probably has something *like* it
230 2015-09-15 20:11:06 <kanzure> Luke-Jr: ouch i forgot about --first-parent
231 2015-09-15 20:11:53 <Luke-Jr> btcdrak: darcs is real magic. git looks very simple in comparison :P
232 2015-09-15 20:12:29 <zooko> Simple rule to mostly fix this: whenever you're about to throw out some history in git, you're only doing that because you want to take its name and use that name for something else, so
233 2015-09-15 20:12:31 <btcdrak> Luke-Jr: never heard of it. *scrambles for google*
234 2015-09-15 20:12:41 <zooko> don't throw it out. Take its name and use that name for something else, and give that thing a *different* name.
235 2015-09-15 20:12:53 <zooko> The first thing, I mean, the thing that I'm begging you not to throw out.
236 2015-09-15 20:13:18 <zooko> "Mostly", because this doesn't 100% solve it, because having a large number of archival names can clutter up some git UIs...
237 2015-09-15 20:13:21 <Luke-Jr> btcdrak: it basically considers C1 and C1' as the same "commit"
238 2015-09-15 20:13:34 <kanzure> Luke-Jr: ok so the actual issue earlier that i was wondering about was "do incremental merges make it easier for downstream contributors to maintain their funky branches of stuff they haven't merged upstream yet?" compared to rebasing. i suspect that an adequate workflow can be achieved with rebasing, but you have to be clever about it in a way that i keep forgetting.
239 2015-09-15 20:13:45 <btcdrak> zooko, maybe the best VCS would be one that has no history at all and consists of snarks :-P
240 2015-09-15 20:13:52 <Arnavion> Luke-Jr: I assume that C1', C2', etc. are merges from master to the branch and not the other way around, and that at the end you have one merge from the branch to master?
241 2015-09-15 20:13:52 <zooko> btcdrak: lol
242 2015-09-15 20:13:57 <kanzure> btcdrak: it's not history, just diffs
243 2015-09-15 20:14:07 <Arnavion> Luke-Jr: Because otherwise you wouldn't have a single merge commit to revert if you want to revert the entire "feature"
244 2015-09-15 20:14:18 <Luke-Jr> Arnavion: no, I would start from master and merge C1, C2, and C3 to produce C1', C2', and C3'
245 2015-09-15 20:14:31 <Luke-Jr> Arnavion: it would look exactly the same as rebasing now, but retain history
246 2015-09-15 20:14:42 <Arnavion> Then you wouldn't have a single commit to revert
247 2015-09-15 20:14:44 <Arnavion> like I said
248 2015-09-15 20:15:06 <Arnavion> With rebasing you still get that because you would merge --no-ff to merge it
249 2015-09-15 20:15:19 <kanzure> oh right, yeah you can do n-way merging in git if you want to have a branch of history that is more "clean", but other incremental branch might be more helpful for speeding up merge work in other people's branches
250 2015-09-15 20:16:21 <Luke-Jr> Arnavion: what?
251 2015-09-15 20:16:47 <Arnavion> Uhh
252 2015-09-15 20:16:52 <Arnavion> So taking that same example
253 2015-09-15 20:17:08 <Arnavion> where I sent you the PR for C1, C2, C3, and you merged it according to your scheme of C1', C2', C3'
254 2015-09-15 20:17:28 <Arnavion> Now you discover the entire feature is flawed / a security disaster / whatever and you want to revert it
255 2015-09-15 20:17:37 <Arnavion> Do you revert C3', C2', C1' individually?
256 2015-09-15 20:18:09 <Luke-Jr> you revert the merge commit to master, just like you would with a regular rebase
257 2015-09-15 20:18:29 <Arnavion> But C1',C2',C3' are the individual merge commits, right?
258 2015-09-15 20:18:39 <Arnavion> C1' is C1 merged into master, no?
259 2015-09-15 20:21:58 <Luke-Jr> Arnavion: http://0bin.net/paste/DksOw0YgP+VLWGP-#BJqMS96T-DXnmLK4b5c8hjT38lnxnIx6ldgb9XBhMa1
260 2015-09-15 20:22:13 <Luke-Jr> Arnavion: except git should hide the original commits by default
261 2015-09-15 20:23:26 <Arnavion> Right, so you're not merging C1 into master to make C1'
262 2015-09-15 20:23:32 <Arnavion> You're merging master into C1 to make C1'
263 2015-09-15 20:24:13 <Arnavion> which is what I said   <Arnavion> Luke-Jr: I assume that C1', C2', etc. are merges from master to the branch and not the other way around, and that at the end you have one merge from the branch to master?
264 2015-09-15 20:26:49 <Luke-Jr> Arnavion: no, I'm merging C1 into master to make C1', and then merging C3' into master
265 2015-09-15 20:27:01 <Luke-Jr> Arnavion: rephrasing..
266 2015-09-15 20:27:10 <Arnavion> No, when you make C1', master does not point to C1'
267 2015-09-15 20:27:20 <Arnavion> So you're not merging C1 into master
268 2015-09-15 20:27:25 <Luke-Jr> I'm re-branching from master, merging C1, C2, C3 to make C1', C2', C3', and then merging the re-branch into master
269 2015-09-15 20:27:30 <Arnavion> Correct
270 2015-09-15 23:46:48 <Tebbo> Anyone think running a TX node on an open wifi network is a good idea?
271 2015-09-15 23:47:27 <Tebbo> I guess if I add it to a vpn I'm alright huh?