I want to illustrate the use of Git commits to make a typical set of changes to an SFM file, and to show how the Git GUI programs work.
The problem illustrated here is from the Dimli Language. We made the decision to create a custom field called the Source Entry. It contains the information that normally would be in the Source field, except it is under the Entry level rather than the sense level. In the SFM file its field marker is \so.
Some of the \so fields were at the entry level, and some at the sense level. In the Dimli SFM file, the sense can start with \ge, \sn, or \ps markers (as a regular expression, "\\(ge|sn|ps) "). Almost all the \so fields occurred only once in a record.
We did this in two different commits. The first commit corrects the records that have more than one \so marker. The second commit moves the \so field out of the sense level into the entry level.
The changes for the first commit were done by hand in Notepad++. To check the changes, we counted the total number of \so fields (using grep -c). Then we ran a Perl script to put each record on one line (opl.pl) and counted the number of records that had a \so field (again, using grep -c).
The number of records with a \so field was the same as the total number of \so fields, so we knew there was only one per record. We documented the check in the first commit message.
The second commit was carried out by a command with 3 processes:
changing the SFM records to one per line, using opl.pl.
doing a Perl substitution that moved the \so field to just before the first sense marker (\ge, \sn, or \ps)
changing the SFM records to multiple lines, using de_opl.pl.
In the second commit's message, we documented the Perl commands to carry out the change.
This screenshot shows the 1st commit as it was made in Git Gui.
This screenshot shows the 2nd commit as it was made in Git Gui.