Re: various suggestions for mr
On Sun, Oct 30, 2011 at 1:26 PM, Adam Spiers vcs-h...@adamspiers.org wrote: On Sat, Oct 29, 2011 at 5:52 PM, Joey Hess j...@kitenet.net wrote: Adam Spiers wrote: However, the basename operation does not preserve the uniqueness property which $MR_REPO had, and that's why I say that we need an additional namespace. So pick an operation that does? tr / _ would do, for example. The other implicit requirement of this namespace was that it is easy to remember and type. The rest of my previous email gives the context for this requirement. OK, I've made a patch which fulfills this requirement pretty well. Hopefully you'll find it reasonably clean and unintrusive: https://github.com/aspiers/kitenet-mr/commit/b9a4e45aefe87c11ade1e4c4022e511f0d96d53c With this patch, if you have .mrconfig files defining repositories: [path/to/foo] ... [path/to/bar] ... then you can limit mr to only act on those via: mr -r foo,bar $action If there is a clash of directory names, then it can be resolved via a new special parameter 'name': [path/to/foo] checkout = git clone ... name = foo.git [path/to/a/different/foo] checkout = cvs checkout ... name = foo.cvs and then you can do: mr -r foo.cvs update etc. ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: various suggestions for mr
On Sat, Oct 29, 2011 at 5:52 PM, Joey Hess j...@kitenet.net wrote: Adam Spiers wrote: However, the basename operation does not preserve the uniqueness property which $MR_REPO had, and that's why I say that we need an additional namespace. So pick an operation that does? tr / _ would do, for example. The other implicit requirement of this namespace was that it is easy to remember and type. The rest of my previous email gives the context for this requirement. ___ 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 6:08 PM, Joey Hess j...@kitenet.net wrote:
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
I already did this; in fact I *had* to, in order to support GNU stow,
which requires the stow package namespace to be the list of
directories under a single stow directory. If you look for
$STOW_PKG_PATH in the code I originally posted, you'll see:
STOW_DIR=$HOME/.cfg
...
MR_NAME=`basename $MR_REPO`
...
STOW_PKG_PATH=$STOW_DIR/$MR_NAME
and then post_{checkout,update} call the install() function which
does:
ensure_symlink_exists $STOW_PKG_PATH ${MR_REPO%/}
However, the basename operation does not preserve the uniqueness
property which $MR_REPO had, and that's why I say that we need an
additional namespace. I can easily hack one, e.g.:
[$HOME/.my-repos/foo]
lib = MR_NAME=my-foo
[$HOME/.upstream-repos/foo]
lib = MR_NAME=your-foo
but that's ugly, and requires execution of shell code which would make
it difficult to implement a reverse lookup from package name to repo
path.
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.
Right. I feel like there's probably some elegant tweak we could make
to mr which would solve all this cleanly without much effort, but I'm
still trying to figure out what it is :-)
Let's examine the status quo. Currently mr has:
- a namespace for repositories (let's call it R) which is a subset
of the filesystem namespace, and values are specified in mr config
section headers,
- a namespace for mr config files (let's call it C) which is a
different subset of the filesystem namespace from R, and
- a 1:many mapping between C and R, i.e. each config file can
contain one or more repos.
I don't think there's anything wrong with this design - in fact that
1:many mapping is a nice configuration-time grouping mechanism, but
it's not quite enough to cater for some use cases.
For instance, sometimes it's just not acceptable to update all repos
at once, e.g. if you know that something is broken in repo X but you
really need the updates from repos Y and Z.
However mr cannot currently perform actions on repos at a finer
granularity than how they are grouped in config files. So if you
wanted to update your 'zsh' and 'emacs' repos, you could only do that
if they were in a config file containing no other repos. In general,
unless you restrict yourself to one config file per repo, there is no
way to get mr to operate on an arbitrary subset of R.
Similarly, if the 1:many mapping between C and R is used to logically
group repositories together (e.g. CLI, X11 and so on), there is no
way to get mr to operate on an arbitrary collection of groups.
Another issue is that whilst mr -c $config ls extracts mappings from
C to R, there's no way to extract the reverse mapping from R to C,
i.e. what config file do I need to use in order to perform actions
on repo X?
In summary, maybe the tweak I'm looking for is simply to decouple
configuration-time grouping of repos from run-time selection of which
repos to act on:
[$HOME/.my-repos/emacs]
name = emacs
[$HOME/.my-repos/zsh]
name = my-zsh
[$HOME/.upstream-repos/zsh]
name = upstream-zsh
which would allow:
$ mr -r my-zsh,emacs
And then the reverse mapping from R to C could be extracted via:
[DEFAULT]
showconfig = echo $MR_CONFIG
(except at the moment, MR_CONFIG isn't changed via includes
which could cause a problem.)
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home
Re: various suggestions for mr
Adam Spiers wrote:
I already did this; in fact I *had* to, in order to support GNU stow,
which requires the stow package namespace to be the list of
directories under a single stow directory. If you look for
$STOW_PKG_PATH in the code I originally posted, you'll see:
STOW_DIR=$HOME/.cfg
...
MR_NAME=`basename $MR_REPO`
...
STOW_PKG_PATH=$STOW_DIR/$MR_NAME
and then post_{checkout,update} call the install() function which
does:
ensure_symlink_exists $STOW_PKG_PATH ${MR_REPO%/}
However, the basename operation does not preserve the uniqueness
property which $MR_REPO had, and that's why I say that we need an
additional namespace.
So pick an operation that does? tr / _ would do, for example.
--
see shy jo
signature.asc
Description: Digital signature
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home
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
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: 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
