also sprach Brian May <br...@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.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