I know what our long term plan in term of repo is.
But given that this is not the situation today, I do find very annoying to do review, where the number of files are HUGE,
and that many of them are identical change (10 files modified in the same way) and/or difference in path because of the machine in which @valassi was running the code (like in some log file).
I would therefore propose that we do "asap" a "removal" of this repo of all generated code like:
gg_tt.mad gq_ttq.mad
gg_tt.sa gq_ttq.sa
gg_tt01g.mad heft_gg_h.sa
gg_ttg.mad pp_tt012j.mad
gg_ttg.sa
gg_ttgg.mad tlau
gg_ttgg.sa tmad
ee_mumu.mad gg_ttggg.mad tput
ee_mumu.sa gg_ttggg.sa
with either
option 1: for each of those directory, we define its own git subpo.
advantages: no change of structure to the current repo
disadvantages: many sub-repo (maybe need a script for commiting all of them when @andrea update them)
option 2: change the structure of the directory to have a single git-subrepo
advantages: clean, only one sub-repo
disadvantages: change of structure
option 3: go directly to the dedicated/clean subrepo
advantages: directly the optimum
disadvantages: how PR are transmitted
option 4: do not do anything
advantages: nothing to do
disadvantages: not make our live easier
@roiser @valassi what do you think?
I'm obviously ready to implement the move as long as we decide which of the options, we want to go.
I know what our long term plan in term of repo is. But given that this is not the situation today, I do find very annoying to do review, where the number of files are HUGE, and that many of them are identical change (10 files modified in the same way) and/or difference in path because of the machine in which @valassi was running the code (like in some log file).
I would therefore propose that we do "asap" a "removal" of this repo of all generated code like: gg_tt.mad gq_ttq.mad gg_tt.sa gq_ttq.sa gg_tt01g.mad heft_gg_h.sa gg_ttg.mad pp_tt012j.mad gg_ttg.sa
gg_ttgg.mad tlau gg_ttgg.sa tmad ee_mumu.mad gg_ttggg.mad tput ee_mumu.sa gg_ttggg.sa
with either
@roiser @valassi what do you think? I'm obviously ready to implement the move as long as we decide which of the options, we want to go.