Add/Commit menu (from VS Code) exporting file but not running git add on sc-list.txt?

[CraigRegester]

@isc-svelury Attempting to add some files to my repo from VS Code (using ISFS) - use Add command from Source Control Menu and it appears to work:

exporting new version of FIT.inc to /hfs/sys/git/IRISHealth/FITLIB/inc/FIT.inc
exporting new version of FITEnsQueueCleanup.mac to /hfs/sys/git/IRISHealth/FITLIB/rtn/FITEnsQueueCleanup.mac

I even went ahead and ran the commit with a comment which worked as I can see it in the Git GUI - However, if I do a git status from the terminal, I see:

/hfs/sys/git/IRISHealth$ git status
On branch dev
Your branch is ahead of 'origin/dev' by 1 commit.
  (use "git push" to publish your local commits)

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   sc-list.txt

no changes added to commit (use "git add" and/or "git commit -a")

If I push to the remote, my two new files go just fine but I'm curious if there's harm in the sc-list.txt being out of sync?

[isc-svelury]

The sc-list.txt is used to keep track of the files that are in Git and on the server. When we import all files into the server or export all files out to the filesystem, we use the files in sc-list.txt to determine which files need to be imported/exported.

This ensures that we always keep the most up-to-date version of all the files that need to be synced between the filesystem and the server while not touching other files that live exclusively in either of them.

The file is updated when you add or remove files from source control. That is why this file was also modified when you added some files to source control.

In practice, having an out-of-sync sc-list.txt would mean that when you run Export All from the Source Control menu to sync files from the server to the file system, you might miss some files. When you run Import All you might delete some files that are on the server (and in sc-list.txt) but not in the filesystem where it expects them. Neither Export All nor Import All will be called automatically.

You should commit it to Git to ensure consistent extension behavior across all the distributed repositories. It is easiest to have entire packages or projects in the sc-list.txt file so that updates to it will be minimal.

Note that this does not affect how the automatic Import and Export work when you save a file after editing. That will work as expected regardless of the state of the sc-list.txt file.

[CraigRegester]

That helps me understand, thanks. Is it possible to scope that file to the namespace (e.g., sc-<ns1>-list.txt, sc-<ns2>-list.txt, etc)?

This kinda links into the other discussion I started now but I would prefer to maintain a single repo for our I4H Integration environment which has a few primary namespaces but most of our common code is kept in a 'LIB' namespace to share across the integration namespaces. Then a separate repo for our UCR environment in similar fashion.

As long as I don't use Export All/Import All, sounds like we're safe regardless but I got this going like I described above in our DEV environment to start playing with it and it works well so far with exception to I now see that sc-list.txt is out of sync...

Those top level folders align to the two namespaces on the same instance of I4H that are both configured with git-source-control using the same git path /hfs/sys/git/IRISHealth - in the Settings, I simply prefix the paths with the namespace name. Works great so far.

git of course is a-ok with as well, the only crux appears to be that sc-list.txt.

[isc-svelury]

I think it could be possible. @isc-tleavitt would know more about how viable it would be and if it is something we will consider down the line.

[isc-tleavitt]

Rethinking how we do sc-list would make sense in the context of multi-namespace support.