NotesHub: changes inside a subfolder create empty Git commits #96
techsemhype
started this conversation in
General
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Hi Alex,
First of all, thank you for NotesHub. I've been using it for years and I really like the app, especially the Git-based approach and the fact that it works across iOS and Android.
I think I finally reproduced an old sync issue I had forgotten about.
My Git repository root is intentionally one level above my notes folder:
I connect this repository to NotesHub on iOS and can browse and open
md/notes.mdnormally.Reading/syncing from GitHub works perfectly.
The problem happens when editing
md/notes.mdin NotesHub:md/notes.mdon iOS.git pullreceives that commit normally.md/notes.mdremains unchanged.For example:
but:
shows no modified file at all.
I reproduced it multiple times. Authentication, fetch, push and fast-forward all work correctly; only the actual note modification is missing from the commit.
My suspicion is that NotesHub is treating
notes.mdas being at the notebook/repository root instead of preserving its real Git pathmd/notes.md.Would it be possible to support this repository layout, where Markdown notes live inside a subfolder of a larger Git repository?
I can provide additional logs or run a minimal reproduction repo if that helps.
Small additional finding that may help reproduce the issue:
I also tested the opposite direction: Mac → GitHub → NotesHub.
I edited
md/notes.mdon the Mac, committed/pushed it normally, and verified thatorigin/maincontains the new text.On the existing NotesHub notebook:
An unhandled error occurred, please try againThen I removed the notebook from NotesHub and added the exact same repository again (
techsemhype/mac).After re-adding it, the new text from
md/notes.mdappeared correctly on iOS.So this does not seem to be an authentication problem. It looks more like the existing local notebook/clone state becomes inconsistent after external Git commits, and recreating the notebook forces a clean clone that works again.
This may be related to the subfolder/path issue described above.
Thanks!
All reactions