--- Day changed Mon Aug 06 2018
01:19 -!- undeath [~undeath@unaffiliated/undeath] has joined #joinmarket     
02:05 -!- grubles [~grubles@unaffiliated/grubles] has quit [Remote host closed the connection]     
02:05 -!- grubles [~grubles@unaffiliated/grubles] has joined #joinmarket     
02:49 <@waxwing> undeath, i'm a bit confused about the wallet storing utxos in storage. Since on startup we call sync_unspent and it just resets and reloads anyway, what's the purpose in adding the utxos to storage?
02:49 <@waxwing> Oh; it means you can load/read the wallet contents without sync/scan i guess? but then it'll be outdated. hmm.
02:49 < undeath> no real purpose. I implemented it like that only to later notice it was never intended to be stored
02:50 <@waxwing> hmm yeah. maybe there's some edge case or new app where it's useful. it doesn't hurt.
02:50 < undeath> it's not used at all
02:50 <@waxwing> except: an unencrypted wallet will have extra identifying data in it, right?
02:50 < undeath> during sync the first thing called is reset_utxos()
02:50 <@waxwing> yes i got that (see above)
02:50 <@waxwing> but it is persisted right?
02:51 < undeath> it is
02:51 < undeath> I should remove that
02:51 < undeath> forgot about it
02:51 <@waxwing> yeah, i actually don't think it's terrible but we may as well remove it for now.
02:51 <@waxwing> but the idea of having a utxo manager object is probably nice anyway, perhaps for some future features
02:53 <@waxwing> "extra identifying data" heh what am i talking about, it has the private key :) anyway i guess nobody fails to encrypt wallets.
02:54 < undeath> it's not even allowed for non-testnet wallets iirc
03:00 <@waxwing> there was another comment i made that i'm not sure if you saw yet: https://github.com/JoinMarket-Org/joinmarket-clientserver/pull/104#discussion_r207744772
03:00 <@waxwing> i may have just misunderstood but let me know
03:01 <@waxwing> no rush ofc, i'm still reading wallet at the moment (although i think i understand most), remaining big areas are wallet_utils, taker, maker, then i think i'm mostly done and will start doing a few manual tests
03:01 < undeath> oh, that one. considering external changes is quite tricky
03:01 < undeath> all kinds of things could go wrong if you consider external modification
03:03 <@waxwing> ok. just seems logical to me to make best effort to keep persistent storage; so if you can write to disk, why not?
03:03 < undeath> would you recommend to simply indiscriminately write to disk?
03:04 <@waxwing> well i don't know about "recommend", but, is there a downside?
03:04 < undeath> considering the size of the average wallet probably not
03:05 <@waxwing> i mean it's a definite edge case anyway, so i'm not going to get upset either way
03:25 < undeath> re pyaes, I don't mind using a different lib. I opted for pyaes because at the time it was used by electrum and it didn't add any atrocious dependencies (ie libsodium)
03:43 < undeath> pushed three new commits to reflect your review insights
03:50 <@waxwing> just checked, thanks
03:57 <@waxwing> it would be really cool if someone else wanted to do a bit of review, maybe in particular: the key import and the mnemonic (incl. especially the mnemonic extension) parts
03:57 <@waxwing> belcher, adlai alexcato or anyone else who's a heavy user ^
03:58 <@waxwing> i guess the comment is more general, if you're familiar with the project, consider trying to run this PR (#104) as a test. it's going to be a good improvement to the project so it's worth it.
03:59 <@waxwing> undeath, i take it we want people to run the conversion script, could you give explicit advice on that (i haven't reached that point in my review yet)
03:59 < undeath> yes     
04:00 < undeath> all you need to supply is the full path to the [walletname].json and it will create a [walletname].jmdat file
04:04 < undeath> maxmixdepth in wallet_utils is currently basically ignored. it is only used for creating a test wallet with hexseed
04:04 < undeath> but I have no idea why I changed the default from 5 to 0
04:05 < undeath> https://github.com/undeath/joinmarket-clientserver/commit/d4e80f92c6888762a6e6cb3f920ee2b904e982ab#diff-b27abfd2db5aa55af981cd811309e366
04:05 < undeath> commit in question
04:05 < undeath> this is probably what should be used when creating a new wallet in general
04:06 < undeath> option has no relation to its help text :/
04:20 < undeath> fixed the mixdepth issue in wallet_utils
05:29 <@waxwing> as per comment update in PR, now going to start doing manual tests. i'll have to switch (mostly) to mainnet for that.
05:33 -!- MaxSan [~user@185.9.19.107] has quit [Ping timeout: 244 seconds]     
05:43 <@waxwing> yes, just anecdotal, but for a heavily used wallet i'd also estimate speedup of sync is about 50%. plus it's not going to be doing the quit-restart thing in most cases.
05:44 < undeath> oh, that's nice
05:44 < undeath> I was afraid it may have ended up slower
05:44 <@waxwing> the weird thing is, previously, the delay was before the "bitcoind syncunspent" line. now it's after, for some reason.
05:46 <@waxwing> error in showutxos method: Traceback (most recent call last):
05:46 <@waxwing>   File "wallet-tool.py", line 8, in <module>
05:46 <@waxwing>     print(wallet_tool_main("wallets"))
05:46 <@waxwing>   File "/home/adam/code/Joinmarket/joinmarket-clientserver/jmclient/jmclient/wallet_utils.py", line 1014, in wallet_tool_main
05:46 <@waxwing>     return wallet_showutxos(wallet, options.showprivkey)
05:46 <@waxwing>   File "/home/adam/code/Joinmarket/joinmarket-clientserver/jmclient/jmclient/wallet_utils.py", line 319, in wallet_showutxos
05:46 <@waxwing>     for u, av in utxos[md]:
05:46 <@waxwing> ValueError: too many values to unpack
05:47 < undeath> oh, that's missing a .items()
05:48 < undeath> weird, I thought I tested that
05:50 <@waxwing> yep, fixed
05:55 <@waxwing> ok, apart from that everything in wallet-tool appears to be working, except i didn't test privkey import.
05:56 <@waxwing> did test dump/display privkey tho
05:56 < undeath> I did test privkey import
05:56 < undeath> worked for me at least :)
06:06 <@waxwing> hmm got this one while testing, but it's nothing to do with the PR: https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/master/jmclient/jmclient/taker.py#L358-L363
06:07 <@waxwing> just hangs until the timeout, oh well, try again.
06:09 <@waxwing> hmm so keyboard interrupt results in a lock hanging around. can we catch a keyboard interrupt, or perhaps we shouldn't. the error message might need to tell the user where the lock file is (even if it's obvious to us)
06:09 < undeath> yeah, the lock file is sometimes a little annoying
06:09 < undeath> especially when testing
06:10 < undeath> I already tried to delete it in __del__ but that's not called when the interpreter exits
06:11 < undeath> a try/except should be a good idea
06:11 < undeath> or at least try/finally
06:12 <@waxwing> oh. sendpayment finished and shutdown normally, but i still get the lockfile error when starting wallet-tool after.
06:13 < undeath> wallet.close() needs to be called at the end of the script, it's possible I forgot adding it to sendpayment
06:13 < undeath> maybe it's better to use something like https://github.com/dmfrey/FileLock
06:14 <@waxwing> ok. maybe add that as an Issue for later.
06:14 <@waxwing> yeah looks like missing on sendpayment and tumbler
06:26 < undeath> this might be worth looking at https://docs.python.org/2.7/library/atexit.html
06:27 < undeath> it can (hopefully) be used to reliably remove the lock on exit
06:34 <@waxwing> looks like just what we need if it works according to the description. so any usual exception that causes shutdown will still allow the lock to be removed in that case.
06:35 < undeath> pushed a commit with atexit, that should also work with keyboard interrupts and no need to add the wallet.close() call
06:35 <@waxwing> i mean, it's a very soft lock mechanism anyway, the effect is more of a warning to the user than an actual prevention, so it should be fairly light.
06:35 <@waxwing> right i will try to test.
06:45 <@waxwing> yes, confirmed, that is working on normal ending, on ending with rejecting offers (y/n = n) and after keyboard interrupt. at least for sendpayment, no reason to think not for others too.
06:48 < undeath> great
06:48 < undeath> thank you for your thorough reviewing and testing!
07:24 -!- Lightsword_ [~Lightswor@2604:a880:1:20::1d3:9001] has joined #joinmarket     
07:26 -!- Lightsword [~Lightswor@2604:a880:1:20::1d3:9001] has quit [Ping timeout: 240 seconds]     
07:26 -!- Lightsword_ is now known as Lightsword     
07:29 <@waxwing> np, this is kinda huge so got to be done. but yeah i'm certainly happy now that we're going to merge it, just we need a couple more eyes than mine on it, at least testing one or two things.
10:37 <@waxwing> Left a final comment at the end of the PR. Please test (to other contributors).
10:38 < undeath> yep, saw it. thank you :)
10:38 < undeath> will rebase rn
10:46 < undeath> I'm not sure how a sensible multi-commit squashing could look like
10:46 < undeath> all I can think of is one commit per file which seems rather pointless
10:48 <@waxwing> undeath, yeah i remember asking recently. i think you can do it in the `git rebase -i HEAD~n` part .. like somehow put "squash" on the different lines.
10:48 <@waxwing> sorry terrible memory, it couldn't have been more than a month ago someone said this to me ...
10:48 < undeath> ah, yeah
10:48 < undeath> that would work
10:49 < undeath> but I don't think you can reorder commit in rebase, can you?
10:49 <@waxwing> i'd be guessing, but i'd say no ..
10:55 < undeath> looks like rebase does in face support reordering
10:55 < undeath> *fact
10:58 <@waxwing> oh great, gtk
11:07 < undeath> rebased, squashing will take some additional time
11:15 < undeath> uh, wtf, I just force-push killed the repo
11:22 <@waxwing> undeath, oh that sounds unfortunately; still got everything locally?
11:22 <@waxwing> unfortunate, even
11:22 < undeath> yes, I do
11:22 < undeath> but github is weird
11:23 < undeath> I now pushed it again to the branch and it shows up on github but github closed the PR and says "there are no now commits to the branch"
11:23 < undeath> *no new
11:25 <@waxwing> it shows up as closed by you
11:26 < arubi> all changes are gone from the branch
11:26 <@waxwing> well if you end up just opening a new PR we can just cross-link for the previous comments/review, so nbd
11:26 < undeath> https://github.com/undeath/joinmarket-clientserver/tree/new-wallet
11:26 < undeath> all the changes are still there
11:26 < undeath> but they vanished from the pr
11:27 -!- puddinpop [~puddinpop@unaffiliated/puddinpop] has quit [Ping timeout: 265 seconds]     
11:27 < arubi> I think you rebased on top of waxwing's 0.3.5 release commit
11:27 < arubi> https://github.com/JoinMarket-Org/joinmarket-clientserver/commit/8fa0f730a50b36b6509c889012e23af9d9fc1b7b
11:28 < undeath> :/     
11:28 < arubi> waxwing, you have the state of the repo before that right?  (do not pull.. that branch, or what's left of it)
11:28 < undeath> any idea how to fix that?
11:29 <@waxwing> arubi, sure. but he still has the same code at his new-wallet branch now
11:29 < arubi> hm     
11:29 <@waxwing> but absolutely, take your point, do not pull from it rn
11:29 < arubi> this new branch has conflicting history now
11:29 < undeath> oh     
11:29 < arubi> (specifically this release commit)
11:29 < undeath> I see
11:29 < undeath> what is the last commit you have, waxwing?
11:30 <@waxwing> c6cf17cda8df5a89cadfc2b1950cfa81633cd93a
11:30 <@waxwing> "ensure storage lock file ..."
11:30 < undeath> ok, git still has that localley
11:30 < arubi> yea all hashes are different now because of that thing
11:32 < arubi> I'm not sure how to fix the committer thing, but it's possible.  first I think it's best to create a new local branch like new-wallet-test and do all tests on that
11:32 <@waxwing> so first  you did interactive rebase, with squash. and then you did git rebase master but it wasn't up to joinmarket-org/master?
11:33 < undeath> I rebase on the wrong "thing" and everything went down from there
11:34 < arubi> I'll try looking into this soon too..  maybe find something that works
11:37 < arubi> also I'm wondering if waxwing can force push the correct history onto undeath's branch
11:37 < undeath> I doubt waxwing can do anything to my repo ;)
11:37 < arubi> I think he can, since you opened the PR
11:37 < undeath> oh     
11:37 <@waxwing> arubi, the link you posted above: that commit says "undeath committed 3 days ago" but it's in Joinmarket-Org? how does that work?
11:37 < arubi> I mean, by default github lets the repo owner d o that
11:38 < arubi> yea that's pretty weird in itself.  maybe just github's way of showing the PR history..
11:40 <@waxwing> so it's commits in the PR which has now been deleted from the repo (well the PR *commits*, if not the PR)?
11:40 <@waxwing> so you're saying if i force-pushed onto that PR it would show up again?
11:40 <@waxwing> and also be in undeath's branch?
11:41 < undeath> I have c6cf17cda8df5a89cadfc2b1950cfa81633cd93a in the branch again
11:41 < undeath> but the PR does not update any more
11:42 < arubi> I never tried force pushing onto someone else's branch
11:42 < undeath> git branch -f new-wallet c6cf17cda8df5a89cadfc2b1950cfa81633cd93a && git push --force
11:43 <@waxwing> yeah the history in the branch now looks right.
11:43 <@waxwing> so create a new PR i guess is the easiest thing to do? or should we do something else?
11:43 < arubi> did you try re-opening that same PR undeath?
11:44 < undeath> I can't :(
11:44 < arubi> crap :\
11:44 < undeath> the button is gray and tooltip says "There are no new commits on the undeath:new-wallet branch."
11:46 <@waxwing> yes it was gray for me too
11:46 < undeath> it's as if github deleted the branch and now created a new branch with the same name
11:46 < undeath> and doesn't realise that's the same branch as before
11:47 <@waxwing> yes i believe that is the case. as far as github (git?) is concerned you have a new branch with the same name.
11:47 <@waxwing> i noticed i can do that with branches, make new ones with same name as deleted ones.
11:47 < arubi> is your remote called "origin" undeath ?
11:47 < undeath> yes     
11:47 < arubi> so currently the new-wallet branch is good right?  maybe try `git push -u origin new-wallet:new-wallet`
11:48 < undeath> Branch 'new-wallet' set up to track remote branch 'new-wallet' from 'origin'.
11:48 < undeath> Everything up-to-date
11:48 < arubi> what a weird thing
11:48 < undeath> I think it's really about some pointer that got lost and/or is broken now
11:49 <@waxwing> is it really weird if the system just allows you to re-use a name? then the old one is simply deleted.
11:49 < undeath> locally I didn't even create a new branch…
11:49 <@waxwing> hmm. ok, that is weird, yes.
11:49 < undeath> I just did something weird while trying to rebase
11:50 <@waxwing> any chance you can tell us what commands you did?
11:50 < undeath> yes     
11:51 < arubi> also I'm wondering which commit comes right before 908877a
11:51 < undeath> after I did (wrongly) git rebase authority/master
11:52 < undeath> I think there was an --onto missing
11:53 <@waxwing> oh; do you need an onto there? i thought it was understood to be the current branch? (i don't do this too often, but that's my memory)
11:53 < arubi> I always do `git pull --rebase jmorg master` to first rebase on top of joinmarket-org's master, then `git rebase --interactive HEAD~n` to squash\fixup\whaetver
11:53 < undeath> then I reordered one commit with git rebase -i
11:53 < undeath> and what broke stuff was when I then did git rebase --onto authority/master
11:53 < undeath> that somehow ended me up with simply authority/master
11:54 < undeath> which I immediately force-pushed without checking
11:54 < undeath> that was when github automatically closed the pr and the branch was broken
11:54 <@waxwing> so seems like the --onto part was the error
11:54 < arubi> so which commit comes before 908877a?
11:55 < arubi> on the new-wallet branch
11:55 < undeath> now it's 39eba7a17b7d8cea8585fd2da5c7f6fd263976a8
11:55 < arubi> same with you waxwing ?
11:56 < undeath> yes, we're both on c6cf17cda8df5a89cadfc2b1950cfa81633cd93a
11:56 < undeath> (I added one more commit now, but)
11:56 < arubi> no I mean, one before the very first commit
11:56 <@waxwing> arubi, yes 39eba
11:56 < undeath> if the hash matches up the base is the same
11:56 < undeath> changing the base will change the hash
11:57 < arubi> right right, I wasn't sure which was the original hash at the HEAD
11:57 < undeath> sorry for the mess
11:57 < arubi> so maybe first `git pull --rebase <jm-org remote> master`, to be on top of actual master..
11:57 < arubi> well, first `git checkout -b new-wallet-tests` :)
11:58 < arubi> then we can go back if things break again
11:58 <@waxwing> undeath, np
11:58 <@waxwing> arubi, +1 that sounds right to me (fwiw)
11:59 < undeath> yep, doing the rebasing again now
11:59 < undeath> with the correct command this time
12:00 <@waxwing> lol https://twitter.com/ComfortablySmug/status/1026500091639681024
12:02 < undeath> lol, my daily struggle
12:02 < arubi> haha
12:03 < arubi> jones probably feels very much validated by this
12:03 < undeath> oh, github fixed itself
12:04 <@waxwing> yeah i see it
12:04 < undeath> suddenly the button was not greyed-out any more and I could re-open
12:04 <@waxwing> had you already pushed anything?
12:04 < arubi> and it says "Able to merge" now
12:04 < undeath> now the rebased version is online
12:05 <@waxwing> ok, so this is rebased on master, but not squashed, right
12:05 < arubi> waxwing, can you restart travis?
12:05 < undeath> exactly
12:05 < undeath> travis is running
12:05 < arubi> on your end, but canceled on jm-org side
12:06 < undeath> https://travis-ci.org/JoinMarket-Org/joinmarket-clientserver/builds/412788908
12:06 < arubi> huh     
12:06 < arubi> yea you're right
12:06 < arubi> well it'll run again anyway after rebase-force-push
12:07 < arubi> oh but it says the owner of this job is waxwing?  man this is weird :)
12:07 < arubi> "AdamISZ authored and committed", wew
12:07 < undeath> force-pushed again, travis should catch up now
12:08 < undeath> oh no, what did it do
12:09 < undeath> I see. I deleted an early commit and now with the rebasing things are a little weird
12:09 < undeath> (deleted the commit that was changing the travis config)
12:09 < arubi> now jmclient/setup.py is conflicting doh.  deleted == marked as fixup?
12:09 < undeath> deleted == drop
12:09 < arubi> oh     
12:11 < undeath> ok     
12:11 < undeath> just re-ran the git pull --rebase cmd
12:11 < undeath> fixed now
12:11 < arubi> awesome, here we go
12:12 < arubi> https://travis-ci.org/JoinMarket-Org/joinmarket-clientserver/builds/412788908 can be canceled
12:12 < arubi> (will start more jobs on undeath's push)
12:14 <@waxwing> ping me when we're near the end point :)
12:14 < arubi> if you cancel that ^ (only you can), it'll be sooner :)
12:14 < undeath> squashing will take a moment but I can probably do it today
12:15 <@waxwing> oh ok i can cancel, sure.
12:16 < arubi> nooo
12:16 < arubi> you canceled undeath's push :(
12:16 <@waxwing> eh? i canceled a push?
12:16 <@waxwing> i just canceled a build, no?
12:16 < arubi> restart it, the previous one is almost done
12:16 < undeath> no worries, there'll be more :)
12:17 <@waxwing> i thought you were just saying it's a waste to run the build test, because it's going to be changed in a minute?
12:17 < arubi> you canceled 412791959 , but should've been 412788908
12:17 <@waxwing> clearly i didn't get it :)
12:18 < arubi> well it's not so bad.  undeath will be force pushing anyway eventually :)
12:19 <@waxwing> i still don't get what you meant by "you canceled undeath's push" ?
12:19 < arubi> you canceled this build : https://travis-ci.org/JoinMarket-Org/joinmarket-clientserver/builds/412791959
12:19 < arubi> but I wanted to cancel this one : https://travis-ci.org/JoinMarket-Org/joinmarket-clientserver/builds/412788908
12:19 < arubi> (see link above)
12:21 < arubi> the one I wanted you to cancel was the "AdamISZ authored and committed" weird thing.  the second one was "undeath authored and committed", which is the proper one
12:21 <@waxwing> oh; i was just reading and puzzling over that.
12:21 <@waxwing> why are there two builds being triggered on the same pR
12:22 < arubi> exactly - I'm confused too :)
12:22 < arubi> probably has to do with how https://github.com/JoinMarket-Org/joinmarket-clientserver/commit/1eefc46e48ad5b35cd6f7a766783f88a9f2ffe15 has two parents
12:24 <@waxwing> arubi, perhaps it's because undeath had marked his branch in .travis.yml, so he is building it, but joinmarket-org is building it as a pr too
12:24 <@waxwing> (but i'm not convinced by that)
12:24 < arubi> no that's not it.  it's really weird
12:25 < arubi> something about how the rebase was done.  the commit message is "Merge aad9184 into a2d2616" , where a2d2616 is the "update docs and versions for 0.3.5" commit
12:26 < arubi> in a clean pull --rebase this should never happen
12:27 <@waxwing> which commit has that message? is that at the start of then PR's new commits?
12:27 < arubi> yes     
12:28 < arubi> travis also says the branch being run is master, but it should be new-wallet.  blah
12:29 < undeath> travis is just as confused as we are
12:29 < arubi> so I'm wondering, if I pull from jmorg master now, will I get all these commits..
12:30 < undeath> I doubt that
12:30 < undeath> it's not merged
12:30 <@waxwing> i can't find the commit you're talking about arubi ; i looked in https://github.com/JoinMarket-Org/joinmarket-clientserver/pull/104/commits ; where should i be looking?
12:30 <@waxwing> anyway this all sounds fishy. may well be better to open new PR if the commits aren't looking exactly as they should.
12:31 < undeath> I think they do
12:31 < undeath> are they not?
12:31 < arubi> yea master is up to date for me.
12:31 < arubi> there are two commits
12:31 < arubi> https://github.com/JoinMarket-Org/joinmarket-clientserver/commit/1eefc46e48ad5b35cd6f7a766783f88a9f2ffe15
12:31 < arubi> no sorry, just this one
12:32 <@waxwing> where do you find it? i don't see it in https://github.com/JoinMarket-Org/joinmarket-clientserver/pull/104/commits
12:32 < arubi> yea, it's not there
12:32 < arubi> it's a merge commit of the 0.3.5 release into undeath's branch
12:32 < undeath> maybe it was before my last force push?
12:32 < arubi> do you see 1eefc46e48ad5b35cd6f7a766783f88a9f2ffe15 in your history?
12:33 < arubi> (I bet waxwing doesn't for the new-wallet branch he has)
12:33 < undeath> no, I don't have that commit
12:33 < arubi> now that's even weirder
12:34 < undeath> but is it something we need to worry about?
12:34 < undeath> the pr looks alright
12:34 < arubi> I don't think we'll be able to merge..
12:34 -!- puddinpop [~puddinpop@unaffiliated/puddinpop] has joined #joinmarket     
12:34 < undeath> where did you find that 1ee?
12:35 < arubi> right there in that link ^, but maybe you force pushed over it already
12:35 <@waxwing> arubi, but i still want to know how you got that link :)
12:35 < arubi> I got there from travis
12:35 < undeath> yes, something along that I think
12:35 < arubi> https://travis-ci.org/JoinMarket-Org/joinmarket-clientserver/builds/412791959 , see "commit"
12:35 <@waxwing> ah from travis. hmm.
12:36 <@waxwing> well but it would seem ... strange ... if the commits in the PR are not the ones that end up going into master after merge, no?
12:36 < undeath> no idea why I don't have that commit locally, but it doesn't really worry me
12:36 < arubi> yes..  maybe it's this one : https://github.com/JoinMarket-Org/joinmarket-clientserver/commit/b73418a685a2b93d065ec6542643a77d9043b6ff
12:36 < arubi> try to see if you have b73418a6 ..
12:36 < undeath> all the correct commits are in the pr and on the branch
12:36 < arubi> I see
12:37 <@waxwing> arubi, sorry to be dumb but what's the command to check if a commit is in this branch?
12:37 < undeath> I don't have b73418a685a2b93d065ec6542643a77d9043b6ff either
12:37 < undeath> git checkout 
12:37 < arubi> just git log and search for it
12:37 < arubi> `git log new-wallet` and '/' to search, then paste the commit
12:37 < arubi> (and enter of course)
12:38 <@waxwing> maybe git show? oh yes / is a thing there
12:38 <@waxwing> yeah i don't have b734
12:38 <@waxwing> so i'll wait until after the squash part and see where we stand :)
12:39 < arubi> alright.  shrodinger's commit
12:39 <@waxwing> well i mean we threw tons of crap at travis, right
12:39 < undeath> yes, I did
12:39 < arubi> and I thought I was abusing it with my silly games :)
12:40 < undeath> fun fact, my travis history doesn't have those commits https://travis-ci.org/undeath/joinmarket-clientserver/builds
12:40 < arubi> can you try `git reflog -a` , then search for those?
12:41 < arubi> (need the shortened hash)
12:41 < arubi> maybe it's the one that got dropped
12:41 < undeath> not there
12:41 < arubi> yea then I'm lost as to what's happening :)
12:42 < undeath> magic
12:42 < arubi> worst case, waxwing still has the whole thing pre-magic
12:42 < undeath> I'll be working off the aad9184 commit
12:42 < arubi> and can probably force push to undeath/new-wallet 
12:43 < undeath> nooooo
12:43 < arubi> yea not yet hehehe
12:49 < arubi> it's really interesting, and actually a good job interview exercise..  "tell me wtf is going on here : <show these two commits on travis\github>"
12:49 < arubi> not that I'd know how to answer it myself :)
12:50 < undeath> lol     
13:53 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Read error: Connection reset by peer]     
15:26 < undeath> I don't think squashing the commits is very viable
15:27 < undeath> I'm down to ~30 commits now but features aso are just wildly mixed, mostly commits are separated by files they touch
15:28 < undeath> doing commits defined by file groups seems more useful
17:01 -!- undeath [~undeath@unaffiliated/undeath] has quit [Quit: WeeChat 2.1]     
19:13 -!- StopAndDecrypt [~StopAndDe@unaffiliated/stopanddecrypt] has quit [Read error: Connection reset by peer]     
19:17 -!- StopAndDecrypt [~StopAndDe@unaffiliated/stopanddecrypt] has joined #joinmarket