various suggestions for mr
Hi all,
I've been tracking my dot files and related stuff since around 1999,
and was very excited to discover this mailing list two years ago.
Since then I've only been able to lurk, but finally have a bit of
spare time to participate.
Since 2005 I have been using my own (as yet unpublished) Perl suite
called cfgctl to manage my dot files, which serves a similar to
purpose to mr - applying operations such as checkout, update
etc. to multiple repositories using multiple VCS backends. However
its shortcomings have increasingly irked me, and just when I was being
to resign myself to a complete rewrite, I noticed that mr had already
stolen most of my thunder :-)
The main differences between mr and cfgctl are:
- cfgctl's repository meta-data is written in pure Perl (and then
require'd at run-time) rather than one or more .INI-style
.mrconfig files. When I originally wrote it, needing
functionality akin to mr's skip parameter I naively thought that
this would give me maximum flexibility, and I mistakenly
underestimated the value of using a DSL.
- cfgctl only has a fixup hook (i.e. post-checkout/update), and no
hooks for any other actions.
- cfgctl is not nearly as extensible. It doesn't support writing
arbitrary new actions either globally or per repo.
- With hindsight cfgctl should have been made more shell-oriented in
general, because the kinds of tasks required for managing dot
files/repos, building/install packages etc. are much more easily
achieved in shell than in Perl.
- Adding support for a new VCS backend is more work in cfgctl,
because it requires writing a new Perl subclass of Cfg::Pkg::Base.
- cfgctl is harder to type than 'mr'.
So far mr is clearly winning :-) However, cfgctl does have one or two
tricks up its sleeve:
- Config modules / packages / repositories / whatever you want to
call them are indexed by name within a unique namespace, rather
than by directory path, and packages are grouped together into
sections. This allows you to easily run any of the actions on:
- all the packages (just like running mr from $HOME)
- a single package, just by specifying its name without needing
to know where it lives, e.g. cfgctl --update zsh would
update just the zsh repository
- a section (i.e. group of packages) just by specifying its name
(e.g. CLI or mail or Xorg) without needing to know where
anything lives, e.g. cfgctl --pull Xorg would update all
repos containing config relating to my Xorg (previously X11)
environment
- any packages matching a regular expression e.g.
cfgctl --update /emacs/
- cfgctl integrates out of the box with GNU stow. Based on this
list's frequency of discussion on fake bare / detached git
repos, it seems that most people here have an aversion to the
symlink approach to managing dot files in $HOME. This surprises
me as I have been using them very successfully for 12 years,
although I will leave that debate for another thread.
- cfgctl's internals have a reasonable amount of pod / comments.
mr's code, whilst mostly self-explanatory at the high-level, does
have a few very long subroutines which I feel would gain clarity
by being refactored into some appropriately-named smaller subs.
All in all, I feel that mr has a better design than cfgctl, and has
greater longevity. So last night I spent an hour or two doing a quick
proof of concept, to see whether I could extend mr to implement the
functionality I require, in particular the integration with GNU stow.
I'm pleased to say that so far it's looking very promising :-)
This is pretty much all that's needed:
- 8 - 8 - 8 - 8 - 8 -
[DEFAULT]
lib =
STOW_DIR=$HOME/.cfg
STOW_TARGET=$HOME
MR_NAME=`basename $MR_REPO`
#
set_stow_common_opts () {
STOW_PKG_PATH=$STOW_DIR/$MR_NAME
stow_common_opts=-t $STOW_TARGET -d $STOW_DIR
}
#
install () {
set_stow_common_opts
ensure_symlink_exists $STOW_PKG_PATH ${MR_REPO%/}
}
#
ensure_symlink_exists () {
[ $# = 2 ] || error CONFIG BUG: Usage: ensure_symlink_exists
SYMLINK TARGET
symlink=$1
required_target=$2
if [ -L $symlink ]; then
actual_target=`readlink $symlink`
if [ $actual_target = $required_target ]; then
return
else
error Symlink $symlink already points to
$actual_target, cannot point to $required_target; aborting.
fi
fi
[ -e $symlink ] error Cannot create symlink $symlink -
already exists; aborting.
ln -s $required_target $symlink
}
#
stow () {
set_stow_common_opts
command stow $stow_common_opts $MR_NAME
}
restow () {
set_stow_common_opts
command stow -R -p $stow_common_opts $MR_NAME
Re: various suggestions for mr
Sorry that I go slightly off-topic but you mentioned Gnu Stow, I looked it up and it seems very nice. i haven't run it yet, but (for those who don't want to read the long description) from the description it seems like a simple and elegant tool, which you give a directory (i want symlinks here) and a bunch of package directories (all files in here must be symlinked) and it will do the right thing on package additions and removals. Some people have actually already written symlink-managers, probably not knowing Stow existed. So yeah, looks neat. Carry on the discussion now :) Dieter ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: various suggestions for mr
On Fri, Oct 28, 2011 at 12:40 PM, Dieter Plaetinck die...@plaetinck.be wrote: Sorry that I go slightly off-topic but you mentioned Gnu Stow, I looked it up and it seems very nice. i haven't run it yet, but (for those who don't want to read the long description) from the description it seems like a simple and elegant tool, which you give a directory (i want symlinks here) and a bunch of package directories (all files in here must be symlinked) and it will do the right thing on package additions and removals. Yes, it is pretty nice (although the code base is very old-fashioned). One thing it does which I guess other symlink managers wouldn't, is called tree folding - i.e. it makes intelligent decisions about when to symlink to a subdirectory vs. to individual files within that subtree: http://www.gnu.org/software/stow/manual.html#SEC4 For example, imagine I have a stow package called 'foo' which wants to install a file to ~/local/lib/perl/Acme/Foo.pm (by install, I mean set up a symlink so that that path points to the Foo.pm inside the stow package). If ~/local doesn't already exist, and 'foo' is the only stow package which installs anywhere under ~/local, then stow's tree folding feature will ensure that ~/local is a symlink back to $STOW_DIR/foo/local/lib/perl/Acme/Foo.pm. However I might very well want to manually place other files inside ~/local which have nothing to do with stow, let alone the 'foo' stow package. It might make sense to have ~/local/lib/perl/Acme/ be a symlink to $STOW_DIR/foo/local/lib/perl/Acme/, but symlinks higher up the tree would be undesirable. This is easily overcome by creating a special stow package (which I call 'ANTIFOLD') which contains (empty) dummy files called .no-stow-folding in those trees. So I run a simple little custom shell script: $ unfold ~/local/lib/perl5 which creates an empty file $STOW_DIR/ANTIFOLD/local/lib/perl5/.no-stow-folding and (re)installs the 'ANTIFOLD' stow package, which causes stow to automatically split the ~/local/lib/perl5 tree open so that ~/local/ ~/local/lib/ ~/local/lib/perl5/ are all normal directories, and ~/local/lib/perl5/Acme becomes the symlink. Problem solved! ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: various suggestions for mr
On Fri, 28 Oct 2011 14:34:16 +0100 Adam Spiers vcs-h...@adamspiers.org wrote: On Fri, Oct 28, 2011 at 12:40 PM, Dieter Plaetinck die...@plaetinck.be wrote: Sorry that I go slightly off-topic but you mentioned Gnu Stow, I looked it up and it seems very nice. i haven't run it yet, but (for those who don't want to read the long description) from the description it seems like a simple and elegant tool, which you give a directory (i want symlinks here) and a bunch of package directories (all files in here must be symlinked) and it will do the right thing on package additions and removals. Yes, it is pretty nice (although the code base is very old-fashioned). One thing it does which I guess other symlink managers wouldn't, is called tree folding - i.e. it makes intelligent decisions about when to symlink to a subdirectory vs. to individual files within that subtree: http://www.gnu.org/software/stow/manual.html#SEC4 IMHO this feature is just common sense and it's among the first things I think of when I'm thinking what would I want a symlink manager to do?, so I would expect that people who implement symlink managers either also do something like this, or at least list it as a todo. For example, imagine I have a stow package called 'foo' which wants to install a file to ~/local/lib/perl/Acme/Foo.pm (by install, I mean set up a symlink so that that path points to the Foo.pm inside the stow package). If ~/local doesn't already exist, and 'foo' is the only stow package which installs anywhere under ~/local, then stow's tree folding feature will ensure that ~/local is a symlink back to $STOW_DIR/foo/local/lib/perl/Acme/Foo.pm. Don't you mean to $STOW_DIR/foo/local ? However I might very well want to manually place other files inside ~/local which have nothing to do with stow, let alone the 'foo' stow package. It might make sense to have ~/local/lib/perl/Acme/ be a symlink to $STOW_DIR/foo/local/lib/perl/Acme/, but symlinks higher up the tree would be undesirable. This is easily overcome by creating a special stow package (which I call 'ANTIFOLD') this seems a bit messy though. Once you go the way of having a tool automagically manage all your symlinks, why not just have the discipline to put all your files in appropriate packages? so that you never _need_ to create antifold packages? what you're doing seems a bit like running into the opposite direction. Dieter ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: various suggestions for mr
On Fri, Oct 28, 2011 at 2:43 PM, Dieter Plaetinck die...@plaetinck.be wrote: On Fri, 28 Oct 2011 14:34:16 +0100 Adam Spiers vcs-h...@adamspiers.org wrote: On Fri, Oct 28, 2011 at 12:40 PM, Dieter Plaetinck die...@plaetinck.be wrote: Sorry that I go slightly off-topic but you mentioned Gnu Stow, I looked it up and it seems very nice. i haven't run it yet, but (for those who don't want to read the long description) from the description it seems like a simple and elegant tool, which you give a directory (i want symlinks here) and a bunch of package directories (all files in here must be symlinked) and it will do the right thing on package additions and removals. Yes, it is pretty nice (although the code base is very old-fashioned). One thing it does which I guess other symlink managers wouldn't, is called tree folding - i.e. it makes intelligent decisions about when to symlink to a subdirectory vs. to individual files within that subtree: http://www.gnu.org/software/stow/manual.html#SEC4 IMHO this feature is just common sense and it's among the first things I think of when I'm thinking what would I want a symlink manager to do?, so I would expect that people who implement symlink managers either also do something like this, or at least list it as a todo. For example, imagine I have a stow package called 'foo' which wants to install a file to ~/local/lib/perl/Acme/Foo.pm (by install, I mean set up a symlink so that that path points to the Foo.pm inside the stow package). If ~/local doesn't already exist, and 'foo' is the only stow package which installs anywhere under ~/local, then stow's tree folding feature will ensure that ~/local is a symlink back to $STOW_DIR/foo/local/lib/perl/Acme/Foo.pm. Don't you mean to $STOW_DIR/foo/local ? Yes, sorry :) However I might very well want to manually place other files inside ~/local which have nothing to do with stow, let alone the 'foo' stow package. It might make sense to have ~/local/lib/perl/Acme/ be a symlink to $STOW_DIR/foo/local/lib/perl/Acme/, but symlinks higher up the tree would be undesirable. This is easily overcome by creating a special stow package (which I call 'ANTIFOLD') this seems a bit messy though. Once you go the way of having a tool automagically manage all your symlinks, why not just have the discipline to put all your files in appropriate packages? so that you never _need_ to create antifold packages? what you're doing seems a bit like running into the opposite direction. I don't understand what you mean; please could you elaborate? As far as I'm aware, all my files are nicely separated into appropriate packages, but that doesn't solve the problem. ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: various suggestions for mr
On Fri, Oct 28, 2011 at 3:26 PM, Dieter Plaetinck die...@plaetinck.be wrote: You wrote However I might very well want to manually place other files inside ~/local which have nothing to do with stow. Now you wrote As far as I'm aware, all my files are nicely separated into appropriate packages. That confuses me. I was responding to your approach in which you describe how you make stow unfold by creating a dummy 'antifold' package which would allow you store files not managed by stow in your ~/local Ah, I see! Well, in an ideal world, I would have time to ensure that every single file in my home directory is perfectly managed as a stow package :-) But in practice is there anyone who really achieves that? There are many cases where it just isn't worth the effort. Perhaps ~/local was a bad example, because that path is suggestive of a typical GNU-like installation sequence: ./configure --prefix=~/local make install in which case I agree it's not much more effort to do: ./configure --prefix=~/.stow/$pkgname make install # now install via stow but there are plenty of other examples where it is not pragmatic to spend the time ensuring every single file is controlled by stow, e.g. ./configure --prefix=~ make install# this puts some files in ~/doc # days/weeks/months later: emacs ~/doc/shopping-list.txt Without a ~/doc/.no-stow-folding file present, suddenly you have accidentally put your shopping list inside a third party piece of software :-) And it's not worth having a stow package for a shopping list which will probably be deleted tomorrow anyway. Another approach would be to add an option to stow that disables tree folding entirely; it shouldn't be hard to do that. But personally I find tree folding useful as long as it's managed well. ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: to symlink or not to symlink (was: Re: various suggestions for mr)
mumble.. [1] https://github.com/RichiH/vcsh ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
how to refactor path duplication in .mrconfig section headers?
If I have multiple repository paths all similar but spread across different .mrconfig files, e.g. in ~/.mrconfig [.config/mr] checkout = ... in ~/.config/mr/config.d/CLI: [$HOME/.git-repos/zsh] ... [$HOME/.git-repos/mutt] ... and in ~/.config/mr/config.d/GUI: [$HOME/.git-repos/urxvt] ... [$HOME/.git-repos/fonts] ... then the DRY fascist inside me is irked by the duplication. I'd much rather write this in ~/.mrconfig: [DEFAULT] lib = MR_GIT=$HOME/.git-repos [.config/mr] checkout = ... and then ~/.config/mr/config.d/CLI would have: [$MR_GIT/zsh] ... [$MR_GIT/mutt] ... and in ~/.config/mr/config.d/GUI: [$MR_GIT/urxvt] ... [$MR_GIT/fonts] ... However this doesn't work - I'm guessing that variable expansion in the section headers is done in Perl, so is not influenced by the shell-code in the DEFAULT lib? So is there any other way of avoiding this duplication? Thanks, Adam ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: Corrupt git-annex repository
Richard Hartmann wrote: fatal: ambiguous argument 'git-annex..refs/remotes/origin/git-annex': unknown revision or path not in the working tree. It seems your repository has lost the git-annex branch. You might try running git fsck to get a better view of the damage, but it's unlikely to fix anything. Your best bet is to re-clone the repository from origin, and preserve the git-annex file contents by moving .git/annex/objects from the broken repository to the new clone. You can also move .git/config over, to preserve the annex UUID setting (and any other configs of course). Then run git annex fsck to make sure its location tracking for that repository is accurate. -- see shy jo signature.asc Description: Digital signature ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: how to refactor path duplication in .mrconfig section headers?
On Fri, 28 Oct 2011 16:42:16 +0100, Adam Spiers vcs-h...@adamspiers.org wrote: If I have multiple repository paths all similar but spread across different .mrconfig files, e.g. in ~/.mrconfig [.config/mr] checkout = ... in ~/.config/mr/config.d/CLI: [$HOME/.git-repos/zsh] ... [$HOME/.git-repos/mutt] ... and in ~/.config/mr/config.d/GUI: [$HOME/.git-repos/urxvt] ... [$HOME/.git-repos/fonts] ... then the DRY fascist inside me is irked by the duplication. I'd much rather write this in ~/.mrconfig: [DEFAULT] lib = MR_GIT=$HOME/.git-repos [.config/mr] checkout = ... and then ~/.config/mr/config.d/CLI would have: [$MR_GIT/zsh] ... [$MR_GIT/mutt] ... and in ~/.config/mr/config.d/GUI: [$MR_GIT/urxvt] ... [$MR_GIT/fonts] ... However this doesn't work - I'm guessing that variable expansion in the section headers is done in Perl, so is not influenced by the shell-code in the DEFAULT lib? So is there any other way of avoiding this duplication? This should do the trick: [DEFAULT] lib = export MR_GIT=$HOME/.git-repos ^^ Thanks, Adam ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home Peace -- Pieter ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: how to refactor path duplication in .mrconfig section headers?
Adam Spiers wrote: If I have multiple repository paths all similar but spread across different .mrconfig files, e.g. in ~/.mrconfig [.config/mr] checkout = ... in ~/.config/mr/config.d/CLI: [$HOME/.git-repos/zsh] ... [$HOME/.git-repos/mutt] ... and in ~/.config/mr/config.d/GUI: [$HOME/.git-repos/urxvt] ... [$HOME/.git-repos/fonts] ... mr can look much nicer if you take advantage of locality and chaining. By locality, I mean putting a mrconfig close to the directories it checks out, rather than in some standards-body controlled directory like ~/.config. For example, you could have: ~/.mrconfig: [.git-repos/CLI] chain = true [.git-repos/GUI] skip = test_non_gui_machine chain = true ~/.git-repos/CLI/.mrconfig: [zsh] ... [mutt] ... ~/.git-repos/GUI/.mrconfig: [urxvt] ... [fonts] ... -- see shy jo signature.asc Description: Digital signature ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: various suggestions for mr
Adam Spiers wrote: So far mr is clearly winning :-) However, cfgctl does have one or two tricks up its sleeve: - Config modules / packages / repositories / whatever you want to call them are indexed by name within a unique namespace, rather than by directory path, and packages are grouped together into sections. This allows you to easily run any of the actions on: - all the packages (just like running mr from $HOME) - a single package, just by specifying its name without needing to know where it lives, e.g. cfgctl --update zsh would update just the zsh repository - a section (i.e. group of packages) just by specifying its name (e.g. CLI or mail or Xorg) without needing to know where anything lives, e.g. cfgctl --pull Xorg would update all repos containing config relating to my Xorg (previously X11) environment - any packages matching a regular expression e.g. cfgctl --update /emacs/ Having two namespaces for the same thing does not strike me as necessarily a good idea. But if you wanted to do that with mr, you could maybe take advantage of a little-known thing it does with determining the absolute path: joey@gnu:~mkdir namespace joey@gnu:~cd namespace joey@gnu:~/namespaceln -s ~/lib/sound joey@gnu:~/namespaceln -s ~/src/git-annex joey@gnu:~/namespacecd git-annex joey@gnu:~/namespace/git-annexmr update mr update: /home/joey/src/git-annex The only problem with this approach is that it only work when inside the symlinked directory, so mr update in ~/namespace won't update the directories symlinked to there. All in all, I feel that mr has a better design than cfgctl, and has greater longevity. So last night I spent an hour or two doing a quick proof of concept, to see whether I could extend mr to implement the functionality I require, in particular the integration with GNU stow. I'm pleased to say that so far it's looking very promising :-) This is pretty much all that's needed: This seems close to something I could put in mr as an includable library. Could use some documentation though. -- see shy jo signature.asc Description: Digital signature ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: Corrupt git-annex repository
On Fri, Oct 28, 2011 at 18:33, Joey Hess j...@kitenet.net wrote: It seems your repository has lost the git-annex branch. No, the branch was still there. If you want the contents, I can send them off-list. You might try running git fsck to get a better view of the damage, but it's unlikely to fix anything. I had hoped to salvage the existing repo, but I will rather play it safe and make _sure_ the data is correct. Your best bet is to re-clone the repository from origin, and preserve the git-annex file contents by moving .git/annex/objects from the broken repository to the new clone. You can also move .git/config over, to preserve the annex UUID setting (and any other configs of course). Then run git annex fsck to make sure its location tracking for that repository is accurate. Sounds like a good idea. One question about the UUID, though. I created a repo as replacement for a borked one and after running `git annex init foo`, it set a UUID for that repo. I copied over the old UUID, hoping to reduce clutter from unused repos, but git annex status still told me the local repo had the initial UUID. The above seems to imply that this should work. The one problem with cloning a new repo is that I will need to restore mtime semi-by-hand. You mentioned the gitogether at Google talking about metadata; what, if anything, did come from that? Finally, I think there's still no way to declare a repo permanently gone, i.e. so that it will never show up in any status reports or similar ever again. Or did I just not find it? Richard ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: to symlink or not to symlink (was: Re: various suggestions for mr)
On Fri, Oct 28, 2011 at 18:23, Adam Spiers vcs-h...@adamspiers.org wrote: Ah thanks, I did wonder about that. Yah, I hope the old version will drop off of google at some point to avoid confusion. Sure, there's no right and wrong. It sounds like your preference is based on a sense of aesthetics rather than more concrete technical arguments? Not that there's anything wrong with that - aesthetics are important too. But if you are aware of some specific technical advantages of avoiding symlinks, I'd be very interested to hear them so that I can weigh them up against the alternative. Well, symlinks (on files!) work pretty much exactly as files in the relevant use cases so there's no real downside. Sure, although that's assuming you have a shell to hand. Almost always the case, but sometimes it's handy to be able to see with nothing more than a file manager (e.g. sftp). Definitely not a use case for me. If you really do access $HOME via ftp, that might be useful, though. Though, arguably, if you are not in an interactive shell, what do you care about where what info lives? More significantly, it doesn't tell you which files are *not* managed by it. Without symlinks, you have to iterate over all your repositories, and then filter out those files from the set of files you are interested in looking at. Valid point, that. Though my fix to the ~/.gitignore issue will address that. Well, I'm obviously more prone to mistakes than you ;-) But that aside, I want this setup to support checkout of a large number of third party software packages which I'm either trying out, using, or even collaborating with development. In that case, there are a large number of unfamiliar looking files installed in my home directory, so it's not always immediately obvious where files have come from. Those will not be symlinks, though. So all you get is is this in any repo, not what program does that belong to. Personally, I like to run temp stuff under a temp user, simply linking the .Xauthority between the two. That avoids hacks like kdesu. To clarify, I'm thinking of using dvcs-autosync in parallel with mr, not instead of it. Then I can't comment as I don't know what it does. I don't know vcsh well enough to know which tool you are referring to or what it would hide. But I can't see how an approach which (in my very limited understanding) is based on altering environment variables would work without requiring a restart of my editor. If you're a vim user who starts up your editor every time you edit a new file, that will work fine for you. But it doesn't gel with my personal workflow. :!vcsh run vim git commit -a Not if there's a bullet-proof barrier in between your gun and your foot :-) Which is exactly my point - I'm saying that if you had the same (relative) file path in two different stow packages, stow will refuse to install one over the top of the other; instead it will tell you that you're trying to do something stupid. It might deflect into your groin ;) vcsh will fetch the files from the remote repo, run ls-files to see if there are any conflicts and only if there are not will it merge. If there is a conflict it will error out and tell you to fix it by hand. I meant disadvantages to using symlinks in general. It doesn't really matter what method you use for managing symlinks, the end result is pretty much the same (modulo tree folding). Well, if you symlink a directory and enter that directory, you will get strange effects. Sane shells like zsh will try to prevent surprises, but session restoration after logging in again (think konsole, etc) will make you end up in the real directory, not the symlink. Icky. - An accidental rm ~/.zshrc seems much more likely than an accidental Agreed, but in that case, both models can restore in the blink of an eye. I was disregarding that as it's easy to fix. Losing your repo is not (for you). And no, it's not likely, but you asked for possible downsides :) And in the former case, if you are using symlinks, all you lose is a symlink, whereas with detached git working directories, you lose the whole file which may contain changes not yet in the git index or repo. Agreed. Richard ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: Corrupt git-annex repository
Richard Hartmann wrote: No, the branch was still there. If you want the contents, I can send them off-list. Hmm, either the main git-annex branch or origin/git-annex seems to be missing based on the error message, and I don't think it's the latter. Sounds like a good idea. One question about the UUID, though. I created a repo as replacement for a borked one and after running `git annex init foo`, it set a UUID for that repo. I copied over the old UUID, hoping to reduce clutter from unused repos, but git annex status still told me the local repo had the initial UUID. The above seems to imply that this should work. The only place the uuid for a repository is stored is .git/config. Finally, I think there's still no way to declare a repo permanently gone, i.e. so that it will never show up in any status reports or similar ever again. Or did I just not find it? There is not. -- see shy jo signature.asc Description: Digital signature ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: Corrupt git-annex repository
On Fri, Oct 28, 2011 at 21:23, Joey Hess j...@kitenet.net wrote: Hmm, either the main git-annex branch or origin/git-annex seems to be missing based on the error message, and I don't think it's the latter. Both are there. The only place the uuid for a repository is stored is .git/config. % git init . Initialized empty Git repository in uuid/.git/ % git annex init 'test' init test ok % grep uuid .git/config uuid = ef90acc8-019e-11e1-9354-9f042d197907 % sed -i 's/ef90acc8-019e-11e1-9354-9f042d197907/06e409ba-019f-11e1-86b0-3bb33a255d70/' .git/config % git annex status supported backends: WORM SHA1 SHA256 SHA512 SHA224 SHA384 SHA1E SHA256E SHA512E SHA224E SHA384E URL supported remote types: git S3 bup directory rsync web hook known repositories: ef90acc8-019e-11e1-9354-9f042d197907 -- test local annex keys: 0 local annex size: 0 bytes total annex keys: 0 total annex size: 0 bytes backend usage: % There is not. Why? If a UUID is marked as 'gone forever', the other repos could pick that information up over time and purge it from their own stores. Richard ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: Corrupt git-annex repository
Richard Hartmann wrote: On Fri, Oct 28, 2011 at 21:23, Joey Hess j...@kitenet.net wrote: Hmm, either the main git-annex branch or origin/git-annex seems to be missing based on the error message, and I don't think it's the latter. Both are there. git log git-annex..origin/git-annex fails, so both are *not* there. (git branch may show them, which means nothing when your repository is corrupted) The only place the uuid for a repository is stored is .git/config. ef90acc8-019e-11e1-9354-9f042d197907 -- test What I meant to say is that the only place that git-annex looks to determine the UUID of the current repository is .git/config. Of course it *stores* information about a UUID in various places -- in your example you told it to store a description test for that UUID, so status displays that even if it doesn't know of any repository that has that UUID. Notice it did not say test (here) There is not. Why? If a UUID is marked as 'gone forever', the other repos could pick that information up over time and purge it from their own stores. Because I don't know how to design a system that has auto-merging and supports outright deletion of UUIDs. Consider this location log file: 1319837256.637657s 1 82e27eac-00d2-11e1-98af-a7c8649fdab4 1319835945.041525s 0 d819e6c8-01a7-11e1-af2b-9f1a8049ae44 If d819e6c8-01a7-11e1-af2b-9f1a8049ae44 is gone forever and is removed, the log file will then contain: 1319837256.637657s 1 82e27eac-00d2-11e1-98af-a7c8649fdab4 But other repositories where that operation has not been performed will still contain the first file. When one of them is union merged back into it, the removed line will necessarily come back. The best that could be done is to add a fourth trust state that is like untrusted UUIDs but causes them to be hidden from view. But this would mean additional work, to handle this edge case -- and simply changing the description of a dead repository seems to work nearly as well. -- see shy jo signature.asc Description: Digital signature ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: how to refactor path duplication in .mrconfig section headers?
On Fri, Oct 28, 2011 at 5:40 PM, Pieter Praet pie...@praet.org wrote: However this doesn't work - I'm guessing that variable expansion in the section headers is done in Perl, so is not influenced by the shell-code in the DEFAULT lib? So is there any other way of avoiding this duplication? This should do the trick: [DEFAULT] lib = export MR_GIT=$HOME/.git-repos ^^ That was the first thing I tried, but I'm pretty sure it didn't work, hence my guess above. ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: how to refactor path duplication in .mrconfig section headers?
On Fri, Oct 28, 2011 at 8:03 PM, Richard Hartmann richih.mailingl...@gmail.com wrote: On Fri, Oct 28, 2011 at 18:45, Joey Hess j...@kitenet.net wrote: mr can look much nicer if you take advantage of locality and chaining. By locality, I mean putting a mrconfig close to the directories it checks out, rather than in some standards-body controlled directory like ~/.config. You mean that ~/.git-repos contains the actual repos? By you are you referring to me or Joey? Yes, my intention was that ~/.git-repos contains all git repos (or at least most). I.e. that every repo comes with its own .mrconfig? If you mean, every repo *contains* its own .mrconfig, then I don't see how that would work - wouldn't it create a chicken and egg situation prior to first checkout? I used that approach at first, but I feel the symlinks (here they are ;) from ~/.config/mr/available.de to ~/.config/mr/config.d are more flexible. I like that scheme with things like apache (sites-available vs. sites-enabled) although with mr config, the same effect can by automated via the special 'skip' parameter, which to me seems nicer than manually fiddling with symlinks. Plus, you get central management of all mr configs. Right on the money! This is the real reason I want all my mr configs in one place - I want them within a single git repo which I can version control everywhere. Then bootstrapping my entire environment is as simple as: [$HOME/.config/mr] checkout = ... chain = true That can be handy when you want to make a global update on a machine which does not have all your mr-controlled repos checked out. If I understand that correctly, you are saying pretty much the same thing as me. ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
