2013-05-30 GnuCash IRC logs
00:23:57 *** Ryan has joined #gnucash
00:46:24 *** naught101 has joined #gnucash
00:54:52 *** naught102 has quit IRC
00:55:40 *** naught102 has joined #gnucash
00:56:50 *** naught101 has quit IRC
00:57:40 *** naught101 has joined #gnucash
01:04:56 *** naught101 has quit IRC
01:06:02 *** naught102 has quit IRC
01:37:02 *** ecocode has joined #gnucash
02:02:07 *** Ryan has quit IRC
02:20:32 *** john has joined #gnucash
02:20:32 *** gncbot sets mode: +o john
02:25:49 *** gour has joined #gnucash
02:45:37 *** john has quit IRC
02:49:47 *** Topcat has joined #gnucash
02:56:54 *** Ryan has joined #gnucash
03:13:05 *** fell has joined #gnucash
03:13:05 *** gncbot sets mode: +o fell
03:34:11 *** Topcat has quit IRC
03:34:43 *** Topcat has joined #gnucash
03:39:49 *** Topcat has quit IRC
03:40:34 *** Topcat has joined #gnucash
03:45:35 *** Topcat has quit IRC
03:45:58 *** Topcat has joined #gnucash
03:51:04 *** Topcat has quit IRC
03:51:26 *** Topcat has joined #gnucash
04:01:34 *** Topcat has quit IRC
04:02:10 *** Topcat has joined #gnucash
04:07:11 *** Topcat has quit IRC
04:07:44 *** Topcat has joined #gnucash
04:17:43 *** Topcat has quit IRC
04:18:20 *** Topcat has joined #gnucash
04:21:32 *** aqua___ has joined #gnucash
04:28:24 *** Topcat has quit IRC
04:28:47 *** Topcat has joined #gnucash
04:33:51 *** Topcat has quit IRC
04:34:25 *** Topcat has joined #gnucash
04:45:25 *** Topcat has quit IRC
04:45:47 *** Topcat has joined #gnucash
04:50:50 *** Arafangion has joined #gnucash
04:56:04 *** Arafangion has quit IRC
04:58:13 *** calbasi has joined #gnucash
05:06:04 *** Topcat has quit IRC
05:06:39 *** Topcat has joined #gnucash
05:10:29 *** aqua___ has quit IRC
05:37:25 *** Topcat has quit IRC
05:38:01 *** Topcat has joined #gnucash
05:42:17 *** nomeata has joined #gnucash
06:24:50 *** Topcat has quit IRC
06:25:24 *** Topcat has joined #gnucash
06:37:32 *** Topcat has quit IRC
06:38:07 *** Topcat has joined #gnucash
06:43:13 *** Topcat has quit IRC
06:43:53 *** Topcat has joined #gnucash
06:48:56 *** Topcat has quit IRC
06:49:30 *** Topcat has joined #gnucash
06:57:36 *** Jimraehl2 has left #gnucash
07:00:59 *** Jimraehl2 has joined #gnucash
07:19:10 *** Topcat has quit IRC
07:19:32 *** Topcat has joined #gnucash
07:24:35 *** Topcat has quit IRC
07:25:16 *** Topcat has joined #gnucash
07:37:10 *** ecocode` has joined #gnucash
07:37:10 *** ecocode has quit IRC
07:53:59 *** Topcat has quit IRC
07:54:21 *** Topcat has joined #gnucash
07:59:23 *** Topcat has quit IRC
07:59:46 *** Topcat has joined #gnucash
08:01:33 *** aqua___ has joined #gnucash
08:03:20 *** aqua___ has quit IRC
08:19:31 *** Topcat has quit IRC
08:19:55 *** Topcat has joined #gnucash
08:24:56 *** Topcat has quit IRC
08:25:29 *** Topcat has joined #gnucash
08:30:32 *** Topcat has quit IRC
08:31:04 *** Topcat has joined #gnucash
08:36:07 *** Topcat has quit IRC
08:36:39 *** Topcat has joined #gnucash
08:46:43 *** Topcat has quit IRC
08:47:05 *** Topcat has joined #gnucash
08:55:17 *** Bodhi-Baum has joined #gnucash
09:02:18 *** Topcat has quit IRC
09:02:51 *** Topcat has joined #gnucash
09:07:51 *** Topcat has quit IRC
09:08:14 *** Topcat has joined #gnucash
09:18:19 *** Topcat has quit IRC
09:18:53 *** Topcat has joined #gnucash
09:29:00 *** Topcat has quit IRC
09:29:32 *** Topcat has joined #gnucash
09:34:36 *** Topcat has quit IRC
09:34:59 *** Topcat has joined #gnucash
09:40:00 *** Topcat has quit IRC
09:40:22 *** Topcat has joined #gnucash
09:50:29 *** Topcat has quit IRC
09:50:51 *** Topcat has joined #gnucash
10:00:56 *** Topcat has quit IRC
10:01:29 *** Topcat has joined #gnucash
10:17:04 *** gour1 has joined #gnucash
10:17:58 *** benoitg has joined #gnucash
10:22:15 *** gour has quit IRC
10:24:53 *** ecocode` has quit IRC
10:35:24 *** benoitg has quit IRC
10:35:33 *** benoitg has joined #gnucash
10:44:39 *** Topcat has quit IRC
10:45:12 *** Topcat has joined #gnucash
10:58:51 *** nomeata has quit IRC
11:09:19 *** Ryan has quit IRC
11:29:49 *** Bodhi-Baum has quit IRC
11:37:40 *** Ryan has joined #gnucash
11:37:44 *** john has joined #gnucash
11:37:45 *** gncbot sets mode: +o john
11:45:49 *** Topcat has quit IRC
11:46:26 *** Topcat has joined #gnucash
11:56:31 *** Topcat has quit IRC
11:57:04 *** Topcat has joined #gnucash
11:59:27 *** aqua___ has joined #gnucash
12:12:25 *** Topcat has quit IRC
12:13:04 *** Topcat has joined #gnucash
12:13:41 *** aqua___ has quit IRC
12:18:27 *** arrainey has joined #gnucash
12:27:58 *** jmd has joined #gnucash
12:39:10 *** Topcat has quit IRC
12:39:25 *** Krzysiek_K has joined #gnucash
12:39:49 *** Topcat has joined #gnucash
12:41:03 <warlord> john: you here?
12:41:20 <john> Hi, Derek.
12:41:39 <warlord> Hey, quick git question -- what's the best way to reverse a git commit (that's not been pushed anywhere)
12:41:57 <warlord> I'm happy with either 'reverse' or 'remove' the commit.
12:42:03 <warlord> (it's the last commit)
12:42:46 <john> git reset HEAD^
12:43:41 <warlord> ah, great.. thanks.
12:44:09 <john> That will undo the commit and leave the source tree and index as if you hadn't done the commit. Use --hard to reset completely to the previous commit and --soft to unset the index but leave the tree changed.
12:50:15 <warlord> thanks. it was good enough.
12:58:27 <john> You're welcome.
13:09:01 *** arrainey has quit IRC
13:09:37 *** arrainey has joined #gnucash
13:15:25 *** Topcat has quit IRC
13:15:48 *** Topcat has joined #gnucash
13:21:20 *** Topcat has quit IRC
13:21:54 *** Topcat has joined #gnucash
13:25:32 *** jmd` has joined #gnucash
13:25:33 *** jmd has quit IRC
13:35:09 *** Topcat has quit IRC
13:35:43 *** Topcat has joined #gnucash
13:45:11 *** arrainey has quit IRC
13:45:46 *** arrainey has joined #gnucash
13:55:58 *** Topcat has quit IRC
13:56:32 *** Topcat has joined #gnucash
14:04:06 *** jmd` has quit IRC
14:09:58 *** john has quit IRC
14:10:42 *** benoitg has quit IRC
14:11:45 *** john has joined #gnucash
14:11:46 *** gncbot sets mode: +o john
14:16:58 *** Topcat has quit IRC
14:17:21 *** Topcat has joined #gnucash
14:17:41 *** benoitg has joined #gnucash
14:18:20 *** jmd has joined #gnucash
14:22:52 *** nomeata has joined #gnucash
14:28:03 *** benoitg has quit IRC
14:36:57 *** arrainey has quit IRC
14:37:32 *** arrainey has joined #gnucash
14:42:33 *** arrainey has quit IRC
14:43:08 *** arrainey has joined #gnucash
14:43:49 *** benoitg has joined #gnucash
14:49:50 *** ecocode has joined #gnucash
14:57:12 *** Topcat has quit IRC
14:57:34 *** Topcat has joined #gnucash
15:02:22 *** arrainey has quit IRC
15:17:21 *** Topcat has quit IRC
15:17:43 *** Topcat has joined #gnucash
15:24:28 *** Bodhi-Baum has joined #gnucash
15:27:46 *** Topcat has quit IRC
15:31:38 *** Bodhi-Baum has quit IRC
16:15:58 *** benoitg1 has joined #gnucash
16:19:22 *** benoitg has quit IRC
16:37:38 *** fell has quit IRC
16:56:32 <warlord> john: ping? got time for another git question?
16:57:42 <john> Sure
16:58:08 <warlord> Do push/pull push/pull all branch information, too?
16:59:09 <warlord> E.g., if I have a clone and create a branch, how do I make sure that branch gets pushed back up to the remote? Will a normal 'push' do that? Do I have to be working in that branch for the push to succeed in creating the 'remote branch'?
16:59:49 <john> By default (meaning no args), push pushes everything to origin and pull *fetches* everything from origin and *merges* the current branch.
16:59:49 <warlord> (non-gnucash-related: I'm going to be setting up a bunch of vendor branches in a repo to track some upstream packages and want to make sure those branches exist in the server repo, not just my local copy)
17:00:41 <warlord> then what does git push --all do differently?
17:01:15 <warlord> (or --mirror)
17:01:20 <john> The *first time* you push a new branch you either have to be checked out in
17:01:29 <warlord> Clearly my brain hasn't completely groked git, yet
17:01:57 <john> the local one or explicitly push it: git push origin new_branch.
17:02:01 <john> ;-)
17:02:24 <john> Have you looked at pro-git yet? It's free online, but I find the dead trees version
17:02:30 <john> to be quite helpful.
17:02:35 <warlord> I have not..
17:02:51 <warlord> I'm trying to pick stuff up as I go along.. But perhaps it would be better to sit down for a day or three and read.
17:03:19 <warlord> For example, I did a test with a vendor branch but didn't try to push that up to an origin
17:03:39 <john> The book link is at http://git-scm.com/documentation, which also has a link to the "reference manual" which is really the man pages.
17:04:55 <warlord> yeah, I can read the man pages, but they dont provide enough background to understand all the terminology.
17:05:52 <warlord> For example, reading the git-push man page, I don't grok the real difference between --all and --mirror in the description (around line 61)
17:06:03 <john> You have to be paying attention to remote names when you do vendor branches. If you start off by cloning somewhere, that's going to be origin unless you change it. IIRC, if you pull from a different remote after setting up your local repo, that branch gets set up to push and fetch to where you pulled it from.
17:07:27 <warlord> Luckily I can start with an empty repo on the server.. and make an initial commit with an effectively empty repo. That will let me create multiple (vendor) branches from an empty repo and merge them together into master
17:08:36 <john> You don't need a server. You can just have a bunch of directories in ~ and push and pull between them.
17:09:10 <warlord> I know, but in this case there will be a server. In the meantime I've been testing locally using file:/// URIs
17:09:40 <warlord> I'm just trying to understand the fundamentals to make sure the on-server remote gets all the necessary branches pushed to it.
17:11:08 <john> Back to push --all v. push --mirror: The first one just pushes all of the branches to wherever (origin by default), and the second pushes everything -- branches, remotes, tags -- whatever is under .git/refs -- to wherever.
17:11:51 <john> You don't even need file:///URIs. Git understands file names and paths just fine.
17:12:45 <warlord> When I tried it, it didn't like relative paths.
17:12:59 <warlord> (but maybe because I specified file://../../....)
17:13:52 <warlord> Okay, so --mirror pushes remotes.. So if I do a git remote add ..., a git push --mirror will send that remote configuration info up to the origin?
17:13:54 <john> Oh. That's not a well-formed URI. The file: scheme doesn't understand relative paths. Just pass the path to git: git clone foo.
17:14:29 <john> >mirror: Yes.
17:14:46 <warlord> But there doesn't appear to be a way to *pull* those remote configurations.
17:14:59 <warlord> At least, I couldn't figure out any way to do that.
17:15:08 <warlord> clone --mirror set up a bare repo
17:15:18 <warlord> and there is no 'pull --mirror'
17:16:18 <john> Yes, that's right. Remotes aren't cloned, they have to be created explicitly.
17:16:57 <john> I've never messed with push --mirror, I don't know that it will mirror the config where the remote URL lives.
17:17:58 <john> It
17:18:12 <john> It's also not mentioned in Pro Git.
17:18:34 <warlord> Okay.. That rules out a distributed method of using subtree merging.
17:18:58 <warlord> (which is fine, I dont think I need it for my use case)
17:20:19 <john> Oh, that's another thing I haven't messed with in a long time. But there's a project I played with a couple of months ago that set up its dependencies as subtrees. It was a bit of a pain finding all of the subtree directories and updating them.
17:21:03 <john> Sorry, sub*module*s, not subtrees.
17:21:18 <warlord> Well, there'
17:21:21 <warlord> s always 'repo' ;)
17:21:42 <warlord> But that's doesn't help tracking an upstream as a 'vendor' dependency, with local changes.
17:24:59 <john> I do do that. Create a remote, fetch (don't pull) it, and create a tracking branch on the remote branch you want to adjust. You can either modify the tracking branch directly (be sure to change the "push" URI to origin if you're going to push it) or create a branch off of the tracking branch for your changes.
17:25:55 <warlord> You just lost me.
17:26:52 <john> Where?
17:27:48 <warlord> let's say you have a repo at ssh://server/productA, another at ssh://server/productB, and then your main repo at ssh://server/MyProject
17:28:16 <warlord> Now let's say that 'master' on productA is just tracking product A releases. So every time pA gets a new release, you import it into that repo.
17:28:21 <warlord> Same thing for product B..
17:30:41 <john> OK, are you using the code in either ProductA or ProductB directly in your project or are they just dependencies?
17:31:24 <john> And are you pushing your local changes to them to your own bare repo (e.g. on Github)?
17:31:25 <warlord> Now in MyProject I want to pull from pA and pB, tracking them in my tree, but applying local changes that only appear in MyProject but don't get pushed back to pA or pB..
17:32:01 <warlord> The issue is that ssh://server/* are all bare repos.. I would want to do all my work in clones on my desktop.
17:32:51 <warlord> So when I set up the pA and pB remotes in my local clone of MyProject, there's no way I can push that remote config up to 'server' and allow another developer to do the pA or pB merges in the future.
17:34:33 <warlord> I'm not sure I understand the question: "using the code directly or are they just dependencies?"
17:35:18 <warlord> I think I'm using the code directly, because I'm making changes to their code... But i want to be able to track their future changes and merge it into mine (which is why I really want to use a vendor branch)
17:35:51 <john> Is the ProjectX code compiled directly into MyProject or does MyProject #include its headers and link to its shared library?
17:36:11 <warlord> Yes
17:36:41 <john> That was an either-or question...
17:37:10 <john> I'll try a different way of asking:
17:38:11 <warlord> '
17:38:55 <john> Do you build ProjectX (./autogen.sh && ./configure && make && make install) in ~/project_x or do you have it as part of MyProject's source tree so that you do only one build?
17:40:39 <warlord> The latter.
17:41:02 <warlord> (although it still might include an autgen; configure; make by itself)
17:42:59 <warlord> But I don't see 'how it gets built' as important. Let me try a different way to present the issue. Let's assume for a moment that gnucash really was tied more closely to QOF. We would want to track QOF updates, but we've got our own extensions and bug fixes that we want in our code that aren't upstream..
17:43:27 <warlord> Further assume QOF doesn't have a GIT repo; we only get periodic releases from them.
17:43:57 <warlord> So we create our own tracking repo for QOF, and we want to pull it into GnuCash and then apply our local changes (bug fixes, enhancements, etc).
17:44:14 <warlord> Now, when QOF makes a new release, we want to merge that into our code (through the tracking repo)..
17:44:41 <warlord> Whether QOF has its own configure;make or whether it's built as part of gnucash is sort of irrelevant, isn't it?
17:46:52 <warlord> Now based on this, assume we'd want multiple developers to be able to perform the QOF Update->GnuCash merge..
17:47:00 <john> Well, stipulating that you're applying periodic tarballs makes it really ugly no matter what else is going on because its almost guaranteed that there will be conflicts every time you rebase your modifications.
17:47:04 <warlord> *THAT* is the configuration I haven't figured out how to set up.
17:47:20 <warlord> Sure.. but sometimes that's the way life works.
17:47:35 <warlord> In my real use case all I get are periodic tarballs.
17:48:05 <warlord> BIAB -- I need to go feed my child.
17:48:30 <john> OK.
17:50:20 *** gour1 has quit IRC
17:56:52 *** kpreid has quit IRC
17:57:40 *** Ryan has quit IRC
17:57:56 <john> Let's just go over the way you'd do this if you kept a separate repo for the dependency. You'd do that by git initiating a working repo, creating a "vendor" branch in it (it's still empty) un-tar-ring the tar-ball in the "vendor" branch and committing everything (`git add .; git commit -m "Release Foo.x.y"`). Now rebase 'vendor' onto 'master' and make your changes, making a bunch of nice commits.
18:02:51 <john> Time passes, and foo have a new release. Checkout vendor, rm -r * (*not* git rm!), and unpack the tarball. You'll need to look for added, deleted, and renamed files and fix them manually. Commit the result to "vendor", then `git rebase vendor master` again.
18:03:14 <john> Clean up the mess and commit.
18:05:16 <john> You can treat this repo like any other, and anyone (with push-priv) can update it to a new release.
18:05:17 <warlord> Right, that's how you'd do it with a single repo with a vendor branch (which is, most likely, how I'm going to do it)
18:05:34 <warlord> Right, they just have to follow the correct procedure..
18:05:49 <john> So repeat as necessary for all of the dependencies.
18:06:21 <warlord> (and FWIW, I believe you can just use git add -a; git commit -a -m "Version xxx") to do the proper add/delete
18:06:37 <warlord> er, git add .
18:06:42 <john> Where it gets a little more interesting is if you want to integrate the vendor trees into MyProject's tree (like qof is in Gnucash). For that, make the vendor directory a git submodule.
18:07:38 <warlord> I'm not sure what you mean by submodule, but I feel like I can certainly untar the dependency into a subdirectory of the tree.. e.g., fooA/depA/...
18:08:10 <john> >git add -a: I don't think that that will properly handle deletions and renames.
18:08:41 <warlord> I got that instruction set from http://happygiraffe.net/blog/2008/02/07/vendor-branches-in-git/
18:08:48 *** jmd has quit IRC
18:08:51 *** ecocode has quit IRC
18:08:54 <warlord> I think it will handle deletions.. Possibly not renames.
18:09:20 <john> >submodule: See the man page of that name: http://git-scm.com/docs/git-submodule. You very much want those vendor repos to be separate from the main repo.
18:13:56 <warlord> from git-submodule man page, "submodules are meant for different
18:13:56 <warlord> projects you would like to make part of your source tree, while the
18:13:56 <warlord> history of the two projects still stays completely independent and you
18:13:56 <warlord> cannot modify the contents of the submodule from within the main
18:13:56 <warlord> project."
18:14:21 <warlord> THat doesn't work for my use case. I need to be able to modify the contents of the submodule from within the main project.. Which is why I think a vendor branch in the main project is still the way to go.
18:14:30 <john> I think it will treat renames as delete + add, so that the history is lost.
18:15:30 <john> Why on earth do you want to have changes to the vendor code mixed in with the changes to your own project?
18:16:55 <warlord> Because my project is based around changes to the vendor code that will never go upstream
18:18:22 <john> So? You can still keep those vendor-code changes separate in your vendor modules in the master branch.
18:18:37 <warlord> You've lost me..
18:21:46 <warlord> Let's say that vendor has a file foo.c. In my main project master branch I need to add a new function to foo.c. With a submodule it doesn't look like I can do that.
18:22:05 <john> The submodule isn't immutable. It's just not part of MyProject. Let's go back to the libqof example, where we suppose that we're actually tracking the external libqof project. We'd still maintain a libqof repo on code, and in Gnucash's tree it would be a submodule. Any changes we made in libqof would get pushed to the libqof repo, but as far as building gnucash was concerned the only difference would be that you'd have to update the repos separately.
18:22:44 <john> Right. You can't do it in your main project master branch, you do it in the submodule's master branch.
18:23:39 <warlord> Right, which means in the 'submodule' i would need to have a vendor and master branches in order to track upstream vs. my changes.. I might as well just have a vendor branch in my main repo for each upstream project I'm tracking.
18:25:26 <warlord> e.g., git init; touch .gitignore; git add . ; git commit -a 'Initial commit''; git branch vendorA; (do import of ProjectA, merge to master); git checkout <first commit>; git branch ProjectB; rather-rinse-repeat
18:25:42 <warlord> er, lather-rinse-repease
18:25:44 <warlord> repeat
18:25:48 * warlord can type, really he can
18:27:00 <john> You can't have a "vendor" branch in your main repo. Each branch has all of the code in it, so when you updated a vendor branch with a new tarball the change set would include not only the tar ball's changes but also all of the changes to all of the other code in the project. The risk of screwing something up is pretty significant.
18:27:39 <warlord> That's why it's all branches are based off the initial empty commit..
18:28:23 <warlord> when you checkout that initial commit you have, effectively, an empty repo again.
18:30:59 *** Ryan has joined #gnucash
18:31:11 <warlord> I wish I could draw ascii art here.
18:31:24 <john> ;-)
18:35:32 <warlord> Okay, let's try this.. Assume 'A' is a true empty commit:
18:35:38 <warlord> /--B--------H-- vendorA
18:35:38 <warlord> / \ \
18:35:38 <warlord> A-----C--E-F-G--I--K-- master
18:35:38 <warlord> \ / /
18:35:38 <warlord> \----D---------J-- vendorB
18:35:54 <warlord> (of course you may need to copy-and-paste to a constant-width font)
18:35:56 <john> OK, I see how that would work. I think. Vendor update merges could bet hairy if you're not real careful.
18:36:51 <warlord> Yeah, you need to make sure you either clone specifically the vendor branch so you're only working there.. Or you need to be very careful what you commit on the vendor branches.
18:37:12 <warlord> And as you say, file renames will be tricky, but they're already tricky because they come in a tarfile.
18:37:18 <john> Didn't quite work, even in a fixed-width font.
18:37:23 <warlord> deletes should work just fine.
18:38:03 <warlord> Well, the letters are supposed to all be time-incremented..
18:39:01 <john> The problem was that the slashes didn't line up right. But it's OK, I get the idea.
18:39:03 <warlord> So B merges down to master as C, D commited on vendorB and merged into master as D, then E, F, and G made on master, H on vA, merged as I, etc.
18:39:10 *** kenyon has quit IRC
18:39:25 <john> You don't want to commit *anything* to the vendor branches except new tar balls.
18:39:25 <warlord> I *think* this should work without requiring submodules.
18:39:30 <warlord> Right
18:39:50 *** Krzysiek_K has quit IRC
18:39:58 <warlord> vendor branches are 100% upstream content.
18:40:03 *** Krzysiek_K has joined #gnucash
18:40:21 *** kenyon has joined #gnucash
18:41:12 <john> I don't see any obvious problems as long as you keep all of your commits simple and never do a rebase.
18:41:39 <warlord> Sure, I would never rebase the vendor branches.
18:42:30 <john> Even rebasing master might lose a merge connection to one or more of the vendor branches.
18:43:16 <warlord> Sure, if you rebase upstream..
18:43:29 <warlord> I can't imagine that happening, tho
18:45:27 <warlord> I tihnk the instructions to update a vendor branch should be: git checkout <branch>; git reset --hard; replace-tarball-content in tree.
18:45:43 <warlord> (I think we'd need the reset in order to clear out the working copy)
18:45:53 <warlord> at least that's my understanding of how checkout works.
18:47:06 <john> There shouldn't be anything uncommitted in the vendor branch. You're not doing any work there except updating from tar balls. You have to commit those changes in order to have something to merge to master.
18:48:08 <warlord> If I'm working in master and then do a "checkout branch", does it reset my working directory to only the branch?
18:48:42 <warlord> (when I was playing around with this I didn't actually test that)
18:49:10 <john> Yes. It won't let you checkout if you have a dirty tree.
18:49:41 <john> You have to commit, stash, or reset first.
18:51:37 <john> I should go pack… flying to NY tomorrow morning.
18:51:38 <warlord> And when you checkout it will clear out your tree completely to the state of the branch? (in my tests I didn't have extra code around, only the vendor branch merges, so I couldn't easily tell)
18:51:53 <warlord> Okay, thanks for your help. Have a great trip, and hopefully see you next Friday!
18:52:35 <john> It won't touch anything that's not a git-controlled file. See git clean.
18:52:42 <john> See you in Boston.
18:52:49 *** john has quit IRC
19:02:49 *** kpreid has joined #gnucash
19:03:11 *** Krzysiek_K has quit IRC
19:03:27 *** Krzysiek_K has joined #gnucash
19:07:26 *** Krzysiek_K has quit IRC
19:46:11 *** Ryan has quit IRC
19:52:43 *** nomeata has quit IRC
20:06:24 *** arrainey has joined #gnucash
20:16:28 *** arrainey has quit IRC
20:17:02 *** arrainey has joined #gnucash
20:18:22 *** Ryan has joined #gnucash
20:32:11 *** arrainey has quit IRC
20:32:44 *** arrainey has joined #gnucash
20:35:59 *** Ryan has quit IRC
20:42:49 *** arrainey has quit IRC
20:43:23 *** arrainey has joined #gnucash
20:53:26 *** arrainey has quit IRC
20:54:07 *** arrainey has joined #gnucash
21:04:15 *** arrainey has quit IRC
21:04:56 *** arrainey has joined #gnucash
21:25:02 *** arrainey has quit IRC
21:25:33 *** arrainey has joined #gnucash
21:40:36 *** arrainey has quit IRC
21:41:11 *** arrainey has joined #gnucash
21:46:13 *** arrainey has quit IRC
21:46:48 *** arrainey has joined #gnucash
21:51:49 *** arrainey has quit IRC
21:52:24 *** arrainey has joined #gnucash
21:57:27 *** arrainey has quit IRC
21:58:01 *** arrainey has joined #gnucash
22:18:12 *** arrainey has quit IRC
22:18:48 *** arrainey has joined #gnucash
22:19:01 *** Ryan has joined #gnucash
22:33:53 *** arrainey has quit IRC
22:34:29 *** arrainey has joined #gnucash
22:39:32 *** arrainey has quit IRC
22:40:16 *** arrainey has joined #gnucash
22:45:26 *** arrainey has quit IRC
22:45:59 *** arrainey has joined #gnucash
22:50:59 *** arrainey has quit IRC
22:51:41 *** arrainey has joined #gnucash
23:01:43 *** arrainey has quit IRC
23:02:29 *** arrainey has joined #gnucash
23:05:55 *** Ryan has quit IRC
23:12:43 *** arrainey has quit IRC
23:13:16 *** arrainey has joined #gnucash
23:18:17 *** arrainey has quit IRC
23:18:54 *** arrainey has joined #gnucash
23:23:54 *** arrainey has quit IRC
23:24:43 *** arrainey has joined #gnucash
23:34:45 *** arrainey has quit IRC
23:35:21 *** arrainey has joined #gnucash
23:40:23 *** arrainey has quit IRC
23:40:56 *** arrainey has joined #gnucash
23:43:41 *** vantage has joined #gnucash
23:47:46 <vantage> Hi, I'm trying to figure out how to generate a custom report. I'm looking to get a line chart that has income/expense/interest income on it. The income/expense chart is close, but it's a bar chart, and I can't see how to also track interest income. Any advice?
23:56:11 *** arrainey has quit IRC
23:56:21 *** pelliott has joined #gnucash
23:56:29 *** smw has joined #gnucash
23:56:46 *** pelliott has quit IRC
23:56:47 *** arrainey has joined #gnucash
23:56:52 *** pelliott has joined #gnucash