2017-09-14 GnuCash IRC logs
01:02:46 *** pi_ has joined #gnucash
01:04:39 *** pi_ has quit IRC
01:17:15 *** Mechtilde has joined #gnucash
01:34:07 *** Mechtilde has quit IRC
01:42:54 *** tuxd00d has joined #gnucash
02:21:19 *** Groan has quit IRC
03:20:52 *** mrklintscher114 has quit IRC
03:20:54 *** gjanssens has joined #gnucash
03:20:54 *** ChanServ sets mode: +o gjanssens
03:23:11 <gjanssens> .
03:23:13 *** fabior has joined #gnucash
03:34:57 *** fekepp has joined #gnucash
03:36:37 *** mrklintscher114 has joined #gnucash
03:46:04 *** fekepp has quit IRC
04:03:22 *** bertbob has quit IRC
04:15:55 *** bertbob has joined #gnucash
04:19:02 *** bertbob has quit IRC
04:23:55 *** pilotauto has quit IRC
04:32:08 *** mreich has joined #gnucash
04:35:19 *** bertbob has joined #gnucash
04:46:38 *** rubdos has joined #gnucash
04:58:26 *** flips has quit IRC
05:01:26 *** fabior has quit IRC
05:02:13 *** mrklintscher115 has joined #gnucash
05:03:38 *** mrklintscher114 has quit IRC
05:08:13 *** fabior has joined #gnucash
05:24:05 *** flips has joined #gnucash
06:02:31 *** christopherlam has joined #gnucash
06:04:06 <christopherlam> .
06:10:21 *** rubdos has quit IRC
06:18:01 *** User has joined #gnucash
06:28:02 <christopherlam> gjanssens: I figure that overhauling transaction.scm Sorting/* is overdue, does the Accounts/Transaction Type Filter add value? I believe transaction.scm should be the swiss-army knife in extracting useful information from the database.
06:28:45 <christopherlam> gjanssens: I hope the Display/* changes also make sense
06:28:59 *** mikee has quit IRC
06:36:03 *** mikee has joined #gnucash
06:36:04 *** ChanServ sets mode: +o mikee
06:46:46 *** shoonya has joined #gnucash
06:49:47 *** Jimraehl1 has joined #gnucash
06:49:53 *** fabior has quit IRC
06:50:10 *** Jimraehl1 has quit IRC
07:11:44 *** mikee has quit IRC
07:11:54 *** mrklintscher116 has joined #gnucash
07:14:15 *** mrklintscher115 has quit IRC
07:15:55 *** mrklintscher117 has joined #gnucash
07:18:06 *** mrklintscher117 has quit IRC
07:18:12 *** mrklintscher116 has quit IRC
07:18:45 *** mikee has joined #gnucash
07:18:47 *** ChanServ sets mode: +o mikee
07:34:30 *** mikee has quit IRC
07:36:16 *** mrklintscher112 has joined #gnucash
07:37:24 *** mrklintscher113 has joined #gnucash
07:38:26 *** jotrago has quit IRC
07:39:27 *** mrklintscher112 has quit IRC
07:40:46 *** karelk_ has joined #gnucash
07:41:37 *** thecat has joined #gnucash
07:42:01 *** codesmythe has left #gnucash
07:42:15 *** mrklintscher114 has joined #gnucash
07:43:01 *** mikee has joined #gnucash
07:43:03 *** ChanServ sets mode: +o mikee
07:43:36 *** mrklintscher113 has quit IRC
07:43:58 *** mrklintscher115 has joined #gnucash
07:45:29 *** mrklintscher114 has quit IRC
07:45:51 *** mrklintscher116 has joined #gnucash
07:46:14 *** mikee has quit IRC
07:47:01 *** mrklintscher115 has quit IRC
07:48:42 *** rickoehn has joined #gnucash
07:52:47 *** mikee has joined #gnucash
07:52:48 *** ChanServ sets mode: +o mikee
07:54:09 <gjanssens> christopherlam: I'll have some time this evening to look at your changes. I'll give feedback then :)
08:14:12 *** thecat has quit IRC
08:38:15 *** rubdos has joined #gnucash
08:39:09 *** rubdos has quit IRC
08:39:30 *** Groan has joined #gnucash
08:53:16 *** shoonya has quit IRC
09:01:14 <warlord> .
09:19:09 *** christopherlam has quit IRC
09:25:56 *** Mechtilde has joined #gnucash
09:32:26 *** Mechtilde has quit IRC
09:42:25 *** Mechtilde has joined #gnucash
09:45:56 *** Mechtilde has quit IRC
09:50:08 *** fabior has joined #gnucash
10:11:23 *** codesmythe has joined #gnucash
10:18:41 *** codesmythe has left #gnucash
10:25:13 *** Groan has quit IRC
10:29:25 *** kael has joined #gnucash
10:37:36 *** Mechtilde has joined #gnucash
10:40:09 *** Groan has joined #gnucash
10:57:19 *** kael has quit IRC
10:58:17 *** kael has joined #gnucash
11:01:48 *** jotrago has joined #gnucash
11:17:48 *** kael has quit IRC
11:28:40 <lmat> it's big.
11:41:34 *** Mechtilde has quit IRC
11:43:10 *** mrklintscher117 has joined #gnucash
11:43:13 *** mrklintscher116 has quit IRC
11:56:26 <lmat> @jralls Nevermind about changing kvp to "flat".
11:56:26 <gncbot> lmat: Error: "jralls" is not a valid command.
11:56:40 <lmat> @tell jralls Nevermind about changing kvp to "flat".
11:56:40 <gncbot> lmat: The operation succeeded.
11:59:28 *** mreich has quit IRC
12:14:15 *** jralls has joined #gnucash
12:14:15 *** ChanServ sets mode: +o jralls
12:14:23 <jralls> .
12:14:23 <gncbot> jralls: Sent 1 day, 14 hours, and 46 minutes ago: <lmat> For what it's worth, I see this error sporadically locally, too. (the segmentation fault)
12:14:24 <gncbot> jralls: Sent 1 day, 2 hours, and 16 minutes ago: <lmat> as I'm working through changing the delimiter for kvp, I'm going through checking all the usages of KVP strings to make sure they're delimited properly (delimiters are hard-coded). Since I'm here, how bout I make kvp non-hierarchical; just a flat key-value pair store?
12:14:25 <gncbot> jralls: Sent 23 hours and 20 minutes ago: <lmat> I guess that would have to be implemented in phases: the first phase would be able to read kvp trees, but write flat kvps.
12:14:26 <gncbot> jralls: Sent 17 minutes ago: <lmat> Nevermind about changing kvp to flat .
12:14:52 <jralls> lmat: Too hard?
12:18:17 *** looters has joined #gnucash
12:18:17 <lmat> jralls: yes. It's big.
12:18:17 <looters> When disaster strikes...niggers go shopping
12:18:18 <looters> https://www.youtube.com/watch?v=uVee9A2IK0I
12:18:19 <looters> https://www.youtube.com/watch?v=AZkJzWFT6rA <== all niggers rofl
12:18:20 <looters> JOIN THE DISCUSSION dumniggaff3fjhrw.onion/6667
12:18:29 <looters> jralls mrklintscher117 jotrago Groan fabior mikee rickoehn User flips bertbob gjanssens tuxd00d Cuare jethrogb Trel xmaka Derperperd jonas lmat karelk Unhammer warlord Artefact2 puck meb O01eg chf g5pw redarrow CDB-Man_ CDB-Away_ entreprnr wget fiddlerwoaroof weasel Simon icasdri GabrieleV gncbot
12:18:33 *** looters has left #gnucash
12:20:44 *** looters_ has joined #gnucash
12:21:36 <looters_> When disaster strikes...niggers go shopping
12:21:37 <looters_> https://www.youtube.com/watch?v=uVee9A2IK0I
12:21:38 <looters_> https://www.youtube.com/watch?v=AZkJzWFT6rA <== all niggers rofl
12:21:39 <looters_> JOIN THE DISCUSSION dumniggaff3fjhrw.onion/6667
12:21:46 <looters_> jralls mrklintscher117 jotrago Groan fabior mikee rickoehn User flips bertbob gjanssens tuxd00d Cuare jethrogb Trel xmaka Derperperd jonas lmat karelk Unhammer warlord Artefact2 puck meb O01eg chf g5pw redarrow CDB-Man_ CDB-Away_ entreprnr wget fiddlerwoaroof weasel Simon icasdri GabrieleV gncbot
12:21:50 *** looters_ has left #gnucash
12:23:44 *** fell has joined #gnucash
12:23:59 <lmat> jralls: I was just working through parts of it, and it seems pretty big, but perhaps I was just at the end... do you thnk it's a big undertaking?
12:25:53 <lmat> jralls: A long while ago, I think you hinted that KVP should not exist. (am I remembering correctly?) It is a poor man's easy solution to database versioning. If it didn't exist, how would we handle the resulting database versioning situation: non-trivial backward compatibility, etc.?
12:31:22 <jralls> I don't like KVP because it violates class integrity: Anything can come along and add a member variable to a class without any changes to a class's declaration. That becomes a problem for a transactional backend because an object's save routine won't necessarily know that the "extra" KVP needs to be saved too.
12:33:20 <jralls> I had to go through the whole code-base and find all of the instances where that had been done and make sure that the code marked the "owning" object dirty and committed it. That's very fragile of course.
12:33:24 *** Groan has quit IRC
12:33:46 <lmat> jralls: ouch
12:34:19 <jralls> The qof_instance_set abstraction made it less fragile, but it's possible for someone to carelessly break it again.
12:35:52 <lmat> jralls: What is the size of changing KVP to be flat in your opinion?
12:37:57 <lmat> jralls: (Am I right to be intimidated, or should I push on?)
12:38:35 <jralls> The hard part would be fixing the backends to read both and write flat. It doesn't even matter if it's internally hierarchical, though it's cheaper to search a single vector than to search a nest of them.
12:41:00 <jralls> No, don't be intimidated, just think about how to break the job up into little chunks. Massive changes done all at once are inherently hard to accomplish and error-prone.
12:42:42 <jralls> But little changes supported with good unit tests can accomplish massive changes safely.
12:43:12 <lmat> jralls: Okay, thanks.
12:44:52 <jralls> I'd approach it by taking a single hierarchical use and flattening it. Then another and another until they're all gone. After that it's pretty easy to just remove the frame and list flavors of KVPValue.
12:46:04 <lmat> Supported by unit tests, too :-)
12:50:16 <jralls> Of course.
12:53:07 <jralls> Hmm, there's one more piece of that puzzle: The backends will need to be able to detect the change in representation and convert a hierarchical representation in the data into a flat representation in memory.
12:53:31 *** marusich has joined #gnucash
12:54:03 <lmat> jralls: I did this for the xml backend, and it's straightforward. In the SQL backends, it's already flat, just don't parse it.
12:54:41 <jralls> And the "previous branch" will need to be able to read a flat representation and make it hierarchical.
12:55:30 <lmat> ummm
12:55:37 <jralls> No, the SQL backend creates a GUID for a frame or a list and uses that GUID as the object_guid for the records of values "inside" the frame or list.
12:56:09 <lmat> jralls: Ah, okay. I was going on what I've seen in sqlite3, not in code.
12:56:43 <lmat> Come to think of it, I should have known better even based on what I've seen. The keys weren't rooted.
12:56:55 <jralls> Right.
12:57:52 <lmat> So version x needs to be able to read files produced by x+1?
13:01:29 <jralls> Yes, where "x" is the middle number in a version. So if you look at it from a git branch view, maint should be able to read a file written by unstable and unstable should be able to read a file written by master.
13:01:59 <jralls> Not necessarily every release from the older branch, of course, just the last one.
13:03:32 <lmat> I see. That should be doable.
13:06:03 *** dum has joined #gnucash
13:06:50 *** mrklintscher117 has quit IRC
13:12:59 *** cyphase has joined #gnucash
13:33:47 *** Groan has joined #gnucash
13:58:29 *** fabior has quit IRC
14:12:48 *** gncbot sets mode: +o fell
14:13:52 *** frakturfreak has joined #gnucash
14:19:56 *** marusich has quit IRC
14:21:42 *** cyphase has quit IRC
14:23:03 *** cyphase has joined #gnucash
14:24:51 <fell> lmat: in xml files we have e.g. <gnc:book version="2.0.0">. I think, that should be incremented on schema changes.
14:27:03 <lmat> fell: Thank you for pointing that out.
14:27:44 <fell> ... and checked on reading.
14:35:19 <jralls> Be very careful with that. Remember that our parser is a hand-rolled, everything hard-coded SAX-like parser. It's very fragile, which is part of the reason that KVP gets used so much: By burying changes in <slot> elements the parser can be tricked into accepting data without writing new handlers.
14:41:55 <warlord> It also enables easier backwards-compatibility, because generally an older version will properly read and re-write unknown KVP, whereas it might not properly rewrite unknown XML tags.
14:42:36 *** Groan has quit IRC
14:43:44 <jralls> It can't rewrite unknown XML tags. It crashes if it finds one.
14:44:34 <jralls> Well, not crashes. It treats unknown XML tags as an ill-formed file and refuses to load it.
14:50:59 <warlord> Right. For some types of new data it would be "better" to read and re-write vs fail to read at all.
14:51:12 <warlord> For other cases, that's absolutely the right thing to do.
14:54:30 <jralls> Yeah, unfortunately some of those latter cases the new data are in Kvp and the parser blindly accepts them.
14:56:11 <warlord> That's what the version numbers were supposed to be for, to add a flag that says "you must understand X"
15:00:40 <jralls> Yes, but that came later, though I doubt there'd be any point to going back through the existing KVP and marking features on it; the GnuCash versions that can't handle it are too old and anyway don't support the "features" feature.
15:01:02 <warlord> Indeed.
15:19:26 *** fbruetting has joined #gnucash
15:31:03 *** tuxd00d has left #gnucash
15:57:08 *** mreich has joined #gnucash
15:57:16 <jralls> lmat: I found the real problem with cmake dist and fixed it, now travis is back to failing only on arch autotools segfaulting in guile. It passed when I re-ran it.
16:00:29 *** fabior has joined #gnucash
16:25:51 <gjanssens> well done jralls
16:26:11 <jralls> gjanssens: For?
16:26:33 <gjanssens> Finding the cmake dist issue :)
16:27:02 <gjanssens> I have just finished reviewing Chris(topher Lam)'s two PR's. Unfortunately both still need work before they can be added
16:28:13 <gjanssens> And the errors that now appear in the transaction report worry me. It seems the OptionDB associated with a running report can change while it's open
16:29:14 <gjanssens> It only had small impact until now, but with Chris' changes the issue seems to have become much worse.
16:30:10 <jralls> Eww, but not surprising. Keeping track of what's going on in the optiondb isn't easy.
16:30:49 <gjanssens> Considering it's moved up and down between C and guile, it's not surprising indeed.
16:31:46 <gjanssens> I remember I attempted tracking this down before but ran out of time before getting anywhere near the cause.
16:32:34 <gjanssens> I reported my preliminary findings in bug https://bugzilla.gnome.org/show_bug.cgi?id=647805 back then
16:35:15 <gjanssens> Anyway
16:36:23 <gjanssens> What's the current status of the 2.7 progress jralls ?
16:37:35 *** codesmythe has joined #gnucash
16:39:09 *** frakturfreak has quit IRC
16:39:53 <codesmythe> gjanssens: Do you know if the python-bindings test works in the presence of an install for autotools on master?
16:41:27 <codesmythe> The essential problem is that we pick up the installed environment file in the test, and use the module path from that.
16:41:45 <jralls> Fixing the cmake macros problem also fixed ninja distcheck, so I'm trying to get test-userdata-dir to pass on MacOS. Once I've got that sorted I'll be ready to branch and release.
16:42:07 <codesmythe> So the test same some modules linked in from the the build dir, and then loads the same-named modules from the install
16:42:34 <codesmythe> Er, So the test uses some modules....
16:46:21 <gjanssens> codesmythe: I suspected it was something like that. I'll run the python-bindings test under autools and report back
16:58:06 *** Mechtilde has joined #gnucash
16:58:27 <gjanssens> jralls: I see last night's nightly build has suddenly become about 80Mb bigger (which makes it almost double the size). Any idea what changed ?
17:00:44 <gjanssens> codesmythe: the python test fails under autotools as well on my system
17:01:47 <gjanssens> But it fails regardless of whether gnucash is installed or not
17:02:42 <gjanssens> There should be no interference from other installs. My cmake build uses a different prefix and I have no system-wide gnucash installed.
17:03:24 <codesmythe> gjanssens: Does it segfault like the cmake build test does?
17:03:46 <gjanssens> It crashes on a double free of the GncDateFormat vector
17:04:29 <gjanssens> I don't know exactly how it crashes on cmake. Let me try to catch that
17:05:26 <codesmythe> That's the same segfault
17:05:38 <gjanssens> Ok
17:06:21 <codesmythe> Looks like thats what you get when you mix build libgncmod-engine.so and installed libgncmod-engine.so :-)
17:07:12 <jralls> gjanssens: That's Monday's build. It looks like my change to the scheduled task to run build_package.ps1 didn't work.
17:07:13 <gjanssens> On a cmake build yes. I don't understand though why my autotools build also has this without having libgncmod-engine.so installed.
17:07:51 <codesmythe> gjanssens: Ah, good point.
17:08:56 <gjanssens> Is there a safer way to define GncDateFormat than as a static ? Some kind of singleton design pattern that can be used in C++ ?
17:09:29 <gjanssens> ISTR I have been chasing this exact same issue before while writing this code.
17:10:10 <gjanssens> I believe jralls managed to fix it then but apparently we didn't discuss this on IRC as I don't find it back in my IRC logs
17:12:41 *** rickoehn has quit IRC
17:12:46 *** rickoehn has joined #gnucash
17:12:54 <jralls> What instance of GncDateFormat are you referring to?
17:15:25 *** fabior has quit IRC
17:17:11 <gjanssens> jralls: the vector of date formats that's being initialized in libgnucash/engine/gnc-datetime.cpp:73
17:26:33 <gjanssens> codesmythe, jralls: the conversation was on IRC after all, but past my local buffer: https://lists.gnucash.org/logs/2017/04/25.html#T15:26:46
17:26:42 <jralls> OK. It's not static in the sense that a static variable is. It's a class variable as opposed to a member variable, so there's only one instance rather than one for each instance of GncDate. It's public, so it's available in any C++ file that includes gnc-datetime.hpp as GncDate::c_formats.
17:28:43 <gjanssens> That link above was to jralls' eureka moment. The conversation starts a few days earlier https://lists.gnucash.org/logs/2017/04/23.html#T11:48:13
17:29:18 <gjanssens> It's bedtime here... so see you later
17:30:28 <jralls> Good night, gjanssens.
17:31:14 *** gjanssens has quit IRC
17:37:48 <jralls> codesmythe: The "eureka moment" was really gjanssens's, finding that c_formats was getting created twice. That means that the class is getting defined twice, and that leads to "undefined behavior" in C++. Make sure that the python tests aren't sourcing any c++ files that are also in libraries linked to the python bindings.
17:42:52 *** Mechtilde has quit IRC
17:50:15 *** ArtGravity has joined #gnucash
17:52:02 *** rickoehn has quit IRC
17:52:24 <codesmythe> jralls, gjanssens: Thanks for the info. I'll continue debugging.
17:53:59 <jralls> codesmythe: Separate subject, I'm having trouble with TARGET_COMPILE_OPTIONS(test-userdata-dir PRIVATE ${OSX_EXTRA_COMPILE_FLAGS}). Is there something about test targets that's getting in the way?
18:01:40 <codesmythe> jralls: It might be that TARGET_INCLUDE_DIRECTORIES() is getting in the way.
18:03:22 <jralls> OK, so trying target_compile_definitions...
18:05:20 <jralls> No joy, but maybe I'm looking at the wrong thing.
18:07:54 <jralls> Yes, I am. OSX_EXTRA_COMPILE_FLAGS was getting set. Looks like there's something else that I need to set to get -DMAC_INTEGRATION.
18:12:06 <jralls> warlord: Is it possible to remove the search link from the mailman webpages? Yet another earnest soul is reporting the broken link on gnucash-user.
18:30:13 *** Cuare has quit IRC
18:36:30 *** pilotauto has joined #gnucash
18:39:05 <jralls> @tell gjanssens: I've worked out how to make test-userdatadir and test-userdatadir-invalid-home pass on MacOS, but I don't think that those are very useful tests. I'm tempted to simply block them on MacOS isntead. What do you think?
18:39:05 <gncbot> jralls: The operation succeeded.
18:50:07 *** Cuare has joined #gnucash
18:56:35 *** christopherlam has joined #gnucash
18:56:40 <christopherlam> .
18:57:26 *** mreich has quit IRC
18:57:31 <christopherlam> help! any git wizards in here? I completely messed up my branch
19:03:43 <jralls> christopherlam: No problem. You can use git reflog and git reset to return to any previous state. There's only one thing you can't recover from: Deleting work that hasn't been committed.
19:05:54 <jralls> christopherlam: Read https://git-scm.com/book/en/v2/Git-Tools-Revision-Selection for how to find the state you want and https://git-scm.com/book/en/v2/Git-Tools-Reset-Demystified for how to use git reset to get there.
19:06:22 <jralls> christopherlam: Then read the rest of the book so that you can be a git wizard too. ;-)
19:07:42 <christopherlam> I think what happened: gnucash/gnucash --fork--> christopherlam/gnucash --branch--> christopherlam/gnucash/patch-1 ------> amend my patch-1 with frequent commits ------> patch-1 otherwise gets stale ------>
19:08:15 <christopherlam> git pull --rebase origin master ---> will rebase patch-1 onto christopherlam/patch-1
19:09:15 <christopherlam> with the new directory structure my old commits will die I think, which is absolutely fine
19:15:37 <jralls> christopherlam: Did you do all of that in Github, at the command line, or in some graphical tool?
19:16:01 <christopherlam> most in github... i'm a newbie in all that
19:16:22 <christopherlam> looks like I've come to decorate some picture frame in a warship in a middle of a storm while the navy is undergoing some massive reorganisation while Trump is being sworn it
19:16:24 <christopherlam> looks like I've come to decorate some picture frame in a warship in a middle of a storm while the navy is undergoing some massive reorganisation while Trump is being sworn in
19:16:32 <jralls> @tell gjanssens: The difference between the 08-09 and the 11-09 builds is that the latter has the documentation in it.
19:16:32 <gncbot> jralls: The operation succeeded.
19:17:29 <christopherlam> I'd think easiest to me is to abandon my branch, and allow one of you to upload a single .scm to the relevant location using your credentials
19:18:20 <jralls> christopherlam: I'm a submariner. We just dive in a storm, it's nice and peaceful at 500'. Makes redecorating comfortable and we don't get much news so we can ignore politicians and admirals. ;-)
19:19:34 <christopherlam> well sir, this sailor has fubar his work, sir
19:21:00 <jralls> christopherlam: We'd rather not. Git PRs are much easier to integrate and to give credit where it's due.
19:22:40 <christopherlam> hm if you wouldn't mind, how do I fix https://github.com/Gnucash/gnucash/pull/177
19:28:04 *** User has quit IRC
19:29:04 <jralls> Do you have the repository cloned on your local computer? If not, do so. What OS are you using?
19:29:28 <christopherlam> yes, on win10
19:29:37 <christopherlam> it's the git pull --rebase origin master that created this mess... i think i should've done git remote -add upstream https://github.com/gnucash/gnucash before rebasiing
19:31:09 <jralls> Is 'origin' your github repo?
19:31:54 <christopherlam> well it was what i cloned the official one a few weeks ago while starting work
19:32:30 <jralls> Hmm, different tack: What is the output of `git remote -v`?
19:32:34 <christopherlam> i think it's best to restart from scratch... another clone of official, and do it right. it just means losing prev commits which is no trouble
19:33:22 <christopherlam> It was as follows
19:33:24 <christopherlam> origin http://www.github.com/christopherlam/gnucash (fetch)
19:33:24 <christopherlam> origin http://www.github.com/christopherlam/gnucash (push)
19:33:26 <christopherlam> until I've added remote after this mess
19:33:27 <christopherlam> origin http://www.github.com/christopherlam/gnucash (fetch)
19:33:29 <christopherlam> origin http://www.github.com/christopherlam/gnucash (push)
19:33:30 <christopherlam> upstream https://github.com/gnucash/gnucash (fetch)
19:33:32 <christopherlam> upstream https://github.com/gnucash/gnucash (push)
19:34:25 <jralls> OK. And you ran `git pull --rebase origin master` with patch-1 checked out?
19:35:27 <christopherlam> correct
19:37:29 <jralls> OK. Do `git checkout patch-1` if you're not already in that branch, then do `git reflog` and find the commit just before the rebase. It will have a tag that looks like HEAD{n} where n is a number.
19:38:07 <jralls> You can then `git reset --hard HEAD{n}` with the same "n" and the rebase will be undone.
19:39:50 <jralls> Now `git checkout master; git checkout-b fullname-filter; git checkout master; git reset --hard HEAD^`. (I'm assuming there that your local master branch is in sync with your Github one.)
19:41:39 <jralls> That will move commit efce898 out of the way. Now from the master branch you can `git pull --ff-only upstream master; git push -f origin master` to get both your local and github master branches in sync with the github repo.
19:41:46 *** tuxd00d has joined #gnucash
19:44:40 <jralls> With that done you're ready to do the rebase that gjanssens asked for: `git rebase master patch-1`. You may have conflicts to resolve. Once that's done you can start fixing up history with git rebase -i.
19:48:59 *** ArtGravity has quit IRC
19:50:24 <jralls> Time for me to go.
19:50:27 *** jralls has quit IRC
20:20:58 *** fbruetting has quit IRC
21:26:29 *** User has joined #gnucash
21:31:54 *** kael has joined #gnucash
21:49:43 *** User has quit IRC
21:56:40 *** kael has quit IRC
22:18:31 *** Cuare has quit IRC
23:04:37 *** kael has joined #gnucash