Would it be possible to not create .gitignore.d every time vcsh is run? I don't use it and it's kind of annoying to have an unused empty directory in the middle of my ~.

This would need to present a list of files and ask what to do with each. Batch mode would help.

• Move gitignore
• Remove any prepending paths
• Any README or similar needs to move into a subdir

Bascially, use vcsh which to verify that the file is tracked by one repo only and then allow the user to git add in the context of that one repo.

0.20111017 has been released without support for vcsh use.

For now, I will keep it that way and see if there are any complaints. This issue is meant to track any discussions wrt this feature.

• explain exact vs recursive as a lot of people miss that
• short blurb on how the whole thing works technically

Neither strictly belongs into those files, but apparently there's user confusion and this may help solve the issue.

Apparently, this is less common knowledge among vcsh users than I assumed.

Along the lines of
for repo in $(vcsh list); do echo $repo; vcsh $repo status -uno -s; done

• Allow all files in $HOME to be listed as tracked/untracked?

vcsh commit:

• Find all staged changed changes
• for repo in list found staged changes in repos; do vcsh run $repo git commit --verbose; done # with some magic to show which vcsh repo you are in

vcsh commit $file

• Check if $file is tracked by one repo only
• vcsh run $repo git commit $file

When removing any repo, (ie: vcsh delete) I get a rmdir error.

An example using your zsh template script:

test@lain ~func % vcsh delete zsh
vcsh: info: This operation WILL DETROY DATA!
These files will be deleted:

.gitignore.d/zsh
.zsh/functions/buildPS1
.zsh/functions/buildRPS1
.zsh/functions/edit_history
.zsh/functions/header
.zsh/functions/help
.zsh/functions/help.d/help_glob
.zsh/functions/help.d/help_history
.zsh/functions/help.d/help_modifiers
.zsh/functions/help.d/help_read_keycodes
.zsh/functions/hooks/chpwd
.zsh/functions/hooks/precmd
.zsh/functions/hooks/preexec
.zsh/functions/issetopt
.zsh/functions/mandelbrot
.zsh/functions/mcd
.zsh/functions/mkiso
.zsh/functions/on
.zsh/functions/purge_temp_files
.zsh/functions/reload
.zsh/functions/scp_wrap
.zsh/functions/ssa
.zsh/functions/startup
.zsh/functions/startup_warnings
.zsh/functions/toggleopt
.zsh/functions/trans
.zsh/functions/vim
.zsh/functions/youplayer
.zsh/functions/zshrc_show_chars
.zsh/functions/zshrc_show_colors
.zshrc

