Gmanehttp://gmane.org/img/gmane-25t.pnghttp://gmane.org
Another approach to vcsh hook/sparse checkout setuphttp://comments.gmane.org/gmane.comp.version-control.home-dir/940
<pre>I just landed an update for my homedir repos that enables the use and bootstrapping of vcsh hooks. This in turn enables sparse checkouts (e.g. for keeping per-repo README files out of $HOME) and other custom repo settings (esp. `git config pull.rebase true`).
I posted in a GitHub issue thread with some related discussion:
https://github.com/RichiH/vcsh/issues/120#issuecomment-119377499 &lt;https://github.com/RichiH/vcsh/issues/120#issuecomment-119377499&gt;
I’ve replicated the comment below, slightly reformatted for email, since I recall there are folks with limited bandwidth who may not want to hit GitHub and/or for discussion here.
— John
-------------
I *finally* went through the setup of vcsh hooks and sparse checkout for my setup. I took a slightly different route than &lt; at &gt;vdemeester and &lt; at &gt;marklee77. Instead of loading up the bootstrap script with the hooks that must be run on the "root" repo, I use some extra `mr.post-clone.*` style symlinks to ensure that my root repo (which vcsh knows as `mr` for historical reasons) gets everything run on it the first time out. See jwhitley/vcsh-root&lt; at &gt;30b0d49 &lt;https://github.com/jwhitley/vcsh-root/commit/30b0d495c2cbe47ae9617ace9c2c14720d961d78&gt;[1], and jwhitley/vcsh-root&lt; at &gt;3dc9057 &lt;https://github.com/jwhitley/vcsh-root/commit/3dc9057f421a3829fbc30bf0c33df27a61bad229&gt;[2] for examples.
The nice thing about this approach is that the bootstrap script takes on only a one line change[3], to do the retroactive sparse checkout cleanup: `vcsh mr read-tree -md HEAD`. After that, the hooks are all in place and `mr update` invokes vcsh on the remaining child repos correctly.
If I ever got too many hooks in place, it'd be easy enough to run `vcsh upgrade mr` in the bootstrap script and remove the extra `mr.*` symlinks.
It'd be interesting to bake out a simplified vcsh-only demo root repo that incorporates just (e.g.) the `core.sparseCheckout` and the `pull.rebase` settings. It's a little unclear how to best do this: maybe just `vcsh clone` a whole list of repos in the bootstrap script or maybe in `root.post-clone-retired.00-clone-child-repos`? vcsh itself doesn't have a concept of available-but-uncloned repos AFAICT; that's been mr's job in setups like mine.
Last but not least, hat tip to &lt; at &gt;marklee77 for having a Vagrantfile around and using sparse checkout to ignore it. Brilliant, and I've adopted that in slightly different forms in the `master`[4] and `bootstrap`[5] branches' Vagrantfiles. The `master` version uses an inline-modified bootstrap script to clone the *local* repo into the VM's homedir for testing. The `bootstrap` version uses the *local bootstrap.sh* to test bootstrap changes vs. the existing remote `master` branch.
[1] https://github.com/jwhitley/vcsh-root/commit/30b0d495c2cbe47ae9617ace9c2c14720d961d78 &lt;https://github.com/jwhitley/vcsh-root/commit/30b0d495c2cbe47ae9617ace9c2c14720d961d78&gt;
[2] https://github.com/jwhitley/vcsh-root/commit/3dc9057f421a3829fbc30bf0c33df27a61bad229 &lt;https://github.com/jwhitley/vcsh-root/commit/3dc9057f421a3829fbc30bf0c33df27a61bad229&gt;
[3] https://github.com/jwhitley/vcsh-root/blob/b7b5947442eef6f8ed94f7aa62f4a11833c732db/bootstrap.sh#L37 &lt;https://github.com/jwhitley/vcsh-root/blob/b7b5947442eef6f8ed94f7aa62f4a11833c732db/bootstrap.sh#L37&gt;
[4] https://github.com/jwhitley/vcsh-root/blob/master/Vagrantfile &lt;https://github.com/jwhitley/vcsh-root/blob/master/Vagrantfile&gt;
[5] https://github.com/jwhitley/vcsh-root/blob/bootstrap/Vagrantfile &lt;https://github.com/jwhitley/vcsh-root/blob/bootstrap/Vagrantfile&gt;
_______________________________________________
vcs-home mailing list
vcs-home&lt; at &gt;lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home</pre>John Whitley2015-07-08T00:11:01vcsh: use branches instead of repos?http://comments.gmane.org/gmane.comp.version-control.home-dir/925
<pre>Hi,
(I couldn't find this
on a quick google search, or on github issues search)
Would it be possible to use a single repo, with each configuration (vim,
zsh, etc) being a *branch* in that repo, rather than each config being
its own repo?
I know vcsh does not do that at present; I'm asking if that sounds like
something that may be a good idea, as an "option".
thanks
sitaram
</pre>Sitaram Chamarty2015-06-26T06:37:37Quieting ``mr`` outputhttp://comments.gmane.org/gmane.comp.version-control.home-dir/923
<pre>All,
I've been using ``mr`` to track my various projects in git,
along with my home directory. I really like how it allows me to
organize and track my work. For some time, I've been using a
home-grown utility to quiet down the output from ``mr status``.
In this way, I can run ``mr status`` from my home directory and
check the status of all 130+ repositories at once without having
to scroll back through twice that many lines of text looking for
something interesting.
The output from ``mr status`` by default looks something like
the following::
mr status: /home/mike/.
mr status: /home/mike/.vim
M vimrc
mr status: /home/mike/projects/ProjectOne
mr status: /home/mike/projects/ProjectTwo
[...]
mr status: /home/mike/projects/ProjectN
I could grep away the blank lines and the ``mr status:...``
lines, but this makes it difficult in general to tell which
repository contains the changes. I prefer to keep the ``mr
status:...`` lines for repositories with changes, but squelch
them otherwise. In the above example, my preferred output
would be:
mr status: /home/mike/.vim
M vimrc
In case someone else might find it useful, I've published this
Python-based utility (which I've named ``ptee`` for "Progress
Tee") on the Python Package Index. I alias ``mr`` to point to
the below script (which I call ``mrwrap``) so that I can execute
``mr status`` and get the quiet output I prefer.
To try this out::
pip install ptee
alias mr='mrwrap'
Then save the text between the ``---cut`` lines as ``mrwrap``
and make it executable. The ``ptee`` utility can be found here
for manual downloading:
https://pypi.python.org/pypi?name=ptee&amp;version=0.2.0&amp;:action=display
---cut mrwrap---
#!/bin/bash
mrtee()
{
ptee \
--regex '^mr (status|update|push): /' \
--regex '^(Everything|Already) up-to-date' \
--regex '^\s*$' \
--heading-regex '^mr \S+: finished '
}
mr "$&lt; at &gt;" 2&gt;&amp;1 | mrtee
---cut mrwrap---
Michael Henry
</pre>Michael Henry2015-06-25T01:07:39Ikiwiki (https://vcs-home.branchable.com/) site brokenhttp://comments.gmane.org/gmane.comp.version-control.home-dir/920
<pre>I get the following back:
The site vcs-home.branchable.com is not here yet.
Does anyone know what has happened?
</pre>Christopher Baines2015-05-05T15:28:40similar projecthttp://comments.gmane.org/gmane.comp.version-control.home-dir/916
<pre>Hi,
I found vcsh today while looking for similar projects to mine[1] that
exploited GIT_DIR to do overlaid git repos. It seems that vcsh and
multigit are quite similar although they started out from trying to
solve different problems. Multigit started from a
git-based-package-manager angle (for Lua modules) while vcsh started
from a git-based-home-directory-manager angle. You can see that
difference in flavor in the command line options and features,
although many options are strikingly similar. Anyway it is nice to see
that other people "get it". It's quite a powerful and low-tech way to
combine modularity and change control.
Happy coding,
Cosmin.
[1] https://github.com/capr/multigit
</pre>Cosmin Apreutesei2015-04-09T08:56:46Constant merging requiredhttp://comments.gmane.org/gmane.comp.version-control.home-dir/910
<pre>Hi there,
I've been using vcsh/mr for quite a while now on my Ubuntu 14.04 client(s).
My setup is: multiple machines (4) and a bitbucket account to keep
everything in sync.
However I've noticed the following:
Suppose I make modifications on two machines and commit them on both.
Next thing on machine A is 'mr up', which causes an automatic recursive
merge. Now I can run mr push to push things to bitbucket.
On machine B I run 'mr up', which brings up a merge window. I accept the
merge and push the changes again to bitbucket.
Coming back to machine A, running 'mr up' I have to merge again and push
the changes to bitbucket...
...and here goes the loop: Next thing which occurs on machine B is a merge.
I this way I can generate an infinite amount of empty merges.
This only way to fix this is running
git fetch origin
git reset --hard origin/master
on all machines...
Here is an example git log
# vcsh bash_user lg
* 5f8f428 (HEAD, origin/master, master) Merge branch 'master' of
bitbucket.org:Thubo/dotconfig.bash_user
|\
| * d4cf1f8 Merge branch 'master' of bitbucket.org:
Thubo/dotconfig.bash_user
| |\
| |/
|/|
* | 72df2b0 Merge branch 'master' of bitbucket.org:
Thubo/dotconfig.bash_user
|\ \
| |/
| * 69e68c4 Merge branch 'master' of bitbucket.org:
Thubo/dotconfig.bash_user
| |\
| |/
|/|
* | 46ab5b0 Merge branch 'master' of bitbucket.org:
Thubo/dotconfig.bash_user
|\ \
| |/
Any ideas who to fix this? (Maybe this is a general git problem or I'm
simply too stupid to use things properly - nevertheless I would like to
know how I can stop this behavior ;) )
Thanks a lot in advance
Cheers
Matthias
</pre>Matthias Thubauville2015-03-28T21:09:21Noob questionhttp://comments.gmane.org/gmane.comp.version-control.home-dir/905
<pre>Hello,
I'm discovering vcsh and try to write a noobs howto in french but I get
stuck really early. This is my test :
echo "test" &gt;.totorc
vcsh init toto
vcsh toto add .totorc
vcsh commit -m "first commit"
This will "forget" my -m comment, open $EDITOR and let me type it again.
Then :
echo "Another test" &gt;&gt;.totorc
vcsh commit
toto:
Sur la branche master
Modifications qui ne seront pas validées :
modifié : .totorc
Which I would translate as :
toto:
On branch master
Changes not staged for commit:
modified : .totorc
If I add .totorc once again it will get committed but this makes it useless.
==========================================================
Second try (rm -rf .config/vcsh), this time specifying the repository
name to vcsh when committing (thus sending the command to git directly) :
vcsh init toto
vcsh toto add .totorc
vcsh toto commit -m "first commit"
[master (commit racine) 96f8587] first commit
1 file changed, 2 insertions(+)
create mode 100644 .totorc
The -m is recognized
echo "Another test" &gt;&gt;.totorc
vcsh toto commit -m "second commit"
toto:
On branch master
Changes not staged for commit:
modified : .totorc
:-( Same fail.
===========================================================
Can you explain to me what I'm doing wrong ?
I'm using Debian's version 1.20140508-1
Many thanks,
JC
_______________________________________________
vcs-home mailing list
vcs-home&lt; at &gt;lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home</pre>Jean-Christophe Boggio2015-03-07T15:07:36Dotfilemanager 1.0.0 releasedhttp://comments.gmane.org/gmane.comp.version-control.home-dir/904
<pre>https://github.com/seanh/dotfilemanager
No new features or bug fixes - I just finally published it to PyPI so
you can do:
pip install dotfilemanager
I still use this little script all the time, has been doing just what it
was meant to for five years.
There are better dotfile managers with more interesting feature sets out
there by now, but where dotfilemanager shines is simplicity - there
isn't even any configuration, all it does is handle making and cleaning
up symlinks for you.
If I were to do any more work on it the first thing I'd do is write a
set of simple automated tests for it so I can make changes and know I
haven't broken anything. But honestly I'm not sure it needs any work.
</pre>Sean Hammond2015-02-23T17:25:04Spam on vcs-home wiki recentchanges pagehttp://comments.gmane.org/gmane.comp.version-control.home-dir/896
<pre>The page http://vcs-home.branchable.com/recentchanges/ contains spam.
Reverting it meant deleting recentchanges.mdwn. How do I get my change
onto the wiki?
Thanks.
commit 9807de80aa295bcd76704e1e9672116988410b73
Author: Edward Betts &lt;edward-gqVrtmV0iFvQT0dZR+AlfA&lt; at &gt;public.gmane.org&gt;
Date: Mon Jan 12 14:43:50 2015 +0000
revert spam
recentchanges.mdwn | 15 ---------------
1 file changed, 15 deletions(-)
</pre>Edward Betts2015-02-11T09:21:52newbie: "fake" README for remote of a `vcsh` repo?http://comments.gmane.org/gmane.comp.version-control.home-dir/880
<pre>
For the gory details, see
https://github.com/RichiH/vcsh/issues/147
but my request boils down to this:
I'm using `vcsh` to VC files in $HOME (et al), but
1. I want to leverage the goodness of `vcsh`/`mr` and have repos for bash, emacs, ssh, etc
2. I also want to have remote repos (for now, privates on Bitbucket)
3. I also want my remotes to have READMEs.
4. I'm trying to standardize my READMEs on reST (which is advantageous for some scientific projects on which I'm *really* working)
So I'd like to know, how to create a README.rst in a "fake" but committable vcsh repo, rather than in $HOME ? Note I'd bail to Bitbucket's web UI to create my READMEs, but their web editor will only take Markdown, so I'd very much prefer to create a ./README.rst for my project ... just not in $HOME.
TIA, Tom Roche &lt;Tom_Roche-e+AXbWqSrlAAvxtiuMwx3w&lt; at &gt;public.gmane.org&gt;
</pre>Tom Roche2015-02-10T01:59:53OpenBSD Porthttp://comments.gmane.org/gmane.comp.version-control.home-dir/879
<pre>Hi there,
I'm planning on porting your wonderful bit of software (as well as the
equally wonderul myrepos) to my favorite blowfish flavored OS, and just
wanted to check that no one else was in the process of doing this, as I
don't want to step on any toes or duplicate effort.
Also, you mention in PACKAGING.md that a pre-compiled man page is available
as an alternative to the ronn one. I would prefer to keep the dependencies
as minimal as possible, &amp; so am planning on using the man page from the
homebrew branch, but wanted to make sure that it's up to date.
Many thanks for creating such an awesome bit of software that has made my
life a whole lot easier!
Cheers,
Toby
</pre>Toby Slight2015-02-04T09:26:02vim-fugitive now works correctly with vcshhttp://comments.gmane.org/gmane.comp.version-control.home-dir/878
<pre>My PR for tpope/vim-fugitive#415 [1] on GitHub was just accepted, which enhances vim-fugitive to work with vcsh. More specifically, fugitive now works correctly when $GIT_DIR is set ,but core.worktree is set instead of $GIT_WORK_TREE.
Vim users, after updating to the latest vim-fugitive, the following now works:
# :Gwrite and other fugitive commands are now defined and work
Cheers,
John
[1] https://github.com/tpope/vim-fugitive/issues/415
</pre>John Whitley2014-11-06T21:19:41Problemes with tab completion for fileshttp://comments.gmane.org/gmane.comp.version-control.home-dir/877
<pre>Hi,
my setup is:
- vcsh 1.20141009
- zsh 4.3.17 (i686-pc-linux-gnu)
when i hit
"vcsh [repo] add &lt;tab&gt;"
i only get
"Completing `modified file' or `untracked file'".
If I eneter the repo via "vcsh enter [repo]" the tab completion works.
Is this how it shoult work or is it a bug?
Greetings
Philipp
</pre>Philipp Dieter2014-10-17T21:12:27ls tricks for git-annex?http://comments.gmane.org/gmane.comp.version-control.home-dir/869
<pre>So now that I am using git-annex for almost all of my stuff, I need
to stay sane when using normal tools (which now see symlinks),
mostly /bin/ls -l (which currently makes my eyes bleed until I add -L).
Sure, I could add -L to my existing /bin/ls alias, but I don't
*want* to do that on all symlinks.
I also don't really want to pipe output from /bin/ls through sed or
what-have-you, because that can just get very messy, and breaks
colouring too.
So, what do you do?
</pre>martin f krafft2014-09-25T05:34:00git annex loses track of files it has locallyhttp://comments.gmane.org/gmane.comp.version-control.home-dir/855
<pre>Have a look at this:
fishbowl:…ka/photos|master|2014.08.29% file *
Foto1.JPG: symbolic link to `../.git/annex/objects/mg/JZ/SHA256E-s3103631--5ba8f6d0b7a51700f03ce1c2ddc774a68c168a07f6b30585ffe3c749e8995ba1.JPG/SHA256E-s3103631--5ba8f6d0b7a51700f03ce1c2ddc774a68c168a07f6b30585ffe3c749e8995ba1.JPG'
fishbowl:…ka/photos|master|2014.08.29% file -L *
Foto1.JPG: JPEG image data, EXIF standard 2.21
So the file is locally available. However:
fishbowl:…ka/photos|master|2014.08.29% git annex whereis
whereis Foto1.JPG (3 copies)
296d71bb-1aef-4381-b15a-8c9f13836254 -- madduck&lt; at &gt;albatross:~/family/veronika/photos [albatross]
81162b32-96f0-4573-94ef-e2930a439bfb -- penny-VDF0TkuUCuxm6qwXn5jAlQ&lt; at &gt;public.gmane.org:~/v-photos
ecedc885-2ecd-4f3a-8bae-ae2c27ae1f37 -- madduck&lt; at &gt;julia:/srv/git/priv/family/veronika/photos.git [origin]
ok
git-annex does not know about it. Consequently, I cannot get it:
fishbowl:…ka/photos|master|2014.08.29% git annex get .
# nothing happens
So part of git-annex thinks the file is present and another thinks
it's not…
I have to drop/get and then it works:
fishbowl:…ka/photos|master|2014.08.29% git annex drop .
drop Foto1.JPG (checking albatross...) ok
(Recording state in git...)
fishbowl:…ka/photos|master|2014.08.29% git annex get .
get Foto1.JPG (from albatross...)
SHA256E-s3103631--5ba8f6d0b7a51700f03ce1c2ddc774a68c168a07f6b30585ffe3c749e8995ba1.JPG
3,103,631 100% 42.90MB/s 0:00:00 (xfr#1, to-chk=0/1)
ok
(Recording state in git...)
fishbowl:…ka/photos|master|2014.08.29% git annex whereis
whereis Foto1.JPG (4 copies)
288d720f-62e5-4703-b74e-8511af1715c4 -- madduck&lt; at &gt;fishbowl:~/family/veronika/photos [here]
296d71bb-1aef-4381-b15a-8c9f13836254 -- madduck&lt; at &gt;albatross:~/family/veronika/photos [albatross]
81162b32-96f0-4573-94ef-e2930a439bfb -- penny-VDF0TkuUCuxm6qwXn5jAlQ&lt; at &gt;public.gmane.org:~/v-photos
ecedc885-2ecd-4f3a-8bae-ae2c27ae1f37 -- madduck&lt; at &gt;julia:/srv/git/priv/family/veronika/photos.git [origin]
ok
The reason may be that I accidentally set trust=dead, but then
changed it back to semitrusted.
Is there another way than drop/get on all files to restore this?
I've run "repair", "reinject" and "fix", but nothing seemed to fix
the problem.
Thanks,
</pre>martin f krafft2014-09-09T14:05:36automating git-annex relationshipshttp://comments.gmane.org/gmane.comp.version-control.home-dir/853
<pre>I found some time to play with myrepos &amp; vcsh &amp; git-annex and it's
looking good. Thank you Joey and RichiH for taking this field so
much further! There are still a couple of warts, but we are
lightyears from where we were when I last could look into this
stuff. \o/
mr+vcsh are now tracking most of my config via git.madduck.net, so
it's a spoke-design.
I also want to use one (or two) central Git servers for my git-annex
stuff. However, ideally, data can be exchanged between my laptop and
the desktop directly. This can be easily done simply by adding the
appropriate Git remotes on all ends…
… except I'd really rather find a way to automate this!
Has anyone come up with a smart way of auto-configuring
relationships between hosts? git-annex keeps track of where files
are, so theoretically, it should be able to auto-configure the
remotes if I tell it that two remotes are directly in reach of each
other?
The info output on one host says:
288d720f-62e5-4703-b74e-8511af1715c4 -- madduck&lt; at &gt;fishbowl:~/family/veronika/photos [here]
296d71bb-1aef-4381-b15a-8c9f13836254 -- madduck&lt; at &gt;albatross:~/family/veronika/photos
ecedc885-2ecd-4f3a-8bae-ae2c27ae1f37 -- madduck&lt; at &gt;julia:/srv/git/priv/family/veronika/photos.git [origin]
and obviously the other host (albatross) has [here] in its line.
I would really like to be able to tell git-annex that fishbowl and
albatross can indeed talk to each other. As a consequence, git-annex
would automatically set up a relationship between them (using
remotes).
Have you thought of this?
</pre>martin f krafft2014-09-09T13:24:12Using subtree with vcsh and mr?http://comments.gmane.org/gmane.comp.version-control.home-dir/845
<pre>Hi, I've been happily using vcsh and mr for a while, to manage my emacs,
zsh, git &amp; bzr configs.
I've hit a problem with integrating third-party code that works with e.g.
emacs or zsh.
I suspect I'm missing a straightforward way to solve this, but in searching
through the vcsh issues on github, it seems like it wasn't solved (or no
one updated the issue, #27 [1]).
For example, useful stuff like zsh-git-prompt [2] just has a top-level repo
with files in it, so if I directly add it as a main repo in vcsh, I'll just
get those files dumped into $HOME. For that one, I 'solved' it by forking
and creating the directory structure I wanted [3]. However, that's going to
be a pain for anything that's more actively developed.
For example, emacs-helm [4] is really useful, and it's actively developed,
but look at all those files in the top level just flooding $HOME.
Any tips?
Thanks,
-mike
[1]: https://github.com/RichiH/vcsh/issues/27
[2]: https://github.com/olivierverdier/zsh-git-prompt
[3]: https://github.com/mikemccracken/zsh-git-prompt
[4]: https://github.com/emacs-helm/helm
</pre>Michael McCracken2014-08-08T14:34:09git-annex - documentation clarification - I've had data losshttp://comments.gmane.org/gmane.comp.version-control.home-dir/816
<pre>Not sure you'd call this a docs bug; more like 90% my fault.
Just posting in case it might help someone avoid the same mistake.
I used git annex on an external usb disk of mine. When I read the
docs, I took the following:
"When you add a file to the annex and commit it, only a symlink to the
annexed content is committed"
(http://git-annex.branchable.com/walkthrough/#index3h2)
to mean that the file are are left intact, in-situ and what was stored
is just metadata about the file.
(yep, I didn't even read the end of the sentence apparently; this was
a while ago)
Anyway, time passes, and I decide to move all this content over to a
different disk.
I just used drag and drop from a gui (not sure whether windows or
linux) and of course the select doesn't pick up the .git directory.
Next I reformated the disk, and get a funny feeling that the copy went
a little too fast ...
Can I suggest that the following wording be changed from this:
"When you add a file to the annex and commit it, only a symlink to the
annexed content is committed. The content itself is stored in
git-annex's backend."
to this:
When you add a file to the annex, the content is moved to git-annex's
backend (.git/annex/..) and replaced with a symlink. The commit only
commits the symlink.
The http://git-annex.branchable.com/how_it_works/ page might be
improved the same way.
It currently says
"The contents of large files are not stored in git, only the names of
the files and some other metadata remain there."
which is strictly true but might lead others to make the same mistaken
assumption that I did.
Regards,
Matt
</pre>Matthew Hannigan2014-02-10T12:50:45mr and git topic brancheshttp://comments.gmane.org/gmane.comp.version-control.home-dir/814
<pre>Hi,
I like the idea behind "mr" a lot. For example, it was really easy to
checkout the public part of joey's homedir on my machine. I would like
to adopt something like you use to improve upon my current "unison"
setup.
I wonder how the users of "mr" deal with short-lived topic branches.
Ideally, it should be possible to create a new topic branch on one
machine, and then continue to work on it on some other machine.
(Without editing .mrconfig in-between)
Also, I wonder whether there is some way to use mr to sync one's
homedirs (that contain git repositories with software projects) with
occasional rebases. Sometimes I would like to squash all the commits of
a topic branch together. Does anyone know a way to do this that works
well with mr?
Cheers,
Christoph
</pre>Christoph Groth2013-11-27T21:10:34How to start syncing two existing directories with git annex?http://comments.gmane.org/gmane.comp.version-control.home-dir/804
<pre>Hey, I have a ~/Music directory on computer A, and a ~/Music directory
on computer B. They contain mostly the same files (and with the same
paths). But there might be some files on A but not B, or vice-versa. And
there might be some files on both but different (e.g. different id3 tags).
I want to use git annex assistant to sync the two dirs. Neither computer
is big enough to hold two copies of the Music dir at once. Ideally, I'd
prefer not to have to delete the Music dir from computer B, for example,
and then let git annex sync it from A over to B again.
I've setup git annex assistant on both machines and have them syncing
their ~/Annex dirs over the local network.
Now how can I start syncing the two music dirs? What will happen if I,
for example, drag ~/Music into ~/Annex on computer A then, without
waiting, do the same on B?
I could use unison to make sure that the two ~/Music dirs are exactly
the same, and resolve any differences, before moving anything into
~/Annex. Maybe that would be a good idea?
Thanks
</pre>Sean Hammond2013-11-24T20:03:37.gitignore with `/*` to check $HOME into Githttp://comments.gmane.org/gmane.comp.version-control.home-dir/799
<pre>Howdy!
First post. I found this group through this post on the Unix &amp; Linux Stack
Exchange:
http://unix.stackexchange.com/questions/46538/are-there-pitfalls-to-putting-home-in-git-instead-of-symlinking-dotfiles/46835#46835
I'm experimenting with checking my $HOME directory into Git for the first
time. Yesterday I read about various ways of doing this and experimented
with vcsh, which is a really cool script.
Today I'm trying out a very simple method. It just uses one Git repo
located in $HOME with a .gitignore file that has contents like the
following:
# Ignore everything by default
/*
# "Unignore" this .gitignore file
!/.gitignore
# Add here everything else you want to unignore
!/.vimrc
This seems like a simple way to override Git's greediness while avoiding
the problems that can arise with nested git repos (just don't unignore them
and they won't cause problems).
Can anyone here more experienced with versioning $HOME advise on problems
that might arise with this approach?
Thanks,
Evan
</pre>Evan R. Murphy2013-10-17T22:17:23Search EngineSearch the mailing list at Gmanequeryhttp://search.gmane.org/?group=$group=gmane.comp.version-control.home-dir