Skip to content
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

Open
Narrat opened this issue Apr 1, 2021 · 4 comments
Open

Some points about the experimental git integration #84

Narrat opened this issue Apr 1, 2021 · 4 comments

Comments

@Narrat
Copy link

Narrat commented Apr 1, 2021

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.

@xscode-auto-reply
Copy link

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

@gnebbia
Copy link
Owner

gnebbia commented Apr 2, 2021

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?

@Narrat
Copy link
Author

Narrat commented Apr 2, 2021

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)

@gnebbia
Copy link
Owner

gnebbia commented Jun 21, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants