-
-
Notifications
You must be signed in to change notification settings - Fork 104
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Some points about the experimental git integration #84
Comments
Thanks for opening a new issue. The team has been notified and will review it as soon as possible. |
Dear Sir thanks a lot for your comments, indeed the "git integration" is experimental really for hearing your feedback and fix it in a reasonable way. |
Maybe for that to decide it is the best to go back to the general question: What do I want and how could it be achieved?
If I could decide, I would tend to option 1. Either an user of |
Thanks a lot for all the interesting points, at the moment the git version implements the XDG compliance, I will look into implementing the other points. |
I recently discovered this tool and thought it could be an idea to get rid of my various text files :D Well, I'll see how it will work out.
While tinkering with the tool I tried the experimental sync feature via git. And noticed some points (didn't look at the source yet, so maybe my observations are wrong)
main
seems to be hardcoded? Causes issues with pushing, ifgit
still createsmaster
or whatever as the main branch as defaultkb sync push
creates a commitregarding 1.:
Remote (and local, but that I discovered later) repo had a different branchname, which caused the following error:
After changing it on the remote if failed again. Because the local repo also had a different branchname from what the program assumed/expected:
regarding 2.: It shouldn't create a commit which then gets pushed, if there is no change in the local repo.
Additional thought about this: When should the commit be created? Either after every
add
,edit
or whatever operation changes the local state in the repo. Or stay with the current implementation. Personally I like the first. Which I luckily can do even if you don't want to change the behaviour, which would be perfectly fine.The text was updated successfully, but these errors were encountered: