Version controlling / .gitignore for hledger-flow

[sbibauw]

The tutorial for hledger-flow recommends to git add . several times. I'm wondering what would make the most sense to version control, in a workflow where many files are entirely generated at each run.

What is in your .gitignore?

Should I exclude 2-preprocessed/? 3-journal/? (a bit too extreme perhaps)
What about inclusion-files such as all-years.journal and 2021-include.journal?

[apauley]

I think I need to explain some oddities in the doc that I think you spotted, for example the various git commands sprinkled in the doc:

The doc is a literate program, those commands are usually executed via emacs directly in the doc.

By doing that I wanted a way to have the human-readable documentation also execute the commands it mentions, and have it embed the output in the doc. In theory the docs would then be kept in sync with the program over time.
This works mostly OK, but it still relies on me manually executing all the code blocks to keep the docs in sync, and I haven't been very good at that.

The docs then also generate the whole hledger-flow-example repository.

OK, onto your actual question: which files to include and exclude from version control.

I have always included the generated files in my repo, because it allows me to see what changed. Especially the journal files.
In retrospect the files in 2-preprocessed didn't add much value, so it can probably be excluded. But you still have to remember that the rules files operate on the preprocessed files, not the originals.

The include files are small, and I find it helpful to see that they get updated when I add stuff, so I'll probably keep those version controlled in my repo - other people probably have different preferences 😃

[sbibauw]

Thanks a lot for your answer. This makes sense. (I also understand what it means for how the hledger-flow-example gets created.)

After a week of trying out the structure, I realize that, indeed, it is useful to have the generated .journal files version controlled as well, to quickly see the changes. And committing the small inclusion all-years.journal and YEAR.journal files has allowed me to use a new git branch to tryout including older/historical transactions in an alternate branch.
So I think your recommendations and setup makes the most sense in the end :-)