kazhala / dotbare Goto Github PK

webpro/awesome-dotfiles#52

I install dotbare via AUR, and have checked the wiki for enabling completion. But I can't find that file in my system

I use zsh together with oh-my-zsh.
Because I don't want to put all my configurations into .zshrc, I use the folder at .oh-my-zsh/custom to organize them there.
I have setup multiple files there to differentiate them by domain, e.g. git.zsh.

The folder .oh-my-zsh is a git repository, the setup clones https://github.com/ohmyzsh/ohmyzsh there. The repo has a .gitignore at its root which contains the entire custom folder, except for the already added files and folders.

When I try to use dotbare to keep track of my custom configuration files in there, it simply doesn't work.

dotbare add ~/.oh-my-zsh/custom/git.zsh

or even with

cd ~/.oh-my-zsh/custom
dotbare fadd -f # and selecting the file

No error is ever reported and the return codes are always 0.

But the file is never staged and I can never commit it to my own dotfiles repo.

Is there a solution to this problem?

I'm using zsh with Oh my Zsh plugin manager.
Following the completion guide, I called:

_dotbare_completion_git
_dotbare_completion_cmd

But only the last one in order is working. It looks like they are mutually exclusive.

How do I enable both completion at the same time?

I am not sure how you would implement this, but I would like to be set authentication through ssh for pushing. One way to do it manually after pulling is to change https=>ssh as explained here.

One issue is that someone could have their ssh config IN the dotfiles, maybe.

The reason is that git only lists conflicted files up to a certain thresh hold and dotbare finit -u URL would read the input of dotbare checkout output. This makes in-place migration unstable if user have lots of dotfiles, potential fixes would be performing a "recursive" checkout process until git doesn't output any conflicted files.

Thanks for this awesome tool. I installed your plugin via zplug and it works great for almost all commands. However, when I run dotbare command without flags it searches inside my scripts folder. When that folder does not exist, dotbare throws an error.

When scripts folder as a subdirectory exists:

When there is no scripts folder in subdirectories:

Hi,
I hope you don't mind that I went ahead and packaged dotbare in the AUR.
I wanted to take this opportunity to discuss ways to improve availability on different systems, since your choice of offering dotbare as a shell extension makes it quite a challenge for distro packagers.
Taking a look at the source code, I noticed the shell extension file simply adds dotbare main file to the shell, which is equivalent of having it in $PATH. I also noticed you mentioned it as an option for installation. However, where the project currently stands, it's impossible to have the main file inside $PATH without scripts and helper directories, so I had to create a custom wrapper to do that and completely ditch shell extension for the AUR package.

Hope you'd consider making this project more packaging friendly, so it's possible to make it available on different systems more easily ;)

Keep up your great work!

When I add new files to some tracked directories, can dotbare auto stages these new files?

I tried using what's present in the Tips and Tricks section of the wiki but this just inserts the command into my prompt.
The zsh plugin could include the appropiate widget and then leave the actual binding of the key to the user. That way, when doing ^G, for example, the command would run directly.

Once again, thanks for this fantastic tool (especially the fedit command that centralizes all files). I tried your strategy of migrating from a symbolic link system to dotbare. It didn't work out as I expected. After following your instructions, fadd added the file as a symbolic link, not as a real file. Perhaps, I did not understand your instructions as I should, or your strategy does not intend to solve this problem.

I don't know how to report this here, but I created a script based on your fadd function. It contains a symbolic link integrity check and asks the user how to handle the file before adding it to the bare repository created by dotbare.

Here's the script.

#!/usr/bin/env bash

function return_file() {
    local file=$1
    if [ -z "${file}" ]; then
        echo "Not a file."
        exit 1
    else
        if [ -L "${file}" ]; then
            if [ -e "${file}" ]; then
                while true; do
                    read -r -p " This file is a symbolic link. What do you want to do?
                    1 - Return it to its original path and add it to the dotbare (Y/N)
                    2 - Add it as a symbolic link (L)
                    Answer: " answer
                    case $answer in
                        [Yy]* ) mv "$(readlink "${file}")" "${file}"; break;;
                        [Nn]* ) echo "Exiting"; exit 1;;
                        [Ll]* ) echo "Adding your file as a symlink"; break;;
                        * ) echo "Please answer yes or no.";;
                    esac
                done
            else
                echo "This is a broken link."
                exit 1
            fi
        elif [ -e "${file}" ]; then
            echo "Not a link"
        else
            echo "Missing"
        fi
        /usr/bin/git --git-dir="${DOTBARE_DIR}" --work-tree="${DOTBARE_TREE}" add ${file}
    fi
}

