GitFinder Unable to Stage Certain Files/Folders

[luxlogica]

Brief Issue Description

GitFinder seems to be unable to correctly see the status of certain files and folders in some directories. In certain cases, this makes GitFinder operation unreliable, as it becomes impossible for GitFinder to stage and commit certain files/folder. Overall, it impossible to use GitFinder in these cases.

Steps to Reproduce Issue

1. Download this zipped archive of a Github-hosted project (it's a development-ready version of Kirby, an excellent and very popular flat-file CMS).
2. Put the downloaded and unzipped 'plainkit-master' folder into a location in your Mac that is being watched by GitFinder.
3. Control+click on the 'plainkit-master' folder, and select 'Create...' from the GitFinder contextual menu, to create a local repository.

We should see '?' tag icons next to the 'plainkit-master' folder, as well as next to every sub-folder and file inside it, indicating that nothing is being staged yet. Unfortunately, this is not what we get, though... If we look inside the sub-folders, we see that GitFinder has marked all files and folder there as 'up-to-date/no change' - even though we still have no commits in our brand-new repository:

Let's try to do an initial commit, to see what happens:

4. Now, control+click on the 'plainkit-master' folder, and select 'Browser...' from the contextual menu. GitFinder's Browser window will popup, allowing us to select the files to be staged and committed. Note, that we do NOT see the files or folders that were marked 'up-to-date' (even though these have files we DO want to commit):

5. In the Browser, click on the 'Select All' button, to try and select ALL unstaged files within the project folder. Note that now our sub-folders DO appear in our Browser list, but none of their files are included, and even though they appear here marked as 'unstaged', we still cannot stage them - if you try to click on the tick box to stage them, they immediately untick themselves automatically. In the end, the only initial commit we can setup is this:

6. Click 'Commit'. The Browser window will refresh, but will let you know that you still have 4 unstaged items (obviously, the 4 folders we could not stage in the previous step) - but nothing is listed in the Browser window, and the 'Un/Stage All' button is greyed out...:

7. Lastly, if we now look at icon tags for the repository in the Finder, we can see the 4 sub-folders with their 'unstaged' tags. But looking inside those folders, we see that their sub-folders and files continue to have their 'up-to-date' tag - at this point, totally misleading and simply wrong, as those files/folders don't seem to have been committed to our repository at all:

Please note, that this means that in this instance, GitFinder seems to be wrongly reporting on the status of certain files and folders. It also seems that it is impossible to stage and commit certain files and folders with GitFinder.

Lastly, this is an issue that happens only with GitFinder. Performing these operations using other git GUI clients, or using git directly on the terminal, proceeds as expected.

[milke]

Hey @luxlogica,

Thanks for detailed investigation and explanation of this bug. Yeah, it's clearly a bug. The funny thing is that it all used to work as it should prior version 1.2, hence, version 1.1.3 was the last one working correctly in this regard. Too bad nobody has caught this before and I'll certainly fix it in the first upcoming minor update.

If you're interested to read how it got broken… Version 1.2 changed a lot in regard what are responsibilities of GitFinder application and its accompanying GitFinderSync Finder Sync extension. I realised it's much better if the application does everything git related and just sends file statuses to the extension, so the extension does minimal work and just shows file statuses in Finder and offers certain menu actions (like Apple advises).

While it was the other way around (prior version 1.2), the extension was doing all git related things, including checking git file status for ALL files in the repository, even if they are unmodified (thus "up-to-date"). With new architecture, I have to send statuses of all files in the repository from the application to the extension. And for large repositories (many files), it can be quite long message, with many objects that need to be encoded on one side and decoded on the other side, etc… And in most cases, out of thousands files, only a few or a dozen are really changed/modified/ deleted, while the vast majority is "up-to-date". Hence, I decided to exclude those unmodified files in the status messages and assume if a file doesn't have status specifically mentioned, then it's ""up-to-date".

Unfortunately, this gets broken for all subfiles and subfolders of a newly added (still untracked) folder. Subfolders and subfiles really don't have any git status (yet), but due to the decision I explained in the previous paragraph, they're treated as "up-to-date", as you've discovered. Everything else that happens (not being able to stage and commit files, etc…) is a consequence of incorrectly calculated/assumed file status.

The fix is coming in a few days.

[luxlogica]

Thank you, @milke - happy to hear it was something easy to pinpoint! :) Looking forward to the update!

[milke]

@luxlogica, I've just updated new beta version 1.3.1b1 (build 58). It fixes (hopefully) these issues with children of folders newly added into the repository. It works as it used to before version 1.2 and as it does in other git clients. I tested it myself, but it's always good to have someone other to confirm it's fixed.

So please, give this beta version a try for a few days and let me know if you still have those problems. You can update your current copy to this beta automatically, just choose Beta channel in update preferences. Or, if you prefer direct download, here it is. Once we're sure it's fixed, I'll make an official release.

[luxlogica]

Thank you for looking at this so quickly, @milke!

I have just tested it, and here is what happens now:

• when a local folder is selected, and a new repository created with the 'Create...' command, the folder and its immediate child items show the "?" symbol. Sub-sub-folders (grandchildren of the parent folder) and their items, however, do not show any icons. I guess this might be intended behaviour?
• once we do an initial commit, then all tracked folders, sub-folders, sub-sub-folders and their items show appropriate info icons:
• Note that there are a couple of sub-folders in there that I did not include in the commit ('kirby', and 'media'). If I now 'Ignore' select these 2 folders, and tell GitFinder to 'Ignore' them, even after committing this, their sub-folders will show all their items as 'up-to-date'...:

I guess that one is probably not intended behaviour, as to me this looks like all these items are being tracked — ie., I expected them to show the 'ignored' symbol, as these have never been tracked...

[milke]

Sub-sub-folders (grandchildren of the parent folder) and their items, however, do not show any icons. I guess this might be intended behaviour?

Yes, it's intended, because those files (children of newly added folder(s)) don't really have any git status. However, from your question I realised that may be confusing to many people, so I decided to show badges for those files too. Not only that, they will also provide Stage action in the contextual and toolbar item menu, since those files can be staged - that is, added into repository index.

If I now 'Ignore' select these 2 folders, and tell GitFinder to 'Ignore' them, even after committing this, their sub-folders will show all their items as 'up-to-date'...:

You're right, of course.

Both of these are fixed in the latest beta version 1.3.1b3 (build 60). You can update to it like you did before. I'd appreciate if you give this beta a try and confirm the issues are fixed. Thanks! 👍

[luxlogica]

Indeed, seems to be fixed now - and the extra indicator icons in the grandchildren files/folders is a definite bonus, which makes it more intuitive - thank you!