Re: Git with Lader logic

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 27, 2015, 15:39 UTC
Message-ID: <xmqqegoawiu0.fsf@gitster.dls.corp.google.com>
In-Reply-To: <loom.20150327T160645-181@post.gmane.org>

Martin Pettersson <martin@siamect.com> writes:

Show 16 quoted lines

> I use Git for versioning PLC program written for Beckhoff TwinCAT v2 that 
> saves the files in binary format.  
> You can probably do the same for most other systems as well.   
>   
> My way of doing it is... 
> I have a batch file that starts TwinCAT including a file that tell Twincat to
> open my PLC program and export it into a text based format. 
> After that the script opens git gui and gitk.  
>   
> I have one script like this for each plc program. 
> It is quite effcient, the whole procedure only takes a double click and 
> less than 10 seconds and you have git gui up and you can see your 
> changes in pure text, commit and push.   
> I commit both the exported text files and the binary  because the binary
> is the one I edit.   
> This has been working very well for many years....

Let me check if I got your scheme correctly.

 - You need to track PLC program files, whose native format is
   binary and is not very amenable to textual processing like diff
   and merge

 - But you can tell TwinCat to export that binary file to text (and
   presumably you can tell TwinCat to read that exported text file),
   and the text format is human-readable.

 - You use a script that calls TwinCat to export the binary into
   text as a clean filter, and what is checked into Git is the
   exported text representation.

 - You use another script that calls TwinCat to convert the exported
   text back to the binary as a smudge filter, and what is checked
   out to the working tree is the native binary format file.

Is that what is going on? I can imagine how that arrangement would work (after all, that is how clean/smudge filters are designed to be used).

Thanks.