return_file "$1"

Unfortunately, this has to be done for each file. In my case, it's an opportunity to review the really important files.

Feel free to close this issue without an answer. I would just like to register my dirty solution here. Sorry for messing up your repository.

In v1.2.0, I added support for staging files with spaces. Most of them are handled through bash array with something like ${array[@]} to respect spaces between indexes. All of them works very well with git commands, however, for some reason, git diff just doesn't like ${array[@]} and this breaks the preview for dotbare fcheckout -s If I do try it I get an error. Well if I do use ${array[*]}, git diff is happy, however, preview for files containing spaces would break due to the asterisk does not respect spaces any more.

Note: This doesn't affect any actual functionalities of dotbare, it's just preview that's breaking.
I'm quite stuck on this, although this won't affect any functionalities and it's unlikely for anyone to experience this, I'll just leave this one here.

Relevant lines:

This works for normal files but not files with spaces. If I do change it to ${files[@]}, none of them will work.

Hi, I just tried migrating my setup to a new arch machine, and dotbare did everything right, except I had a few submodules defined in .gitmodules, none of which where cloned. I don't know if this is intended, but I would like to be able to keep them when migrating.

Also, how is the generated .gitignore file supposed to work? I would guess it's to avoid tracking the bare repo folder, but a) it should not be tracked anyways unless one explicitly adds it; and b) if my bare repo(dotbare_dir) is in .config/dots, with tree in $HOME, and the .gitignore file generated the entry "dots", would it even work? it does not seem to be the correct relative path..

I like the idea of git --bare repos. But its not creating the folder structure I want. For example if I have,
$HOME --> .config --> nvim --> plugins --> someplugin.vim

and I add 'someplugin.vim' then I get one folder named '$HOME\ .config\nvim\plugins' in my remote repo in gitlab.

$HOME\.config\nvim\plugins --> someplugin.vim

Is this the expected behaviour for git work-tree outside the git-dir or am I doing anything wrong.

Ive installed dotbare both from source and the aur but this error of the file names being messed up and the preview window still show up not sure if its dotbare or my system

I am new to dotbare it seems great. Rather special

Before I resort to my disk backup of yesterday, (and saving about an hours work in changes since then), am i able somehow to retrieve lost files?

I staged a first commit , pushed to git, with just a read me, and then ,

• Somehow detached from HEAD, a branch 'master'
• About 100 config files in all added, from ~ , and then subsequently from .config, , bu
• I suspect i added the bulk (I.E. from .config) to the new branch of master, detached form HEAD.

I attempted and succeeded to revert to the 1 st commit,.. in order not to use a detached branch, for newly added/ and staged files.

I see in fedit, and in checkout that the .config files have disappeared from my disk and in 'fedit' they are visible in red with a ?? preceding.

1 st commit remains.
Only the 12 files from home directory remain, staged and ready.
Second commit has vanished.

Thanks,
John
I don't see them in trashes.

Hello @kazhala

first let me thank you for this project...not being a true IT person, having a visual context in the cli when dealing with dotfiles is quite invaluable for me!

My question relates to the possibility of using dotbare to track (separately) two dot repositories with two different working dirs, specifically the $HOME for the majority of config files, and /etc for those few files involving system customization (eg. confs within sysctl.d/ or udev rules).

Without taking into consideration the file ownership drawbacks when handling dirs outside $HOME (I am aware of such problems, but my scope would be limited to a local tracking and manual cloning), the issue is ultimately how to use dotbare scripts to track two git bare repositories pointing to two different working trees.

Thanks again for your great contribution!

Hi there,
forgit has this binding for scrolling previews. I wondered if it was possible for dotbare to have it as well ;)

Hey,

I'm not all too familiar with zsh completion so I was strictly following the wiki more or less.

If I specify an alias agrument for _dotbare_completion_cmd it breaks completion for both the alias and dotbare :

It works fine without an argument:

I think it just might be that the docs are wrong/outdated on this one.

P.s. Thanks for the amazing tool btw!!

Hi, I noticed that launching dotbare without arguments is now broken; I believe it was not before last release. Specifically, it returns:

basename: extra operand ‘/opt/dotbare/scripts/fcheckout’
Try 'basename --help' for more information.

I experience this with both the AUR release, as well as upstream.