Generating generations of files

[DL Neil]

On 30/04/19 8:04 AM, Chris Angelico wrote:
> On Tue, Apr 30, 2019 at 6:00 AM DL Neil <PythonList at danceswithmice.info> wrote:
>>
>> Are you aware of a library/utility which will generate and maintain the
>> file names of multiple generations of a file?
>>
> 
> Commit it to a git repository. All the generations have the same name,
> but you can compare them, explore past versions, etc, etc, etc, with a
> rich set of tools. And it's easy to invoke git from a program (if you
> need information from stdout, most git commands accept a "--porcelain"
> parameter), so you can fully automate.


Great idea!
(and all 'the work' is already done)

I've seen various Py + GIT entries in the library, so can I assume the 
ability to output a file directly into a GIT repo/branch, instead of the 
file-system?

Is this a common use-case?


Three immediate thoughts:

1 I'd have to put GIT onto one of the users' storage servers (see 
comment elsewhere about re-thinking location of file-storage). OK, so 
I'm lazy - but I work hard at it!

2 We'd need a user-friendly GIT-client for the users. The words "Linus" 
and "user friendly" don't often sit together happily in the same 
sentence (and if he ever reads this...)

3 The users' case for retaining older-versions is so that they can 
compare between runs. (I blame myself, showing them filecmp, noting that 
they could quickly employ Calc/Excel...)
Easiest explained example = some slight change in a variable results in 
a 'surprise' result. (which scenario is almost identical to the 
'sensation' when a user throws some data at *our code* and finds some 
'error' - schadenfreude means there's always a silver lining!)
Earlier, I had suggested dropping the o/p of each 'run' into its own 
sub-dir of the client-/experiment-directory (perhaps using date-time) 
and thereby completely avoiding any fileNM 'collisions'. Lead balloon! 
Sigh...


Thanks! I'll have some little git - apologies, I mean: "a Git expert", 
research further...
-- 
Regards =dn