kb icon indicating copy to clipboard operation
kb copied to clipboard

Some points about the experimental git integration

Open Narrat opened this issue 3 years ago • 4 comments

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)

  1. branch name main seems to be hardcoded? Causes issues with pushing, if git still creates master or whatever as the main branch as default
  2. every kb sync push creates a commit

regarding 1.: Remote (and local, but that I discovered later) repo had a different branchname, which caused the following error:

Create a remote empty repository on github/gitlab or other git provider...
Insert the URL of the created empty remote repo (e.g., https://github/user/mykb): Clio:Backup/Repository/kb.git
Initialization with remote may take time...
Please provide remote credentials and wait...
Traceback (most recent call last):
  File "/usr/bin/kb", line 33, in <module>
    sys.exit(load_entry_point('kb-manager==0.1.6', 'console_scripts', 'kb')())
  File "/usr/lib/python3.9/site-packages/kb/main.py", line 66, in main
    dispatch(cmd, cmd_params, config=DEFAULT_CONFIG)
  File "/usr/lib/python3.9/site-packages/kb/main.py", line 56, in dispatch
    return COMMANDS[function](*args, **kwargs)
  File "/usr/lib/python3.9/site-packages/kb/commands/sync.py", line 46, in sync
    git_init(config["PATH_KB"])
  File "/usr/lib/python3.9/site-packages/kb/commands/sync.py", line 126, in git_init
    remote.push(refspec='{}:{}'.format("main", "main"))
  File "/usr/lib/python3.9/site-packages/git/remote.py", line 848, in push
    return self._get_push_info(proc, progress)
  File "/usr/lib/python3.9/site-packages/git/remote.py", line 735, in _get_push_info
    proc.wait(stderr=stderr_text)
  File "/usr/lib/python3.9/site-packages/git/cmd.py", line 408, in wait
    raise GitCommandError(self.args, status, errstr)
git.exc.GitCommandError: Cmd('git') failed due to: exit code(1)
  cmdline: git push --porcelain origin main:main
  stderr: 'error: src refspec main does not match any
error: failed to push some refs to 'Clio:Backup/Repository/kb.git''

After changing it on the remote if failed again. Because the local repo also had a different branchname from what the program assumed/expected:

~ $ kb sync push
zsh: correct 'sync' to 'Sync' [nyae]? n
Some error occured while pushing the code
Check your internet connection or the existence of the remote repository 

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.

Narrat avatar Apr 01 '21 23:04 Narrat

Thanks for opening a new issue. The team has been notified and will review it as soon as possible. For urgent issues and priority support, visit https://xscode.com/gnebbia/kb

xscode-auto-reply[bot] avatar Apr 01 '21 23:04 xscode-auto-reply[bot]

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. I conceived this mode as "the suer creates a git repo on github/gitlab" specially for kb and doesn't do anything more than push/pull... Anyway we can work this out and try to think about a more flexible way. What would you suggest? How a user should configure its git repo/branch and so on?

gnebbia avatar Apr 02 '21 06:04 gnebbia

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? In my opinion there are two ways to integrate sync via git:

  1. Only add a light integration in that sense, that kb tries to detect if its database is a git repository. If there is one, then create commits depending when changes are done to the database. For syncing the information somewhere else there is a perfect tool already at hand: using git itself. The benefits are, that people can freely choose where to sync (if they don't like github/gitlab), with what authentication (http, ssh), branches, settings. None of those usecases and settings need to be handled by kb, which would reduce code complexity.
  2. Integrate everything, which would introduce handling of various use cases and settings. Is the entered repo url a local path (don't ask for credentials), a ssh endpoint (setup done with ssh_conf or not). One of the various hosters, or even self hosted? Respect global config settings of git in regards of branch names, when kb tries to setup the repo, etc. A lot of ground to cover, which could break with time. Especially if everything is done via syscalls to git instead of using a library for git.

If I could decide, I would tend to option 1. Either an user of kb knows about git or doesn't. In which case this said user propably wouldn't care. And if someone cares, some manual steps (setting up the repo) don't hurt, especially if they're well documented: So the documentation should be extended on how syncing/transferring the database could be achieved. Where is the database stored (currently $HOME/.kb/, but maybe $XDG_DATA_HOME/$HOME/.local/share should also be covered), setup the local repo, offer suggestions for the remote repo and what to do to sync. And ways to automate syncing (either cronjob via a small script, or a helperscript at a specific location which kb could use to kb sync pull/push)

Narrat avatar Apr 02 '21 11:04 Narrat

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.

gnebbia avatar Jun 21 '21 07:06 gnebbia