Re: trying out vcsh
On Fri, Apr 26, 2013 at 9:28 PM, martin f krafft wrote:
> also sprach Brian May [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.
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home
Re: trying out vcsh
also sprach Brian May [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.bo...@madduck.net
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home
Re: trying out vcsh
On Mon, Feb 6, 2012 at 01:16, Brian May wrote: > Previously I managed my configuration using the "most trendy" vcs > available (ie. starting with rcs!) and using my set of scripts to > customize the configuration for every host. Aye, been there, done that ;) > 1. Instructions should perhaps link to > http://lists.madduck.net/listinfo/vcs-home instead of the email > address. Fixed in master > 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? Yes, use vcsh run foo git config ... > 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? Correct. > 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? vcsh will change your repo's configs to refer to .gitignore.d/foo, instead. This is done to avoid conflicts. > 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? Yes-ish. The gitignore setup vcsh does for you will guard against most mistakes. Still, I have been thinking about this topic recently, but I didn't come up with a definite answer on what to do in the long term, yet. Fwiw, I will most likely implement something like `vcsh whereis` that tells you in what repo a file lives, soonish. > 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. Possible, but I am not sure if that's within the scope of vcsh. whereis will do part of what you want and you can script around this. Usually, you would do vcsh enter foo git add file git commit other stuff yet more stuff git commit -a exit > 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. $HOME/.config/mr/available.d holds the configs $HOME/.config/mr/config.d holds the configs activated on this host $HOME/.config/vcsh/repo.d holds the actual repo If there's anything else, just ask :) Richard ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
trying out vcsh
Hello, Just recently I heard of this vcsh thing, just some of my initial thoughts. Previously I managed my configuration using the "most trendy" vcs available (ie. starting with rcs!) and using my set of scripts to customize the configuration for every host. Unfortunately I came to realize that while the approach was very flexible, it is also rather complicated. I made it too flexible and as such too complicated. Also customizing config files for each host doesn't work so well when config files are shared between hosts, e.g. shared NFS. Much better to use the same files when possible, and e.g. have the bash scripts change behaviour depending on the system when logging in. So I have been looking out for a simpler approach, when I saw vcsh. So far it seems like a really good approach. Just some minor concerns though: 1. Instructions should perhaps link to http://lists.madduck.net/listinfo/vcs-home instead of the email address. 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? 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? 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? 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? 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 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. Thanks -- Brian May ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
