Closed tklijnsma closed 9 years ago
Just saw: it also add the MEIntegratorStandalone to the .gitignore.
Probably ok for now, but shouldn't this actually be a submodule? If there are no objections I can promote it to one.
I think it looks good. I'm OK with the MEIntegrator being a submodule or in .gitignore. I used to use them in the past, but I found that they introduced somewhat more confusion in merges than they saved in storing the correct hash, but that confusion could probably be avoided with some effort.
See also: https://codingkilledthecat.wordpress.com/2012/04/28/why-your-company-shouldnt-use-git-submodules/
Thanks - I'll merge this then.
Regarding submodules: as our current system is just to clone the most recent version from Lorenzo's repo we probably don't gain much either way.
Maybe, when things are a bit more stable, it will make sense to at least clone a specific tag from Lorenzo so we know which version the code should be on (but this can also be done in setup.sh)
Yep, thanks for merging. In general I like the idea of submodules and fully support using them in this case - just the last time I tried to introduce it to my physicists friends it ended in some very with some very unconvinced people needing to do git submodule update
instead of the usual git pull
due to my insistence on having new technology.
Currently, our approach with the MEIntegrator code is that Lorenzo's master always points to the version that should be used with the master of tthbb13 and the concept of multiple branches does not exist.
This is the code used to generate the Transfer Function pickle file. It does not interact with the rest of the code, except for outputtree-strict.py, which needs the AccessHelpers from the TTHNtupleAnalyzer.