AGAIN, THIS WILL DELETE YOUR DATA!
To continue, type 'Yes, do as I say'
Yes, do as I say
rmdir: failed to remove `/home/test/.config/vcsh/repo.d/zsh.git': Directory not empty
vcsh: error: could not delete '/home/test/.config/vcsh/repo.d/zsh.git'

Do you happen to have rmdir aliased to --ignore-fail-on-non-empty?

Thanks.

That would allow hooks to be a lot more powerful. But if there's an exit() in a hook today...

Or introduce a new kind of hook that's sourced:

source-post-clone
post-clone

In the README, section available.d you mention zsh.mrconfig, but the latter word occurs nowhere else.
What is it, and what does it have to do with available.d? Did you mean available.d/zsh.vcsh ?

While you're at it,
you also mention I.e. in this specific example, push can not work. but you don't explain why push can't work, it's not obvious from the example.

See #92 for details.

Or maybe this is a documentation issue?

From documentation, section 4.2:

brian@aquitard:~$ vcsh clone git://github.com/RichiH/vcsh_mr_template.git
vcsh: info: attempting to create '/home/brian/.config/vcsh/repo.d'
Initialized empty Git repository in /home/brian/.config/vcsh/repo.d/vcsh_mr_template.git/
remote: Counting objects: 19, done.
remote: Compressing objects: 100% (12/12), done.
remote: Total 19 (delta 2), reused 19 (delta 2)
Unpacking objects: 100% (19/19), done.
From git://github.com/RichiH/vcsh_mr_template

• [new branch] master -> origin/master
  brian@aquitard:~$ mr update
  cat: /usr/share/mr/vcsh: No such file or directory
  mr: include command exited nonzero (256)
  mr checkout: /home/brian/.config/vcsh/repo.d/mr.git
  Initialized empty Git repository in /home/brian/.config/vcsh/repo.d/mr.git/
  remote: Counting objects: 19, done.
  remote: Compressing objects: 100% (12/12), done.
  remote: Total 19 (delta 2), reused 19 (delta 2)
  Unpacking objects: 100% (19/19), done.
  From git://github.com/RichiH/vcsh_mr_template
• [new branch] master -> origin/master
  vcsh: error: '.config/mr/available.d/mr.vcsh' exists.
  vcsh: error: '.config/mr/available.d/zsh.vcsh' exists.
  vcsh: error: '.config/mr/config.d/mr.vcsh' exists.
  vcsh: error: '.mrconfig' exists.
  vcsh: fatal: will stop after fetching and not try to merge!
  Once this situation has been resolved, run 'vcsh run mr git pull' to finish cloning.

mr checkout: command failed

mr update: finished (1 failed)

In section 4.1.2 of the documentation it says to add "mr.vcsh" to the command line:

brian@aquitard:~$ rm -rf /home/brian/.config/vcsh /home/brian/.config/mr/ /.mrconfig
brian@aquitard:$ vcsh clone git://github.com/RichiH/vcsh_mr_template.git mr.vcsh
vcsh: info: attempting to create '/home/brian/.config/vcsh/repo.d'
Initialized empty Git repository in /home/brian/.config/vcsh/repo.d/mr.vcsh.git/
remote: Counting objects: 19, done.
remote: Compressing objects: 100% (12/12), done.
remote: Total 19 (delta 2), reused 19 (delta 2)
Unpacking objects: 100% (19/19), done.
From git://github.com/RichiH/vcsh_mr_template

• [new branch] master -> origin/master
  brian@aquitard:~$ mr update
  cat: /usr/share/mr/vcsh: No such file or directory
  mr: include command exited nonzero (256)
  mr checkout: /home/brian/.config/vcsh/repo.d/mr.git
  Initialized empty Git repository in /home/brian/.config/vcsh/repo.d/mr.git/
  remote: Counting objects: 19, done.
  remote: Compressing objects: 100% (12/12), done.
  remote: Total 19 (delta 2), reused 19 (delta 2)
  Unpacking objects: 100% (19/19), done.
  From git://github.com/RichiH/vcsh_mr_template
• [new branch] master -> origin/master
  vcsh: error: '.config/mr/available.d/mr.vcsh' exists.
  vcsh: error: '.config/mr/available.d/zsh.vcsh' exists.
  vcsh: error: '.config/mr/config.d/mr.vcsh' exists.
  vcsh: error: '.mrconfig' exists.
  vcsh: fatal: will stop after fetching and not try to merge!
  Once this situation has been resolved, run 'vcsh run mr git pull' to finish cloning.

mr checkout: command failed

mr update: finished (1 failed)

still no joy, obviously mr is looking for the repository in /home/brian/.config/vcsh/repo.d/mr.git, so lets try:

brian@aquitard:~$ rm -rf /home/brian/.config/vcsh /home/brian/.config/mr/ /.mrconfig
brian@aquitard:$ vcsh clone git://github.com/RichiH/vcsh_mr_template.git mr
vcsh: info: attempting to create '/home/brian/.config/vcsh/repo.d'
Initialized empty Git repository in /home/brian/.config/vcsh/repo.d/mr.git/
remote: Counting objects: 19, done.
remote: Compressing objects: 100% (12/12), done.
remote: Total 19 (delta 2), reused 19 (delta 2)
Unpacking objects: 100% (19/19), done.
From git://github.com/RichiH/vcsh_mr_template

• [new branch] master -> origin/master
  brian@aquitard:~$ mr update
  cat: /usr/share/mr/vcsh: No such file or directory
  mr: include command exited nonzero (256)
  mr update: unknown repository type and no defined update command for /home/brian/.config/vcsh/repo.d/mr.git

Which isn't really surprising.

However, I am a bit confused how to make mr update to work as described in the documentation.

vcsh rename should also rename core.excludesfile repo's config section

as a new user, I wonder "do I need to do anything special to my git repositories in order to make them work with vcsh?"

the README says "vcsh will check if any file it would want to create exists", IMHO you should document how this works, how does vcsh differ from regular git? just by setting some env vars? when? when invoking vcsh ?

[~]$ vcsh ranger commit -m 'new vcsh ignore system'
error: pathspec 'vcsh' did not match any file(s) known to git.
error: pathspec 'ignore' did not match any file(s) known to git.
error: pathspec 'system' did not match any file(s) known to git.

vcsh treats arguments with whitespace in them as separate arguments. Because of the simple way $VCSH_EXTERNAL_COMMAND is assigned, all arguments with whitespace in them will be treated as if they are multiple arguments, causing things to break badly.
The correct solution would be to use arrays, but you cannot use arrays if you want to remain posix compliant.
I would just write this stuff in bash and depend on bash, which would also allow us to clean up the code in other places.

Allow users to use arbitrary worktree directories.

Else, I may/will forget to update this at some point in time.

I'm trying to run

 $ vcsh version
 vcsh 1.20130724
 $ vcsh clone --recurse-submodules https://github.com/spf13/spf13-vim.git

and receive the following error

fatal: Could not switch to 'https://github.com/spf13/': No such file or directory
vcsh: fatal: no repository found for 'spf13-vim'

Am I using the right syntax here?

Thanks

quote: "/.config/vcsh/repo.d is the directory into which vcsh clones the git repositories"
I would phrase this as:
"/.config/vcsh/repo.d is the directory where all git repositories vcsh works with are located. Also, mr will work with repositories in this directory if you configured it to do so (see above)"

The main point being that vcsh doesn't just clone new repos there, often you'll have mr clone new repos in there and they'll show up in vcsh list, the current explanation doesn't cover this, in fact maybe even my version still doesn't cover this well enough.

Please excuse my suggestion if I'm being ignorant here, but I though maybe I had an idea to provide a clean cut way to deal with submodules:

Implement a script that just creates a specific file whenever it comes across a git repo within the directory vcsh is set to monitor. E.g. ~/.vim/bundle/.subrepos.vcsh This file contains the git address to all the remote repositories within the parent directory containing any number of git repos. I don't know much about git, but I was thinking that vcsh would at least be able to parse this file and clone all the repos, whenever vcsh would create the set of dotfiles on a new system.

git allows to clone directly into branches like
git clone -b branch URL

I find the clone parameters in vcsh too restrictive.
The clone activity should allow more than just 3 parameters.
With bash you can easily expand the parameters with "${@:2}" also add remaining parameters to the clone request.

I just noticed that 'vcsh rename oldname newname' neither renames the gitignore file in ~/.gitignore.d, nor updates the core.excludesfile directive in the renamed repositories' config.

As far as I understand, this leads to some unexpected behavior when writing a new gitignore after renaming or adding another repository named 'oldname' after issuing the above command, right?

Short, friendly, based on use cases.

When/if we have tests...

And with "we" I mean "I"...

Or am I doing something wrong?

brian@aquitard:~/tree$ git clone https://github.com/RichiH/vcsh.git
Cloning into vcsh...
warning: remote HEAD refers to nonexistent ref, unable to checkout.

Thanks

• Beginners should use merging branches
• Pros could use rebasing if they are willing to do the extra work.

on line 223 there's a return call which is not in the scope of a function.

diff -N "$tempfile" "$HOME/.gitignore.d/$2" > /dev/null &&
        rm -f "$tempfile" &&
        return

I've installed vcsh via homebrew and it generally works fine except when running the "vcsh write-gitignore" command. When I do I get an error message about mktemp failing. The issue is the mktemp program under OS-X is the BSD program and is expecting a file pattern where the GNU mktemp doesn't require it.

To fix the issue adding the tmp.XXXXXXXXXX to the following code fixes the issue.

tempfile=$(mktemp tmp.XXXXXXXXXX) || fatal "could not create tempfile" 51

See comments of http://richardhartmann.de/blog/posts/2013/07/24-vcsh-v1.20130724/

this glob expands incorrectly when there are no matches.
so you probably need to enable nullglob for it.

elif [ "$1" = 'list' ]; then
         for i in $VCSH_BASE/*.git; do

With pure zsh, i believe you can

for i in $VCSH_BASE/*.git(N)

with posix sh, not sure.

DIrect command to show what repo(s) control a certain file.

You should probably throw in a --version flag so that I can figure out whether I'm using a current vcsh, or one from eight months ago.

Hi.

I'm trying to add vundle as a submodule for my vim repository, but when I try to execute vcsh vim submodule add https://github.com/gmarik/vundle.git ~/.vim/bundle/vundle, it fails with:

fatal: working tree '/home/magne' already exists.
Clone of 'https://github.com/gmarik/vundle.git' into submodule path '/home/magne/.vim/bundle/vundle' failed

Is using submodules impossible with vcsh, or is there something I'm missing?

Magne Rasmussen

11:18:28 < tfnico> Running vcsh 1.20130724 (via homebrew), I see an empy list of files when i do vcsh status, but when doing a single repo vcsh tmuxinator status, I see all untracked files in the homedir, which renders the command a bit
useless.. Ideas?
16:10:41 < tfnico> RichiH: https://gist.github.com/tfnico/6366440
16:29:01 < RichiH> tfnico: status runs --short --untracked-files='no'
16:29:12 < RichiH> to avoid that other stuff
20:49:13 < tfnico> RichiH: how about vcsh , like in vcsh status tmuxinator ?

what if I don't have or can't install vcsh on a server? It'd be lovely to have a "vcsh transmit user@host:" that does an scp of the relevant files in the remote home

If i vcsh clone git://github.com/RichiH/vcsh_mr_template.git and the files already exist, it complains about that, so i remove the files and try again. then it says:

vcsh: fatal: /home/dieter/.config/vcsh/repo.d/vcsh_mr_template.git exists
 fatal: remote origin already exists.

so i remove /home/dieter/.config/vcsh/repo.d/vcsh_mr_template.git and try again.
then it complains again that the files in ~ already exist

Solutions?

• maybe vcsh clone could be more atomic?: only really install the git repo once all prerequisites are met (repo does not exist yet, no file conflicts, ..)
  i would suggest to first clone in $XDG_DATA_HOME/vcsh/repo.d/, check all conditions, then move repo to $XDG_CONFIG_HOME/vcsh/repo.d/
• and/or use more clear warning messages: A user should probably never try to re-clone (instead pull)
  it should be clear what worked and what didn't (i.e. the clone worked, but not putting files in place? although i would guess these operations are very closely related, hence the point above seems sensible to me)

for a new user reading the README, when reading the part about available.d, the first thought that pops up is "all these files in available.d which will have a lot in common, how to avoid redundancy?". that could use some explanation.

This is non-obvious, but very helpful.

12:40:59 < dorbin> Hi. What is the correct way to create a bare directory for vcsh?
12:41:36 < dorbin> Normally, I create a bare repo on my server and start from there..
12:47:43 < gernot> dorbin, create the vcsh repo locally and a regular git bare repo on the server. Then, in the local vcsh repo, git remote add the bare repo and push to it.
12:55:05 < dorbin> Simple and sweet. Thanks

do we really need the bakfiles for seed-gitignore?
some arguments why not:

• if the user invokes this command, he could expect that his files will get overwritten
• user has $HOME/.gitignore.d/* in git anyway (or at least should have)
• if user is going to have a tool automatically maintaining a file, putting manual stuff in there is pointless anyway
• maybe we could add a -f flag to force overwrite, but still this doesn't seem like a natural approach (read on).

some arguments in favor

• .bak files can easily be gitignored (although, if he has $HOME/.gitignore.d in git, he uses vcsh to manage it, is there a way to maintain ignore files that are not overridden by git-seedignore?
• maybe the gitignore.d dir should contain for each repo 2 files: .manual and .auto
  the autofile can be automatically rewritten by vcsh and needs no backing up, and vcsh wouldn't touch the manual files. it however create a new file .merged, or something which simply contains the sum of both files. (which is basically a work around for git's lack of multiple ignore files)

the latter is maybe the best solution: it removes the need for backupfiles completely, and allows users to maintain their own gitignore rules safely.

See http://lists.madduck.net/pipermail/vcs-home/2013-April/000849.html
Message-ID: [email protected]