>> ... Instead, Git thinks of its data more like a series of snapshots of a miniature filesystem. With Git, every time you commit, or save the state of your project, Git basically takes a picture of what all your files look like at that moment and stores a reference to that snapshot. To be efficient, if files have not changed, Git doesn’t store the file again, just a link to the previous identical file it has already stored. Git thinks about its data more like a stream of snapshots.
>
>I understand, but my point is that the snapshot that you take is based on what you **stage** and then commit not necessarily what's on your disk. You tell Git what to commit. `-a-` is just a shortcut that says stage and commit everything in one step.
>
>Personally I think the big difference - and perhaps learning curve item - is that Git doesn't have the concept of file locks where files are 'checked out', but rather treats all committed files as a state snapshot that is compared to another snapshot when merging. This changes how you use Git compared to classic SCC like SourceSafe - in many ways it's so much better, but it does require adjusting in how you manage changes. In collaborative environments you have to make sure to commit small and commit often, and pull often to ensure you don't get very large commits causing merge conflicts.
>
>+++ Rick ---
>
My collaboration is mostly to myself. Patch vs Development vs Changes To Framework.
The idea is to merge - but keep the files short. This, from a VFP POV, would mean file-per-procedure or file-per-class. I do not much with procedures. And those are rather static.
Fernandos Bozzos FoxBin2Prg cuts VCXs into single class files, where one only merge a class. So, even if two collaborators touch two different classes of the same lib, there will be no merge conflict. The idea of merging a whole lib at once is odd. Monolithic prgs with tens of thousands of lines and n classes anyway. Never groked this approach. I always need an external editor to get a split view ....

Merge could be done with a simple editor, or with a powerful mergetool. Each has it oddness.

Shure, any merge will not work on binary based files - but I can only repeat: - do not commit binaries. You can not merge, and git is not made for it.
The conversion is an odd extra layer (work files - text representation - index - repository) but one get used to.
Normally I do conversion -> add -> commit in one step.

I'm still thinking about to use Eventbinding to connect it to file save .... One will not loose anything, since every change is in the repo. Only one need to merge -squeeze from time to time to get more meaningfull (task based) commits - and reduce the then crowded tree.

Lutz