trying out vcsh

[Richard Hartmann]

On Fri, Apr 26, 2013 at 9:28 PM, martin f krafft <madduck at madduck.net>wrote:

> also sprach Brian May <brian at microcomaustralia.com.au> [2012.02.06.0116
> +0100]:
>



>   - git add requires the -f flag
>

I have been pondering if it's possible to tell vcsh about directories it's
managing exclusively.

Though even that starts to break down once you have

  zshrc
  zshrc.local

which carry public and private configuration.


  - 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?
>

Yes. I keep wondering if git smudge/clean filters could be abused to do
this.



>   - 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.
>

Both the problems of "global ignore file" and "caching of ignore data" are
still open.

Still, you need to ensure that the common case, i.e.

  vcsh enter foo
  git add bar

heeds the ignore data, no matter where it sits.


>
> > 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.
>

The actual adding is prevented by gitignore; but only to some extent as you
more or less start to default to `git add -f`.

I did think about a `vcsh status` a lot recently and a file tracked by two
repos would be an obvious candidate of things to list.


 > 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 …
>
>
The more I think about it, the more I am convinced that there's a way to
safely and sanely implement `vcsh add` and `vcsh commit`.

https://github.com/RichiH/vcsh/issues/45
https://github.com/RichiH/vcsh/issues/46


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.
>

Renames that span several machines are still an open question.