trying out vcsh

[martin f krafft]

also sprach Brian May <brian at microcomaustralia.com.au> [2012.02.06.0116 +0100]:
> Just recently I heard of this vcsh thing, just some of my initial
> thoughts.

Just recently started to clean out my inbox… ;)

> 2. I found following the instructions for creating new
> repositories insufficient (section 4.1.4); I also had to add the
> following to $HOME/.config/vcsh/repo.d/foo.git/config:
> 
> [branch "master"]
>         remote = origin
>         merge = refs/heads/master
> 
> otherwise "mr pull" won't work. Is there an easier way to make
> this change, e.g. using git command line?

vcsh run foo git config branch.master.remote origin
…

> 3. If I accidentally add a repository I didn't want, is there an
> easy way of removing it and the checked out files? Maybe this is
> what vcsh delete is meant to do?

vcsh remove now exists.

> 4. What is the recommended practise for $HOME/.gitignore? I found
> this file on one host only, and it is not committed anywhere.
> Should I be adding it to a repository?

I am still working on that. Right now, vcsh write-gitignore writes
a file into ~/.gitignore.d/ for each repo, but that file is only
used by the repo. And while this makes work within a repo nice and
tidy (mostly), it has a couple of drawbacks:

  - git add requires the -f flag
  - no trivial way to reuse the information outside of the repo,
    e.g. for a ~/.git repository. Wouldn't it be nice to be able to
    say git status in ~ and be told which files are not tracked by
    *any* repo?
  - I don't like that ~/.gitignore.d/foo is a "config file" that
    mostly just replicates (cached) what is known to Git. I feel
    like this information can be extracted from Git directly. But
    I have not figured out how to deal with non-tracked files like
    .Xauthority. I would want my 'x' repo to know to ignore the
    file. Right now, I could add it to ~/.gitignore/x but I don't
    want to use those files as config files.

> 5. Suspect this is related to 4; am concerned about the
> possibility that I might accidentally commit the same file to two
> different repositories. For example by running git add on the
> wrong repository. Are there any safe guards to prevent this from
> happening?

Wouldn't be hard to do, again using vcsh which. The requirement to
pass -f to git add is also a bit of a safe-guard. Best practice
might be to add an exclusion to the respective gitignore file before
adding, then the -f won't be needed.

> 6. Would it be possible to implement commands that, assuming the file
> is already committed to an active repository, automatically work out
> this repository from the list of files? e.g.
> 
> vcsh add .zshenv
> vcsh commit
> 
> and/or
> 
> vcsh commit .zshenv

This should be possible with a simple wrapper around vcsh which and
vcsh run, e.g.

  vcsh which '^\.zshenv' | cut -d: -f1 | xargs -I '{}' vcsh run '{}' git …

Arguably, this could be made into a vcsh subcommand, e.g.

  vcsh run-by-file '^\.zshenv' git …

> 7. I can see why it is done this way, but not entirely comfortable
> with having duplicate information about repositories (e.g. the
> upstream repository) both in $HOME/.config/mr/available.d and
> $HOME/.config/vcsh/repo.d . For example, if you want to change to
> upstream repository, it becomes clumsy to do so; I think every host
> would have to be updated manually (at least the repo.d directories).
> Similarly, when a repository is activated, there are two places that
> have to be changed to reflect this that could become inconsistent with
> each other. Still thinking about this issue.

I cannot think of a smart way to reuse these data. The way I think
you are supposed to approach this is by making the change in
$HOME/.config/mr/available.d and add a pre-hook to the update
command to fire off the appropriate vcsh run … git config … commands
prior to running the update.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
"with sufficient thrust, pigs fly just fine. however, this is not
 necessarily a good idea. it is hard to be sure where they are going
 to land, and it could be dangerous sitting under them as they fly
 overhead."
                                                           -- rfc 1925
 
spamtraps: madduck.bogus at madduck.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: digital_signature_gpg.asc
Type: application/pgp-signature
Size: 1124 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
URL: <http://lists.madduck.net/pipermail/vcs-home/attachments/20130426/41e1a0de/attachment.pgp>