Re: Git
[please format your mail to 68 chars per line] also sprach chombee <[EMAIL PROTECTED]> [2007.11.26.0233 +0100]: > I'm not versioning everything in my homedir, I leave out music, > photos, videos and the like, why? Git's storage format should actually be able to deal with those quite well, better than the diff/snapshot/weave-based VCS at least. > Then you place any files you want to version into the git folder, > and anything left outside of this folder is not versioned and > won't be touched by git. This is not a bad idea; however, In my experience it gets messy quickly, with all symlinks and detecting changes. I could fathom a manager script though, which symlinks all the files to appropriate places and keeps track of which it installed, so that it can remove those which are no longer present. Doing this as part of a merge hook would be best. I am experimenting with detached worktrees, but I cannot yet say that these are the solution. The idea is that I have ~/.fgits/mutt.git holding the http://git.madduck.net/v/etc/mutt.git repository, and core.worktree set to ../../, so that checkouts etc. actually operate on ~/.fgits/mutt.git/../.. == ~. It works fine until I need to commit a change, because that requires me to use $GIT_DIR currently. also sprach chombee <[EMAIL PROTECTED]> [2007.11.26.2200 +0100]: > So Joey finds that git works well for mboxes, and Venklatesh finds > it works well for maildirs. Okay. I have maildirs. I'll give it > a try. I don't see the benefit of using Git for mail. Why not offlineimap? One idea I have recently had, which is more about /etc than ~, but might apply too: Imagine a bare repo in /srv/gits/postfix.git with a post-receive hook to call 'make -C /etc/postfix'. /etc/postfix itself is just a checkout of this repo. Now when I make a change, I can either clone the repo again, e.g. to /home/admin/postfix and push. This causes make to be invoked and I can use /etc/postfix/Makefile to fix up all permissions and run postfix reload. This is a bit of extra work, but I think it's more robust and better than a general solution, like etckeeper (which arguably has a different use case). -- martin | http://madduck.net/ | http://two.sentenc.es/ a qui sait comprendre, peu de mots suffisent. -- intelligenti pauca spamtraps: [EMAIL PROTECTED] digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
git for mail (was: Git)
also sprach chombee <[EMAIL PROTECTED]> [2007.11.27.1416 +0100]: > I'm not sure if I will bother to use git or not. Depends how > much hassle it is. Synchronisers like offlineimap make me > queasy though. It is fairly easy to destroy all your email. I've been using offlineimap since it came out and have never lost mail. > Say something goes wrong on a client, and your email gets > deleted or moved or something on that client. I guess if you cannot rule out that "something goes wrong on a client" you should switch clients or offlineimap isn't for you... -- martin | http://madduck.net/ | http://two.sentenc.es/ "i worked myself up from nothing to a state of extreme poverty." -- groucho marx spamtraps: [EMAIL PROTECTED] digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: Git
also sprach Venkatesh Srinivas <[EMAIL PROTECTED]> [2007.11.27.1520 +0100]: > For files like music or photos or moves, which tend not to be > changed, what does using a VCS gain for you? Distributed backups, consistency. > Also, how does git deal with large (movie-sized) files? Fine. > shuffled out of the inbox. Offlineimap was very slow to sync > moves between the inbox and saved-messages - it had fallen into a > mode where a complete sync would have taken ~45/50 days. Perhaps it > was a problem with my server setup? Perhaps an artifact to trying to sync > from a Maildir with 28k messages? No idea. I had massive problems too. In the end, it was dovecot's problem: a combination of http://www.dovecot.org/list/dovecot/2007-August/024840.html http://www.dovecot.org/list/dovecot/2007-August/024842.html. Now that I delete the index cache daily, I can sync a 100'000 message Maildir in a little less than 2 minutes. > Also offlineimap doesn't like when a server doesn't report the > full contents of a mail folder - this can happen when a server > runs out of memory, for example. In my case, it interpreted the > mails that the server didn't load as ones that it needed to delete > and proceeded to delete those messages locally. Never had that happen. -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED] this message represents the official view of the voices in my head. spamtraps: [EMAIL PROTECTED] digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
git for mail (was: Git)
also sprach Venkatesh Srinivas <[EMAIL PROTECTED]> [2007.11.27.1520 +0100]: > The mail model I use is that I have an inbox, which is kept as small > as possible, and a 'saved-messages', which is all my archives and mail > shuffled out of the inbox. I've thought about this for a bit and I could imagine some cool uses of Git for mail, such as attaching procmail logs to commits and the like, so that they'd always be tied to the message. However, unless one has such a simple mail flow as you, I would not trust Git with mail, simply because it does not observe the Maildir algorithm and doesn't bother to lock mailboxes. If I move a message to a folder and push the change, let the server pull it and that happens right around the time when procmail delivers a message to the folder, the two could collide because Git does not observe the Maildir approach. -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED] no micro$oft components were used in the creation or posting of this email. therefore, it is 100% virus free and does not use html by default (yuck!). spamtraps: [EMAIL PROTECTED] digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
non-fast-forwarding git merges (was: Git)
also sprach chombee <[EMAIL PROTECTED]> [2007.12.03.1404 +0100]: > Is there some way to get git-pull to abort if it's not going to do > a fast-forward? I think it just does a merge automatically. That's > the problem, cause you might not be expecting it. It'd be good if > it could warn you if a non-fast-forward merge was gonna happen. I suggest not using git-pull. Instead, use git-fetch and git-merge, then you are far closer to what's happening to your clone. git-pull doesn't do anything else anyway. Anyway, if a merge results in a non-ff, just point your HEAD to the previous commit: git reset --hard HEAD^ Now you have the commits from the remote in a separate branch and you can instead rebase or do the merge again. -- martin | http://madduck.net/ | http://two.sentenc.es/ "the condition of perfection is idleness. the aim of perfection is youth." -- oscar wilde spamtraps: [EMAIL PROTECTED] digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
git submodules in ~ (was: Introductory git article?)
also sprach Jens Peter Secher <[EMAIL PROTECTED]> [2008.02.17.1252 +0100]: > I tried various systems, but ended up only moving (and linking) > private dotfiles like .ssh/ and .gnupg/ in a git submodule. That > way I can check out my homedir without the private stuff on an > insecure machine, as others have described. The way submodules work is that the parent has a reference to a specific revision of a submodule. So if you have two machines and each have a submodule in ~/foo at commit A and you add some commits to the first ~/foo submodule and push them, you cannot just tell your ~ on the other machine to update; instead, you have to pull ~/foo and then commit ~ to tell it about the updated submodule. I personally prefer the mr tool to submodules for this task. -- martin | http://madduck.net/ | http://two.sentenc.es/ "never attribute to malice what can be adequately explained by incompetence." -- mark twain spamtraps: [EMAIL PROTECTED] digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: git submodules in ~ (was: Introductory git article?)
also sprach Casey Link <[EMAIL PROTECTED]> [2008.02.20.2352 +0100]: > Do you use the mr tool instead of git submodules? Yes. See http://colabti.org/irclogger/irclogger_log/git?date=2007-09-06,Thu&sel=578#l979 -- martin | http://madduck.net/ | http://two.sentenc.es/ "welcome to american airlines, sir. here's your avocado - remember to keep it turned on and with you at all times. please turn your luggage over to the armadillos for rootling." -- http://azure.humbug.org.au/~aj/armadillos.txt spamtraps: [EMAIL PROTECTED] digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: git submodules in ~ (was: Introductory git article?)
also sprach Manish <[EMAIL PROTECTED]> [2008.02.21.0811 +0100]: > > I personally prefer the mr tool to submodules for this task. > > Can you please share your .mrconfig? No, it contains sensitive information, like client names and the like. What are you looking for anyway? -- martin | http://madduck.net/ | http://two.sentenc.es/ "by accepting this brick through your window, you accept it as is and agree to my disclaimer of all warranties, express or implied, as well as disclaimers of all liability, direct, indirect, consequential or incidental, that may arise from the installation of this brick into your building." -- seen on irc spamtraps: [EMAIL PROTECTED] digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: git submodules in ~ (was: Introductory git article?)
also sprach Manish <[EMAIL PROTECTED]> [2008.02.21.1122 +0100]: > I wanted to know how you were using mr to manage submodules but like > you said you are not. Guess I just need a clean layout. Define "submodule"? I am using mr to manage my ~. Please read http://colabti.org/irclogger/irclogger_log/git?date=2007-09-06,Thu&sel=578#l979 and note that I have since replaced colgit with mr. -- martin | http://madduck.net/ | http://two.sentenc.es/ "no woman should ever be quite accurate about her age. it looks so calculating." -- oscar wilde spamtraps: [EMAIL PROTECTED] digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
git-home-history
FYI, I just found http://jean-francois.richard.name/ghh/git-home-history.html I'll invite Jean-Francois to the list. -- martin | http://madduck.net/ | http://two.sentenc.es/ "in a country where the sole employer is the state, opposition means death by slow starvation. the old principle: who does not work shall not eat, has been replaced by a new one: who does not obey shall not eat." -- leon trotsky, 1937 spamtraps: [EMAIL PROTECTED] digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: git-find-repeo
The problem Max is trying to solve started with this post: http://marc.info/?l=git&m=118407895625277&w=2 and was identified here: http://marc.info/?l=git&m=118422647932244&w=2 I have some minor comments on the code: > for repo in .fgits/*; do probably want to make this configurable... > if GIT_DIR=$repo git ls-files $file | fgrep $file >/dev/null; then fgrep -q :) The only concern I have is scalability. Iterating all repos and running ls-files on them is quite bad. However, I can't think of a better way. Can you? -- martin | http://madduck.net/ | http://two.sentenc.es/ above all, we should not wish to divest our existence of its rich ambiguity. --friedrich nietzsche spamtraps: [EMAIL PROTECTED] digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: Fwd: SVN vs. Mercurial vs. Git For Managing Your Home Directory
also sprach Aristotle Pagaltzis <[EMAIL PROTECTED]> [2008.04.26.1718 +0200]: > might be of interest to this list: > http://joshcarter.com/productivity/svn_hg_git_for_home_directory Added to http://vcs-home.madduck.net. -- martin | http://madduck.net/ | http://two.sentenc.es/ the only secure micro$oft software is what's still shrink-wrapped in the warehouse. spamtraps: [EMAIL PROTECTED] digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: Bazaar
also sprach chombee <[EMAIL PROTECTED]> [2008.05.16.1225 +0100]: > It seems like it would be pretty good, perhaps better than git, I find it very slow, but otherwise it's probably pretty much equivalent to git and hg. Git is amazingly fast. That's most of the reason why I use it, especially for large repositories like $HOME. > Bazaar's own website, but: > > http://bazaar-vcs.org/BzrVsGit I find most of these claims to be wrong. But hey, to each their own. Try Bazaar and let us know how it works for you! A couple of quick comments to your most important points: > * A remote repo can be just a directory accessible via SSH or FTP, > you don't need a bzr instance on the remote server. You don't need git on the remote server either. > * bzr recognises files and directories, you can commit an empty > file or directory, commit a rename of a file or directory. You can commit empty files to git and renames are handled IMHO better than in Bazaar. It's true about the empty directories, but where's the problem? I usually just check in an empty .gitignore file if I need to create a directory that's otherwise empty. > * More direct support for the centralised server workflow. You can > commit directly to a centralised server instead of committing and > then pushing. Not sure how much I'd want that. You can also do > local commits. You can do that with git hooks as well. > * "supports SVN-style checkout, whereas in Git you may have to > download whole — possibly big — repository", I think this means > you can checkout just a given file or directory from a repo. True, this and subtree checkouts are not supported well with Git, but you can do shallow clones. > * I think it might track file permissions: "Security can be > applied to different branches by using existing operating system > access control facilities." This is not true. It tracks the same bits as git. > * Don't need to periodically pack repositories yourself. Git does this automatically as well. > * It has a Python plugin API, might be useful True. > They also claim it's up to par with git on speed, storage space They "claim" :) In my tests, it's absolutely not true. > and cryptographic content validation. Both of them do that alright. -- martin | http://madduck.net/ | http://two.sentenc.es/ "if one cannot enjoy reading a book over and over again, there is no use in reading it at all." -- oscar wilde spamtraps: [EMAIL PROTECTED] digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: Bazaar
also sprach [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2008.05.17.2057 +0100]: > Does it? I mostly use a git-gc cronjob. See man git-gc's --auto option. To be honest, I *prefer* using a cronjob for this and thus have gc.auto and gc.autopacklimit set to 0. The reason is simply that I am so used to git's speed that I'd hate to have to wait for a random operation to complete because it repacks the repo. Instead, let cron do it at 4am. But that's just me... -- martin | http://madduck.net/ | http://two.sentenc.es/ this product is under strict quality contril with perfect packing and quality when leving the factory.please keep away from damp.high temperature or sun expose.If found any detectives when purchasing. please return the productby airmail to our administration section and inform the time, place.and store of this purchase for our improvement.We shall give you a satisfactory reply.Thanks for your patronage and welcome your comments. -- http://www.engrish.com spamtraps: [EMAIL PROTECTED] digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: diff-ing and uniq-ing directory trees
also sprach Rustom Mody <[EMAIL PROTECTED]> [2008.04.20.0356 +0100]: > Do you know whether this is possible? I only just saw this now in my overfull mailbox. :) How about one of the tools that find duplicates, like perforate, fdupes, etc? Git does internal stuff to prevent duplication, but I think you'd be going on a stretch to use that for your purposes. -- martin | http://madduck.net/ | http://two.sentenc.es/ "sometimes we sit and read other people's interpretations of our lyrics and think, 'hey, that's pretty good.' if we liked it, we would keep our mouths shut and just accept the credit as if it was what we meant all along." -- john lennon spamtraps: [EMAIL PROTECTED] digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: semi-OT: favicon/site icon for the wiki
also sprach Aristotle Pagaltzis <[EMAIL PROTECTED]> [2008.05.29.1245 +0200]: > No it’s not… rhis would probably be the list configuration. I asked her to send the file to me directly. -- martin | http://madduck.net/ | http://two.sentenc.es/ "we all know linux is great... it does infinite loops in 5 seconds." -- linus torvalds spamtraps: [EMAIL PROTECTED] digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: mrsetup and the rest of the toys
also sprach Yaroslav Halchenko <[EMAIL PROTECTED]> [2008.07.17.2000 +0200]:
> I have ran into your git repository while looking for a nice zsh
> config to start with. So I got interested in the way you setup
> management of the account configuration and projects within mr.
> I kept thinking to move my home CVS (at least parts) under similar
> setup, but I am lacking the rationale behind few decisions you've
> made. If you get a chance, could you either reply to me or
> describe your setup and typical workflow in your blog?
I've been meaning to do this as soon as I am comfortable with my
setup. It's okay up to now, but there are still some rough edges.
> now specific questions:
For the others, this is the repo of mrsetup, which I use to
bootstrap my accounts:
http://git.madduck.net/v/etc/mrsetup.git
> 1. why did you decide to go with .fgits and git_fake_bare_checkout. How
> do you adjust and propagate your changes in lets say .ssh/config back
> into the repository and the rest of the nodes? how could those changes
> become MY_ACCOUNT specific
>
> alternative seems to have .ssh/.git (instead of ssh.git/.{ssh,git}), ie
> explicit clone of ssh.git under home dir, and to allow MY_ACCOUNT
> specific branch within .ssh/ git repository (which gets pushed back to
> repository). That allows easy modification of .ssh/* and immediate
> 'reflection' of the change, and later on push into repository (including
> cherry picking into master branch which supposed to be common to all
> the ACCOUNTs)
I used to do the subdirectory approach you describe and symlinked
files into ~ where needed, but that just turned out really ugly and
I had some problems with it.
I always wanted to just have files in ~ and be under version
control, so I briefly considered merging all the config repos into
a single account-specific branch which is checked out into ~, but
then that got to the point where I lost track.
So instead I started to experiment with detached worktrees: the git
repo is in ~/.fgits/ssh and it has core.worktree=../../ so that ~ is
its worktree (don't ask me where the name ~/.fgits came from). By
itself this works, but it's cumbersome to manage.
Therefore I use two tools to my rescue: mr and vcsh.
mr is Joey Hess' multiple repository tool and I configure it like
this: http://git.madduck.net/v/etc/mr.git?a=tree;f=.mr;hb=HEAD. On
each machine I symlink those collections in ./roles to ~/.mr (which
is what you see at the link). ~/.mrconfig then simply includes them
and mr manages all my repos, including those under ~/.fgits
This works well and to pull in changes, I simply run `mr -i up` when
I need to sync an account. Right now, it all insists on ssh://, but
I want to integrate dynamic support for git:// instead for accounts
to which I don't forward my SSH agent socket.
The problem was for a long time how to commit changes, and to deal
with that, I wrote vcsh, which drops me into a subshell in which
GIT_DIR and GIT_WORK_TREE are setup up properly:
http://git.madduck.net/v/etc/zsh.git?a=blob;f=.zsh/func/vcsh;hb=HEAD
So after I made a change to, say ~/.zsh/zshrc, I would then do
vcsh zsh
and get a prompt like this:
{vcsh:zsh}+piper:~/.fgits/zsh.git|master|~%
there I then add, commit, and push as needed. I am starting to like
this approach more and more because it enforces the modularity. In
fact, if I am about to make a change to the zsh config, I do so in
the vcsh zsh subshell... YMMV, of course.
SSH is an interesting case because I wanted to keep run-parts-style
modularity, but SSH only reads single files for authorized_keys and
known_hosts. Thus, I coded up a Makefile to compile those:
http://git.madduck.net/v/etc/ssh.git?a=blob;f=.ssh/Makefile;hb=HEAD
and told mr to invoke it. Sometimes this has caused me to scratch my
head, at other times it was really nice to be able to edit the
configuration file or known_hosts, knowing that the changes are
temporary and the file would be restored. I use aliases in [0] (note
how ssh drops stuff into ~/.zsh and thus registers completion and
aliases) to help me manage known_hosts.
0.
http://git.madduck.net/v/etc/ssh.git?a=blob;f=.zsh/zshrc/parts.d/50_ssh;hb=HEAD
crontabs [1] are another case where I use a Makefile, and where
I expect other tools (such as mutt [2]) to drop files into
~/.crontab.d. This is all still work in progress still...
1.
http://git.madduck.net/v/etc/ssh.git?a=blob;f=.zsh/zshrc/parts.d/50_ssh;hb=HEAD
2. http://git.madduck.net/v/etc/mutt.git?a=blob;f=.crontab.d/mutt;hb=HEAD
I also handle the configuration file with the Makefile simply
because some accounts on older machines wouldn't have support for
all the options; those are now commented out on compilation.
This brings me to account-specific branches: I opted against them
and instead made my configuration global so that it applies
everywhere. This is much more straight forward than remembering to
cherry-pick local changes into the central config and then not to
forget to merge t
Re: git for versioning
also sprach Rustom Mody <[EMAIL PROTECTED]> [2008.07.30.0851 +0200]: > But how do I work on the base and have it push (yeah, that's not > exactly the word) its changes through the (branches for) Albert, Beth > and Foo? You push them to a central location and they fetch&merge from there, or they fetch from your repo and merge. > I tried to study rebase for this but I guess its not the thing I want. You could have them rebase too, but I suggest you don't until you are comfortable with Git. -- martin | http://madduck.net/ | http://two.sentenc.es/ if you find a spelling mistake in the above, you get to keep it. spamtraps: [EMAIL PROTECTED] digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: git for versioning
also sprach Rustom Mody <[EMAIL PROTECTED]> [2008.07.30.1113 +0200]: > >> But how do I work on the base and have it push (yeah, that's not > >> exactly the word) its changes through the (branches for) Albert, Beth > >> and Foo? > > > > You push them to a central location and they fetch&merge from there, > > or they fetch from your repo and merge. > > merge I can understand. > But why push and fetch? Its all on the local machine. you need to pull revisions from the other repos. I strongly suggest you read http://git.or.cz/course/svn.html http://utsl.gen.nz/talks/git-svn/intro.html (even though git-svn, this is still good for learning git) -- martin | http://madduck.net/ | http://two.sentenc.es/ kermit: why are there so many songs about rainbows? fozzy: that's part of what rainbows do. spamtraps: [EMAIL PROTECTED] digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: git for versioning
also sprach Rustom Mody <[EMAIL PROTECTED]> [2008.07.30.1322 +0200]: > If I want to work on changes in the common part, I check out (a tag > for) the point before the branch (as a detached head??) > Work on that and then what?? Thats my question. Don't you have a common branch, like master? You can't work with detached heads, so you'd need to make a new branch there. Once you made changes to such a branch, then you either merge this branch into the branches for Beth and Albert and so on, in turn, or you rebase each of these branches onto the tip of the branch you worked on. so if A,B,C are branes off master and you work a bit on master, then either: for i in A B C: do git checkout $i git merge master done or for i in A B C; do git rebase master $i done I suggest you make a copy of the repo and try this stuff out to see what the difference is. gitk is really useful to visualise the graph. -- martin | http://madduck.net/ | http://two.sentenc.es/ what do you mean, it's not packaged in debian? spamtraps: [EMAIL PROTECTED] digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: git for versioning
also sprach Manish <[EMAIL PROTECTED]> [2008.07.30.1520 +0200]: > I am also new to git so just to confirm. Merge will leave us with one > less branch whereas a rebase will move our changes on top of the > changes of other branch. Right? No, you'll have two branches in both cases. The distinction is between linear (rebase), meaning that one branch builds off the tip of another, and recursive (merge), meaning that the branches run in parallel and later join up. I really suggest to play around with this, the manpages, and gitk! > Also if a document is modified in master and also modified in > branch A, then when we rebase A on top of master what will be the > state of contents of A? Same as master or same as A or will > a merge be performed? A merge will be performed, or conflict resolution required. Just like if you merged them. Rebasing is essentially taking each commit and cherry-picking/applying it on top of the destination tip; if a commit cleanly applies, move on; if not, try merge; if that fails, ask the user to resolve the conflict. -- martin | http://madduck.net/ | http://two.sentenc.es/ "no survivors? then where do the stories come from I wonder?" -- captain jack sparrow spamtraps: [EMAIL PROTECTED] digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: I am using fsvs and just found svnhome in google...
also sprach Plamen Marinov <[EMAIL PROTECTED]> [2008.08.22.1404 +0100]: > And I am not giving any advice - fsvs is better or not. I am just > asking, if you know about fsvs, what do you think about it. If you are fine with the slow speed and all the other limitations of Subversion, give it a shot. I haven't, and I wouldn't touch it because I don't trust Subversion. Also, since Subversion can't actually operate in offline mode, you either need to be connected to use the filesystem, or you only get a local repository that you cannot sync with another machine, which kinda defeats the whole point for me. -- martin | http://madduck.net/ | http://two.sentenc.es/ tempt not a desperate man. -- william shakespeare spamtraps: [EMAIL PROTECTED] digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: I am using fsvs and just found svnhome in google...
also sprach Juliano F. Ravasi <[EMAIL PROTECTED]> [2008.08.26.2207 +0100]: > > If you are fine with the slow speed and all the other limitations > > of Subversion, give it a shot. I haven't, and I wouldn't touch it > > because I don't trust Subversion. > > Gratuitous Subversion bashing? Not intended, no. > May I ask why you don't "trust" Subversion? It has corrupted my repositories often. I was using Subversion for about 3 or 4 years. > What? Are you sure you meant that? You can't use the filesystem if > you are not connected? So you have a centralised repository. What do you do when you are on an airplane? How do you write to the filesystem? > distribution is needed). In fact, I already knew that git and hg > would fail for the task, since I already knew them very well for > SCM before starting my vcs-home experiments. I use Git for homedir versioning. How does it fail for you? > code projects (only files and not directories are important, no > need to support unicode filenames, most files are very small, > etc). That is Git supports unicode filenames and binary files as large as you want them. Anyway, as I said a couple of times in all different places: use the tool that suits you. You wanted feedback on fsvs and I told you what I thought of it. I am also interested in what your experiences are or will be! -- martin | http://madduck.net/ | http://two.sentenc.es/ http://lavender.cime.net/~ricky/badgers.txt spamtraps: [EMAIL PROTECTED] digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Subversion corruption (was: I am using fsvs and just found svnhome in google...)
also sprach Juliano F. Ravasi <[EMAIL PROTECTED]> [2008.08.27.0302 +0100]: > Ok, this is a personal experience. I don't know what may have > happened to your repositories, but I would be interested, since > I work with this. I do not recall the details, but I've had numerous occasions where I'd have to dump and restore the repository with svnadmin because some obscure errors prevented me from using the repository. I have never had a problem with Git or mercurial. -- martin | http://madduck.net/ | http://two.sentenc.es/ "i am not in favour of long engagements. they give people the opportunity of finding out each other's character before marriage, which i think is never advisable." -- oscar wilde spamtraps: [EMAIL PROTECTED] digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
(valid) criticisms of Git addressed (was: I am using fsvs and just found svnhome in google...)
also sprach Juliano F. Ravasi <[EMAIL PROTECTED]> [2008.08.27.0302 +0100]:
> 1. Both don't see directories. Just because a directory is empty
> doesn't mean that it doesn't exist. If I delete all files in
> a directory, it doesn't mean that that directory ceased to exist.
> Some programs don't expect this. For example, file all messages
> from your Inbox, and commit. Then you pull from the other machine,
> and your Inbox directory just disappears.
If you emptied your inbox, why keep it around? I expect the tools
I use to recreate empty directories aqs needed.
This is apart from the fact that I prefer to use IMAP for
synchronising mail, since it's a better tool (made) for the task and
can do stuff (like flags) better than a mail-agnostic tool, such as
a content tracker.
> 2. Both lack proper ways to store metadata. This is evidenced by
> the need to pollute your directories with .gitignore,
> .gitattributes and .gitmodules (for Git), and .hgignore,
> .hgbranches and .hgtags (for Mercurial). All this information is
> threated and versioned as part of the contents of the repository,
> while it should not. It is the plumbing of the VCS that gets
> exposed and mixed with the user files.
This is a very valid point and I wish Git had a metadata layer. I've
tried to bring up the issue with the developers, but they're not
interested in making Git more generic ("it's used to track the linux
kernel sources, if you use it for anything else, you are on your
own").
But keep in min that Git, Mercurial & Co. are first-generation (if
you are willing to place arch into the zeroth generation, and see
Monotone in a league of its own). We are surely going to see new
tools which pick up on these issues in the future.
There is one thing to be said in favour of in-filesystem metadata,
such as .gitattributes — conflicts in those are no different than
conflicts in content files, and all of the standard and advanced
conflict resolution mechanisms (merge drivers, git-rerere, etc.) can
be used for those just as well. Surely, this could be remedied by
exposing the metadata layer as files in the event of conflicts, but
that would be a hack in my world, and likely come with other
problems.
> In the case of Git, .gitattributes is a huge misfeature. The
> attributes stored in it are user-edited, and is not attached to
> the actual files. If you move files around, you suddenly lose your
> attributes until you fix the attributes file.
Agreed.
> 4. Git only: lack of real rename/copy support. This affects not
> only vcs-home, but also general SCM use; it is just worse for
> vcs-home. There is a much bigger likelihood of having binary files
> in your home than common source code projects (what Git was
> designed to manage). Images, text documents, spreadsheets,
> presentations, compressed files, etc... For example, you change
> a single character in an ODF document and save. You will see that
> the file is completely different binary-wise, not easy to track.
Git doesn't track the file, it tracks the content. If you make small
changes, it's likely that the two blobs will be compressed to little
more than the size of one in the store. When it comes to keeping the
association (e.g. log messages), Git uses commit history anyway to
figure this out.
> If you also rename before the commit, you just lose the
> connection, and there is nothing you can do about it.
This has not happened to me before, or well, it's not bitten me.
Do you mean something like:
+lapse:~/.tmp/cdt.VLULwrjW|master|% echo foo > testfile
fatal: No HEAD commit to compare with (yet)
+lapse:~/.tmp/cdt.VLULwrjW|master|% git add testfile
gfatal: No HEAD commit to compare with (yet)
+lapse:~/.tmp/cdt.VLULwrjW|master|% git commit -m'add testfile(foo)'
Created initial commit 3ff1892: add testfile(foo)
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 testfile
+lapse:~/.tmp/cdt.VLULwrjW|master|% echo bar >| testfile
changes on filesystem:
testfile |2 +-
+lapse:~/.tmp/cdt.VLULwrjW|master|% git mv testfile someotherfile
cached/staged changes:
someotherfile |1 +
testfile |1 -
+lapse:~/.tmp/cdt.VLULwrjW|master|% git commit -m'moved the file to
someotherfile(bar)'
Created commit 78b242f: moved the file to someotherfile(bar)
2 files changed, 1 insertions(+), 1 deletions(-)
create mode 100644 someotherfile
delete mode 100644 testfile
+lapse:~/.tmp/cdt.VLULwrjW|master|% git log -- someotherfile
commit 78b242f2d5df1ebe96e25e2dc6c69eb1c135cbb2
Author: martin f. krafft <[EMAIL PROTECTED]>
Date: Wed Aug 27 13:55:37 2008 +0100
moved the file to someotherfile(bar)
> 5. Git doesn't actually support Unicode filenames (neither does
> Mercurial). Both just store whatever the file name is in the
> filesystem directly into the reposit
Re: I am using fsvs and just found svnhome in google...
also sprach Juliano F. Ravasi <[EMAIL PROTECTED]> [2008.08.27.0302 +0100]: > So, you are calling the repository a filesystem, this led me to > misunderstand you. For me, a filesystem is contained in a hard disk > partition, mounted somewhere in my directory tree. No, I meant what I said: fsvs is presumably a fuse-filesystem and mounted under ~. It being a Subversion-backed filesystem, there has to be some repository behind it all. This can either be local, in which case you cannot really synchronise between two machines independently (unless you treat one machine as a central node), or you won't be able to use (commit to) the filesystem when offline. Am I misunderstanding fsvs? > You can work offline with Subversion, no problem here. It doesn't > inhibit you from doing your work, but you will have to refrain > from committing until you have your connection back. Your > statement in the other message made it seem like you are > completely hindered if you are offline. Well, if I am making changes to the filesystem, I want to have them committed. From what you suggest, it seems as if fsvs requires some external command to be run to actually make commits, in which case you'll end up with gigantic, unrelated commits after working on your files on e.g. a transglobal (= long) flight. [Git stuff left for a separate mail] -- martin | http://madduck.net/ | http://two.sentenc.es/ man muss noch chaos in sich haben um einen tanzenden stern zu gebähren. -- friedrich nietzsche spamtraps: [EMAIL PROTECTED] digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: Keeping your dotfiles in git
also sprach [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2008.08.26.2255 +0100]: > Google and you can find lots of people who keep their dotfiles in > a git repository. Usually they create a directory such as > ~/dotfiles/ and they move all the dotfiles they want to track into > that directory, and create the git repository in that directory. > Then they have a script of some kind (I've seen scripts in half > a dozen languages for this) that creates symlinks from the root of > their homedir into their dotfiles directory, e.g. linking > ~/.muttrc/ to ~/dotfiles/muttrc/. I found this too ugly and cumbersome and never liked the redundancy a script would introduce, or the mess of symlinks cluttering ~. Therefore I started to experiment with "detached worktrees" with Git. The concept is easy: ~/dotfiles/vim.git is what I call a fake-bare Git repository (meaning ~/dotfiles/vim.git/config holds the Git config, but core.bare is false), with core.worktree set to ../../. As a result, ~/.vimrc is actually a plain file versioned in the repository at ~/dotfiles/vim.git. This works reasonably well for me, but I have yet to figure out how to deal with .gitignore. Also, to commit or otherwise interact with the vim repository, I have to set $GIT_WORK_TREE and $GIT_REPO accordingly prior to any command using /usr/bin/git. At the moment, I am using a script called vcsh[0] for that, which spawns a subshell with these variables set (and the $PS1 modified to help me keep track), and I am actually liking it a lot, even though at first I tought this explicit "context-switching" would quickly get on my nerves. 0. http://git.madduck.net/v/etc/zsh.git?a=blob;f=.zsh/func/vcsh;hb=HEAD The approach has the advantage that my /bin/ls -l output is not polluted with a lot of symlinks, and that I can tell someone else to look at e.g. http://git.madduck.net/v/etc/zsh.git?a=tree and know immediately what goes where. No explanation, no script, no redundancy, little room for failure. Joey's mr script knows how to deal with "fake-bare" Git repositories, so "cd ~/dotfiles/vim.git && mr commit" will work as expected, as will "cd ~/dotfiles && mr update". As mentioned before, the problem is simply that in the context of ~/.git or ~/dotfiles/vim.git a file like ~/.mutt/muttrc is "unknown" and will show up in git-status output. One way to deal with that is to put stuff like /* !/.vimrc !/.vim into ~/dotfiles/vim.git/info/exclude, but unfortunately, that has to be done on every machine and cannot be synchronised. It would be possible to version ~/.gitignore.d/vim in ~/dotfiles/vim.git and set core.excludesfile in ~/dotfiles/vim.git/config, but that too is something that has to be done on all machine and won't be synchronised. There's also an issue with certain Git repositories requiring post-processing after cloning and merging (see http://git.madduck.net/v/etc/ssh.git?a=tree;f=.ssh;hb=HEAD for an example, which uses make to generate the configuration actually used by SSH). This can either be done with something like mr, but it's hackish, or with ~/dotfiles/ssh.git/hooks/update, but that isn't versioned or synchronised. Maybe someone has an idea how to deal with those issues? > I'm not entirely clear on why, in the examples I've seen, the -s > option is used to create symbolic links instead of just using hard > links. Many "editors" don't respect hardlinks and would unlink them, causing your files in ~ to become detached from the Git-versioned files. > What about the permissions of your dotfiles? Git does not track > file permissions, except for the executable bit, so people often > create scripts to somehow store and restore the permissions of all > the files. I have ~ at 711 and a umask of 077 and have been happy so far. -- martin | http://madduck.net/ | http://two.sentenc.es/ "nothing can cure the soul but the senses, just as nothing can cure the senses but the soul." -- oscar wilde spamtraps: [EMAIL PROTECTED] digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: I am using fsvs and just found svnhome in google...
also sprach Juliano F. Ravasi <[EMAIL PROTECTED]> [2008.08.27.1843 +0100]: > What? There is nothing there that even resembles a fuse > filesystem. Are we talking about the same thing? I mixed it up with something else then. Sorry for that. -- martin | http://madduck.net/ | http://two.sentenc.es/ "i feel sorry for people who don't drink. when they wake up in the morning, that's as good as they're going to feel all day." -- frank sinatra spamtraps: [EMAIL PROTECTED] digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: Subversion corruption
also sprach Juliano F. Ravasi <[EMAIL PROTECTED]> [2008.08.27.1859 +0100]: > It seems that what you got was some dangling lock or unfinished > transaction. Nothing that I would call a "corruption" (i.e. data loss). > Something that 'svnadmin rmlocks' or 'svnadmin rmtxns' would fix. Nope, it was more substantial. I spent days trying to rescue the repository before I found out that dumping/restoring miraculously worked still. And this didn't happen only once. -- martin | http://madduck.net/ | http://two.sentenc.es/ "moral zu predigen ist ebenso leicht als moral zu begründen schwer ist." - friedrich nietzsche spamtraps: [EMAIL PROTECTED] digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: (valid) criticisms of Git addressed
also sprach Juliano F. Ravasi <[EMAIL PROTECTED]> [2008.08.27.1958 +0100]: > > If you emptied your inbox, why keep it around? I expect the tools > > I use to recreate empty directories aqs needed. > > Yes, but some programs don't expect their directories to disappear. Then I think those programmes are buggy. Empty directories have no meaning, I think. > See? Just a single-pixel change of an image, together with > a rename from draft.png to final.png broke the history, because > Git doesn't record this information. Sure, it's ugly, but if you edit and rename in two separate commits, it works fine. So it is possible and should be fixed. In any case, I usually put renames into their own commits, so that's why I have not been bitten by this yet. -- martin | http://madduck.net/ | http://two.sentenc.es/ never trust an operating system for which you do not have the source. -- source unknown spamtraps: [EMAIL PROTECTED] digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: I am using fsvs and just found svnhome in google...
also sprach Juliano F. Ravasi <[EMAIL PROTECTED]> [2008.08.28.0153 +0100]: > This is starting to get way of topic... If anyone is bothered with this > discussion, just say so and I will continue off-list. You might want to change the thread subject, then I can adjust the archives. :) -- martin | http://madduck.net/ | http://two.sentenc.es/ minchinhampton (n.): the expression on a man's face when he has just zipped up his trousers without due care and attention. -- douglas adams, the meaning of liff spamtraps: [EMAIL PROTECTED] digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: OT: tips for directory structure for recurring LaTeX projects
also sprach Paul Menzel <[EMAIL PROTECTED]> [2008.09.04.1220 +0100]: > I do write letters and protocols using LaTeX with KOMA-Script > (texdoc scrguien). Now I want to start using a VCS. I use something similar to you, but I have all my letter-writing classes and files in $TEXMFHOME, where they are in VCS: http://git.madduck.net/v/etc/texmf.git and I use vimplate to create new letters. -- martin | http://madduck.net/ | http://two.sentenc.es/ a: no. q: should i include quotations after my reply? spamtraps: [EMAIL PROTECTED] digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: Migrating from svn to git
also sprach Chanoch (Ken) Bloom [2009.02.12.1727 +0100]: > 1. Some subdirectories have a quite long revision history. If, in the > future, I find myself checking out onto a low-bandwith computer, or > space-limited computer, or I just don't want the whole revision history > for some reason, I can use "git clone --depth" to get a history horizon > on the git repository. If you use --depth, you get an "inferior" repository, which won't allow you to use the Git feature set. So I'd say: no. On the other hand, if you use git-repack on the server, it probably squashes all of your history to the smallest possible size, so you probably won't take much of a hit. > The docs say that if I do this, then I can't push from (or pull > from) the shallow repository. However my tests indicate otherwise. > What's the real restriction? Do I just have to make sure both > branches involved in the push operation have history that goes > back to the point where they diverge, or is something else going > on here? It's something like that, yes, purely technical. This is to say that git does not prohibit you to do anything just because you made a shallow clone. If you can stay on top of things, then do it. You can always later get a full repo, after all. But if you want the gory details, I suggest you better ask the Git mailing list. > 2. A couple of my subdirectory repositories have subdirectories > that should themselves be omitted (or split off into directories > of their own). Is there some way to filter out these > subdirectories when doing the conversion or to filter them out > immediately afterward? With Git, you version full trees. If you want to discard a subtree, commit its removal, which will become part of the history. If you can't live with that, use git-filter-branch to rewrite the entire history. Since you cannot rewrite history, it seems like you should not, even though Git gives you the tools. Who knows, maybe later you find you do need a subdirectory back... -- martin | http://madduck.net/ | http://two.sentenc.es/ "never try to explain computers to a layman. it's easier to explain sex to a virgin." -- robert heinlein (note, however, that virgins tend to know a lot about computers.) spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: Best practice for Documents directory: looking for comments on my current setup
Collective reply, because this thread has been in my inbox too long... also sprach W. Kaplan [2009.04.19.1640 +0200]: > The problems I'm aware of are: > > a) Having the big ~/Documents repository is as wrong as a single big > $HOME repository, because it's still a lot of unrelated stuff in one > place. I'm actually not perfectly sure why this is so bad. It isn't, necessarily. It just means that you won't be able to pull it apart, e.g. only take stuff related to your thesis with you on the space-limited netbook, and still be able to use VCS as before. If you keep it all in one repo, it's all or nothing anywhere you go. > b) Since the ~/Documents/git-projects directory is being ignored > by the Documents repository I have to manually create it on the > other computer and manually pull the projects inside it. Right now > I only have to deal with 2 active projects, so I don't mind > managing this by hand, but what if I create more projects? Maybe > that will be the time to try the "mr" tool. Yeah, sounds like mr. > I read about but haven't actually tried the "mr" tool yet. I don't > think that I want to go down that road. As far as I understand it, > I could create repositories in different places anywhere in > Documents/ and would not have to remember them all, because "mr", > once configured, would take care of it. While this seems nice it > also seems inefficient to keep pulling repositories that will not > see any new commits ever though. With Git, you don't really notice it. Plus, mr can parallelise the pulls, so I'd say: just do it. > Looking at my current approach I feel like I'm using git for > several different purposes: simple synchronizing (of dotfiles), > synchronizing and archiving (of the Documents directory) and > actual project management. This makes me wonder if I'm trying too > hard to use one tool here. Maybe there are other tools to be > considered? I think Git is fit for all those purposes. also sprach Chanoch (Ken) Bloom [2009.04.19.2234 +0200]: > Keep in mind that if you have merge conflicts in your office > files, whether OpenOffice or MS Word, git and other version > control systems are much less likely to be able to do something > sensible about merging them. Less likely than what? I don't know any other tool that can sensibly merge those dinosaur formats. > I don't expect any other synchronization system can reconcile > these files any better though. When someone comes up with a good > way to reconcile these files, I hope we'll steal it and integrate > it into git. Yeah. Git does allow for custom merge drivers. > I use git for all of these things. There are a few places where I feel > subversion might be a better fit (a few particularly conflict-prone > configuration files are easier to blow away local changes without > creating the extra commits that git needs), but I'm going to make a go > of it with git. If it's just local, you can use git-reset or git-rebase -i to blow them away too... also sprach Rustom Mody [2009.04.20.0829 +0200]: > Thanks to this push, good-ol MS has moved (unwillingly?) from doc (for which > your comments above are correct) to docx that is similarly at core xml and > hence text. > > > I don't expect any other synchronization system can reconcile these > > files any better though. > > This true today. And merging XML is not identical to merging program > sources. But is much closer to it than arbitrary binry data True, in theory. If you think that we'll be able to merge two separately-edited OOo or MS Office files anytime soon, you are underestimating the storage format requirements of WYSIWIG editors, and underestimating Microsoft's furious attempts to adhere to the standard without actually implementing it. Apart, even if you could identity the conflicts atomically, how would you alert the user to them? also sprach Chanoch (Ken) Bloom [2009.04.20.1532 +0200]: > Though I've uncompressed .odt files myself to get at the XML inside, > I've never seen one of these in the wild that wasn't ZIP-compressed, so > as far as version control systems are concerned it's still binary data. This wouldn't matter for Git, since Git only stores contents, even for text files, and invokes merge drivers to combine two different versions. For text-only files, the merge driver is just the easiest you could conceive, which is why Git can do such an awesome job. It's still line-oriented, so far from perfect yet. > (I'm not even sure how the format would keep the four separate XML files > together if they weren't zip compressed, so maybe the Wikipedia article > is wrong or unclear.) AFAIUI, Zip is part of the format specification. also sprach Kelly Clowers [2009.04.21.0731 +0200]: > http://git.or.cz/gitwiki/GitTips > > In git 1.6.1 or later, try this in .gitconfig: > > [diff "odf"] > textconv=odt2txt > > (unoconv might also work) > > and in .gitattributes: > > *.ods diff=odf > *.odt diff=odf > *.odp diff=odf > > Note that I have yet t
dropbox (was: Best practice for Documents directory: looking for comments on) my current setup
also sprach Cory Myers [2009.05.13.1747 +0200]: > One of the neat things about Dropbox, actually, is that every > machine you link to your Dropbox account has a complete copy of > your data. Even if you unlink a computer, it keeps its copy. The > Dropbox folks would have to actively *delete* all the data in all > accounts for you to lose any of your local copies. Do they do anything other than remote storage and synchronisation based on modification times? How else do they or would they do it? What happens if you modify the same document in two places? How does it deal with conflicts? -- martin | http://madduck.net/ | http://two.sentenc.es/ "durch frauen werden die höhepunkte des lebens bereichert und die tiefpunkte vermehrt." - friedrich nietzsche spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: Getting Started with mrsetup issues...
also sprach Eric [2009.08.28.2032 +0200]: > I: cloning mr configuration... > ./mrsetup: line 79: code/mr/mr: No such file or directory Does this fix it? --- a/mrsetup +++ b/mrsetup @@ -15,7 +15,7 @@ MY_GIT_URL_BASE=ssh://$MY_GIT_SERVER MY_MR_REPO_URL=$MY_GIT_URL_BASE/$MY_GIT_REPOS/pub/etc/mr.git MY_ACCOUNT_REPO_URL=$MY_GIT_URL_BASE/$MY_ACCOUNT_GIT_REPO MR_REPO_URL=$MY_GIT_URL_BASE/~/git/pub/code/mr.git -MR_CODE=code/mr +MR_CODE=$HOME/code/mr MR_FGIT=.fgits/mr.git MR=.mr BIN_DIR=.bin changes on filesystem: mrsetup |2 +- -- martin | http://madduck.net/ | http://two.sentenc.es/ "a man's very highest moment is, i have no doubt at all, when he kneels in the dust, and beats his breast, and tells all the sins of his life." -- oscar wilde spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: Getting Started with mrsetup issues...
also sprach Eric [2009.08.28.2208 +0200]: > I: cloning mr into /home/eje001/code/mr... > Initialized empty Git repository in /home/eje001/code/mr/.git/ > remote: Counting objects: 1136, done. > remote: Compressing objects: 100% (507/507), done. > remote: Total 1136 (delta 617), reused 1136 (delta 617) > Receiving objects: 100% (1136/1136), 179.09 KiB, done. > Resolving deltas: 100% (617/617), done. > *fatal: git checkout: updating paths is incompatible with switching > branches. > Did you intend to checkout 'origin/vcsh' which can not be resolved as > commit?* I use a special branch or mr, called vcsh. You seen to replace all occurences of 'vcsh' with 'master' or whatever you want to use. Yes, the script could be refactored, but I am not that far (yet). -- martin | http://madduck.net/ | http://two.sentenc.es/ "'oh, that was easy,' says Man, and for an encore goes on to prove that black is white and gets himself killed on the next zebra crossing." -- douglas adams, "the hitchhiker's guide to the galaxy" spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: mrsetup and the rest of the toys
also sprach Mario Scholz [2009.11.24.2137 +0100]: > right now i'm trying to find a solution to sync my home > directory on different machines. Martin, Joey and others > made a perfect job in defining/describing a solution with > Joey's tool MR. I actually got my vcs-home impulse from Joey. > What is ~/.mrsetup. Is .mrconfig meant here? Yes. > Why is it so. Martin also wrote before: > > > mr is Joey Hess' multiple repository tool and I configure it > > like > > this: > > http://git.madduck.net/v/etc/mr.git?a=tree;f=.mr;hb=HEAD. On > > each machine I symlink those collections in ./roles to ~/.mr > > (which > > is what you see at the link). ~/.mrconfig then simply > > includes them > > and mr manages all my repos, including those under ~/.fgits > > Now i thought that there is only a single .mrconfig. This > one is checked out by mrsetup in an earlier phase. The > global .mrconfig file includes all modules which are put in > ~/.mr/? (symlinked from ~/roles) Look at the script: the idea is that I store .mrconfig for each machine/account separately, just in case I want to make local changes. mrsetup checks in an auto-generated .mrconfig file in case there isn't one for this account yet. -- martin | http://madduck.net/ | http://two.sentenc.es/ "sometimes we sit and read other people's interpretations of our lyrics and think, 'hey, that's pretty good.' if we liked it, we would keep our mouths shut and just accept the credit as if it was what we meant all along." -- john lennon spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: mrsetup and the rest of the toys
also sprach Mario Scholz [2009.11.25.1125 +0100]: > The template mrconfig includes everything by running find over all > 'roles/*' > and sourcing 'base'. > > This means as a default on a new machine you take everything? No, not roles/*. ~/.mr/templ/.mrconfig only says ~/.mr/*. > For an account with less modules you modify your account specific > .mrconfig. > So symlinks are not used. Right? I symlink from ~/.mr/roles/* to ~/.mr/ and store those symlinks in each account's git repository. > I would skip the 2-times .mrconfig bootstrapping. But this is my > personal taste. That was from a time when mr moved so fast that I needed a local checkout. Nowadays, the Debian package probably will do. > Thinking currently if it makes sense for me having .mrconfig > account specific or doing it like in Joey's .mrconfig.complex with > matching the hostname. Then the repository configuration for all > hosts is in one place as for me its a "single" home directory with > host-specific variations. Not sure right now. I find single-file approaches too limiting, and they will get out of control quickly if you have more than a handful accounts. -- martin | http://madduck.net/ | http://two.sentenc.es/ die wahrheit ist selten auf seiten der wahrscheinlichkeit. -- heinrich v. kleist spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: Another dotfiles manager
also sprach chombee [2010.03.10.1822 +0100]: > I'm sure everyone already has their own one of these, but I just wanted > to post my dotfile manager: > > http://github.com/seanh/dotfilemanager > > I've been using it for a while now and it seems to work well, I've > ironed out a couple of bugs that it initially had. It's basically a > re-implementation of Steve Kemp's dotfile manager in Python, but with > some minor design tweaks. I wonder what these offer that GNU stow or xstow couldn't do. Similarly, I wonder why people use symlinks instead of hardlinks. Sure thing, hardlinks are brittle, but if the manager keeps track anyway, it might just as well recreate hardlinks as necessary. -- martin | http://madduck.net/ | http://two.sentenc.es/ "to every complex problem, there is a solution which is short, simple, and wrong." -- mencken spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: Another dotfiles manager
also sprach Pavel Avgustinov [2010.03.11.1322 +0100]: > >From what I can see, the host-specific linking (i.e. prefer > >a file with suffix "__foo" on host foo). I wonder whether this isn't something for VCS branches anyway > > Similarly, I wonder why people use symlinks instead of > > hardlinks. Sure thing, hardlinks are brittle, but if the manager > > keeps track anyway, it might just as well recreate hardlinks as > > necessary. > > I think the killer point is that you can remove a file from the > .config directory and detect dangling symlinks, while you wouldn't > be able to tell a dangling hard link apart from an untracked > config file. Oh, but there might be other dangling symlinks, so to discern those managed from those external, the tool needs to keep track in a state file anyway. > Anyway, one feature that my custom-baked scripts provide which > isn't present (I think -- happy to be corrected!) in either of the > dotfile-manager solutions is merging multiple VCS-controlled files > into one. Having a .d solution integrated is indeed nice, I use it extensively in some repos, but I currently rely on custom Makefiles, e.g. http://git.madduck.net/v/etc/ssh.git/blob/HEAD:/.ssh/Makefile The problem is of course that the actual config files then become caches, and it's happened that I forget and lose changes that way. Oh well. The true solution is either - a filesystem layer change allowing read() access to a directory (you would lose the ability to filter files like run-parts) - a layer which uses e.g. xattrs to define those filters - a way to tie a program call to a file, so that if the file is read, the program is run instead (The Hurd can do that) - adding includedir or similar directives to all the applications. I think the latter is going well, but it'll take a while still. For SSH, I've requested the feature for authorized_keys.d nearly two years ago: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=481251 and similar other requests exist. -- martin | http://madduck.net/ | http://two.sentenc.es/ only by counting could humans demonstrate their independence of computers. -- douglas adams, "the hitchhiker's guide to the galaxy" spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: Preserving timestamps with git
also sprach Jakob Voss [2010.05.26.1826 +0200]: > But git-utime is only one side of the process. How do I > > 1) reset the commit time of selected files in the repository to their > last modification timestamp (for the files that I have already > commited) man touch > 2) add and commit a set of files in a batch such that each commit has > the timestamp of the last modification time of its file (for new > files). man git-commit > How do you deal with timestamp of you files? I heard there are > some hacks to even preserve file permissions but I'd prefer > a simple solution first. Well, I'd suggest you don't reinvent the wheel and instead use metastore: http://repo.or.cz/w/metastore.git It doesn't force you to do one-commit-per-file, but instead just saves and restores the metadata separately. -- martin | http://madduck.net/ | http://two.sentenc.es/ "the perfect gun is an idealist without any ideal." -- mc 900 ft jesus spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: using git to version large files w/o checking them in
also sprach Abhishek Dasgupta [2010.09.30.0911 +0200]: > Isn't this what unison does? Note that you cannot combine unison with Git though. -- martin | http://madduck.net/ | http://two.sentenc.es/ "to me, vi is zen. to use vi is to practice zen. every command is a koan. profound to the user, unintelligible to the uninitiated. you discover truth everytime you use it." -- reddy ät lion.austin.ibm.com spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: Python script for automatic synchronization based on inotify
also sprach Dieter Plaetinck [2011.03.20.1235 +0100]: > oh, one more thing. > you can query the current branch in a pure-python way, by reading .git/HEAD No, please do not use this. Use git symbolic-ref -q HEAD || git name-rev --name-only HEAD -- martin | http://madduck.net/ | http://two.sentenc.es/ sex an und für sich ist reine selbstbefriedigung. spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: Python script for automatic synchronization based on inotify
also sprach Dieter Plaetinck [2011.03.23.0933 +0100]: > well, the idea behind doing it in pure-python is removing the > overhead of spawning extra processes, do you have an argument why > reading the branchname of the current HEAD in a few lines of > python is bad? .git/* is not a public API. It's considered internal. -- martin | http://madduck.net/ | http://two.sentenc.es/ "america may be unique in being a country which has leapt from barbarism to decadence without touching civilization." -- john o'hara spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: Python script for automatic synchronization based on inotify
also sprach Felix Kaiser [2011.03.23.1250 +0100]: > > .git/* is not a public API. It's considered internal. > > > > Not its not. > > Its even documented[1]: "... a valid git repository must have the > HEAD file; some porcelains may use it to guess the designated > "default" branch of the repository (usually master)." Ha. This is news to me. Interesting, thanks. -- martin | http://madduck.net/ | http://two.sentenc.es/ "next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank god for the better sleep he enjoys after this process of grotesque self-deception." -- mark twain spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: fake git repositories.. how far do you go?
also sprach Dieter Plaetinck [2011.03.03.1416 +0100]: > I meant "fake bare git repositories". I just try to stick to the > existing terminology. see the articles I linked to, where the > concept is explained in detail. "detached bare" would be better. -- martin | http://madduck.net/ | http://two.sentenc.es/ "the duration of passion is proportionate with the original resistance of the woman." -- honoré de balzac spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: Fw: fake git repositories.. how far do you go?
also sprach Dieter Plaetinck [2011.03.03.0953 +0100]: > I could not really understand why one would actually _want_ > multiple fake git repositories. When I commit a change to my vim configuration, that has nothing to do with the history of changes to my mutt configuration. Thus, I prefer to keep them separate, and Git lets me do that. Now I can share each configuration on git.madduck.net and people can clone just the parts they want. In short: because I can, and tools like vcsh and mr and all the others make it a little less cumbersome. But if you prefer to use a single repo for your homedir stuff, do it. -- martin | http://madduck.net/ | http://two.sentenc.es/ "if beethoven's seventh symphony is not by some means abridged, it will soon fall into disuse." -- philip hale, boston music critic, 1837 spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: Announcing: dotfuse a project this list may find useful
also sprach Erich Heine [2011.03.13.1710 +0100]: > I'm not sure how to get around this just yet, other than suggest > not using this system for configuring programs that modify the rcs > internally. Although now that I think about it, a read could > trigger a hook, calling a per config file script which would know > how to parse the config and possibly decompose it to the > appropriate templates. You could write a diff of the file as written by the programme against the file as would be generated from the templates. Existence of a diff would trigger warnings to the user whenever possible to reintegrate the diff into the templates. I use this system for my SSH known_hosts management: new hosts are added to a temporary file, and SSH (wrapped by a zsh function) warns me of its existence, meaning that I have to integrate new hosts. -- martin | http://madduck.net/ | http://two.sentenc.es/ "it usually takes more than three weeks to prepare a good impromptu speech. -- mark twain spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: Fake bare git repos
also sprach Richard Hartmann [2011.04.02.2203 +0200]: > Can someone dump a current snippet that will create a fake bare > git repo that works locally _and_ allows me to push to a truly > bare remote? The concept of "fake bare git" comes from the fact that the GIT_DIR is names e.g. vim.git (instead of .git), which is like a bare repo, but core.bare is set to false (hence "fake"), because there is a worktree, albeit it's detached. I think "detached worktree repository" also covers it and might be a better name. Here is how to create one: Create a *non-bare* repo as you would always do, but in a temp directory (or directly in ~ if you wish): mkdir mytempworktree && cd mytempworktree git init git remote add origin ssh://server/path/to/repo git config branch.master.remote origin git config branch.master.merge refs/heads/master Or if the repo already exists remotely, clone it into a temp directory (or ~): mkdir mytempworktree && cd mytempworktree git clone git://git.madduck.net/madduck/pub/etc/vim.git Then move the GIT_DIR to the final location and set core.worktree to point to the worktree (~ in our case) git config core.worktree ../../ # ~/.fgits/vim.git/../../ → ~ mv .git ~/.fgits/vim.git and possibly move checked out files to the worktree: mv * .* ~ To work with the repo, make sure to export GIT_WORK_TREE=$HOME GIT_DIR=$HOME/.fgits/repo.git or: alias git="git --work-tree=$HOME --git-dir=$HOME/.fgits/repo.git") Essentially, this is what my vcsh function does for me: http://git.madduck.net/v/etc/zsh.git/blob/HEAD:/vcsh -- martin | http://madduck.net/ | http://two.sentenc.es/ "glaube heißt nicht wissen wollen, was wahr ist." - friedrich nietzsche spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: fake git repositories.. how far do you go?
also sprach martin f krafft [2011.04.06.1040 +0200]: > "detached bare" would be better. Actually, see http://lists.madduck.net/pipermail/vcs-home/2011-April/000378.html Sorry, -- martin | http://madduck.net/ | http://two.sentenc.es/ "the surest way to corrupt a youth is to instruct him to hold in higher esteem those who think alike than those who think differently." -- friedrich nietzsche spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: Announcing: dotfuse a project this list may find useful
also sprach Dieter Plaetinck [2011.04.07.1721 +0200]: > well, in my experience, many of the apps who like to modify the > rc/config files themselves, do it quite frequently. Thinks like > "last window position" or "last open folder [in the app]" can get > updated a few to tens of times per day. I wouldn't like to > reintegrate all that myself manually. Then file bugs for those are cache data, not configuration data. ;) -- martin | http://madduck.net/ | http://two.sentenc.es/ anyone who says sunshine brings happiness has never danced in the rain. 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
attachments (was: [mr] support for vcsh)
also sprach Richard Hartmann [2011.11.29.2255 +0100]: > I got a report that there's no attachment to this email. The email i > sent _does_ have an attachment, the archive does not... The list does filter certain types of attachment. Part of the reason is that attachments cannot be changed (like pastes…). So instead, I always suggest that you ought to send gitweb URLs ;) Cheers, -- martin | http://madduck.net/ | http://two.sentenc.es/ for years, we have thought that a million monkeys typing at a million typewriters would eventually produce the complete works of shakespeare. today, thanks to the internet, we know this is not true. 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
My vcsh is deprecated
Folks, just so you know: I have deprecated my vcsh script a long time ago, and now it's official: http://git.madduck.net/v/etc/zsh.git/commitdiff/4e5f7ffb64e3e06024312c9d8595c4504dd1 Since RichiH's vcsh is fully functional and compatible, please migrate to his: https://github.com/RichiH/vcsh The can only be one, and from now on, vcsh is RichiH's script. Cheers, -- martin | http://madduck.net/ | http://two.sentenc.es/ "everyone has a little secret he keeps, i like the fires when the city sleeps." -- mc 900 ft jesus spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: trying out vcsh
also sprach Brian May [2012.02.06.0116 +0100]:
> Just recently I heard of this vcsh thing, just some of my initial
> thoughts.
Just recently started to clean out my inbox… ;)
> 2. I found following the instructions for creating new
> repositories insufficient (section 4.1.4); I also had to add the
> following to $HOME/.config/vcsh/repo.d/foo.git/config:
>
> [branch "master"]
> remote = origin
> merge = refs/heads/master
>
> otherwise "mr pull" won't work. Is there an easier way to make
> this change, e.g. using git command line?
vcsh run foo git config branch.master.remote origin
…
> 3. If I accidentally add a repository I didn't want, is there an
> easy way of removing it and the checked out files? Maybe this is
> what vcsh delete is meant to do?
vcsh remove now exists.
> 4. What is the recommended practise for $HOME/.gitignore? I found
> this file on one host only, and it is not committed anywhere.
> Should I be adding it to a repository?
I am still working on that. Right now, vcsh write-gitignore writes
a file into ~/.gitignore.d/ for each repo, but that file is only
used by the repo. And while this makes work within a repo nice and
tidy (mostly), it has a couple of drawbacks:
- git add requires the -f flag
- no trivial way to reuse the information outside of the repo,
e.g. for a ~/.git repository. Wouldn't it be nice to be able to
say git status in ~ and be told which files are not tracked by
*any* repo?
- I don't like that ~/.gitignore.d/foo is a "config file" that
mostly just replicates (cached) what is known to Git. I feel
like this information can be extracted from Git directly. But
I have not figured out how to deal with non-tracked files like
.Xauthority. I would want my 'x' repo to know to ignore the
file. Right now, I could add it to ~/.gitignore/x but I don't
want to use those files as config files.
> 5. Suspect this is related to 4; am concerned about the
> possibility that I might accidentally commit the same file to two
> different repositories. For example by running git add on the
> wrong repository. Are there any safe guards to prevent this from
> happening?
Wouldn't be hard to do, again using vcsh which. The requirement to
pass -f to git add is also a bit of a safe-guard. Best practice
might be to add an exclusion to the respective gitignore file before
adding, then the -f won't be needed.
> 6. Would it be possible to implement commands that, assuming the file
> is already committed to an active repository, automatically work out
> this repository from the list of files? e.g.
>
> vcsh add .zshenv
> vcsh commit
>
> and/or
>
> vcsh commit .zshenv
This should be possible with a simple wrapper around vcsh which and
vcsh run, e.g.
vcsh which '^\.zshenv' | cut -d: -f1 | xargs -I '{}' vcsh run '{}' git …
Arguably, this could be made into a vcsh subcommand, e.g.
vcsh run-by-file '^\.zshenv' git …
> 7. I can see why it is done this way, but not entirely comfortable
> with having duplicate information about repositories (e.g. the
> upstream repository) both in $HOME/.config/mr/available.d and
> $HOME/.config/vcsh/repo.d . For example, if you want to change to
> upstream repository, it becomes clumsy to do so; I think every host
> would have to be updated manually (at least the repo.d directories).
> Similarly, when a repository is activated, there are two places that
> have to be changed to reflect this that could become inconsistent with
> each other. Still thinking about this issue.
I cannot think of a smart way to reuse these data. The way I think
you are supposed to approach this is by making the change in
$HOME/.config/mr/available.d and add a pre-hook to the update
command to fire off the appropriate vcsh run … git config … commands
prior to running the update.
--
martin | http://madduck.net/ | http://two.sentenc.es/
"with sufficient thrust, pigs fly just fine. however, this is not
necessarily a good idea. it is hard to be sure where they are going
to land, and it could be dangerous sitting under them as they fly
overhead."
-- rfc 1925
spamtraps: madduck.bo...@madduck.net
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home
Re: attachments in this ML (was: Re: mr/vcsh integration)
also sprach Andre Klärner [2013.04.28.2310 +0200]: > funny - I just cleared the personal copies of the > mailinglist-messages, and the mailing-list copy did not contain > the attachment. Does someone know about if this mailing list > strips all attachments (also noticed it with my messages that are > now a broken multipart/signed). It's true, the mailing list is set up to remove attachments that are not multipart application/pgp-signature text or have any of the following extensions: exe bat cmd com pif scr vbs cpl I'd be glad to extend this as needed. What was the attachment that got dropped? -- martin | http://madduck.net/ | http://two.sentenc.es/ "the sick do not ask if the hand that smoothes their pillow is pure, nor the dying care if the lips that touch their brow have known the kiss of sin." -- oscar wilde spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: attachments in this ML (was: Re: mr/vcsh integration)
I have simply removed all filters for now. Users of this mailing list surely know not to abuse it nor are they endangered of opening .pif files! ;) -- martin | http://madduck.net/ | http://two.sentenc.es/ "wickedness is a myth invented by good people to account for the curious attraction of others." -- oscar wilde spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: cdgit: cd relative to git workdir root
also sprach Thomas Koch [2013.09.16.2101 +0200]: > shell alias cdgit = cd $(git root) I've tried to make this happen many years ago, but I never finished the ZLE widget that did it. The idea was to bind 'tab' to a function that would replace an occurrence of ~g in $LBUFFER with the output of rev-parse--show-toplevel and then delegate to normal tab expansion. So now I just have hash -d g=$(git rev-parse --show-toplevel) in a pre-prompt function and get the same effect. fishbowl:~/code/salt|develop|debian% ls ~g/debi -- martin | http://madduck.net/ | http://two.sentenc.es/ "i am not in favour of long engagements. they give people the opportunity of finding out each other's character before marriage, which i think is never advisable." -- oscar wilde 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
automating git-annex relationships
I found some time to play with myrepos & vcsh & 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@fishbowl:~/family/veronika/photos [here] 296d71bb-1aef-4381-b15a-8c9f13836254 -- madduck@albatross:~/family/veronika/photos ecedc885-2ecd-4f3a-8bae-ae2c27ae1f37 -- madduck@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? -- @martinkrafft | http://madduck.net/ | http://two.sentenc.es/ http://www.transnationalrepublic.org/ 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
git annex loses track of files it has locally
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@albatross:~/family/veronika/photos [albatross] 81162b32-96f0-4573-94ef-e2930a439bfb -- pe...@hippolyta.gern:~/v-photos ecedc885-2ecd-4f3a-8bae-ae2c27ae1f37 -- madduck@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/s0: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@fishbowl:~/family/veronika/photos [here] 296d71bb-1aef-4381-b15a-8c9f13836254 -- madduck@albatross:~/family/veronika/photos [albatross] 81162b32-96f0-4573-94ef-e2930a439bfb -- pe...@hippolyta.gern:~/v-photos ecedc885-2ecd-4f3a-8bae-ae2c27ae1f37 -- madduck@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, -- @martinkrafft | http://madduck.net/ | http://two.sentenc.es/ "out of the crooked timber of humanity, no straight thing was ever made." -- imanuel kant spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: automating git-annex relationships
also sprach Adam Spiers [2014-09-09 15:59 +0200]: > This is how I do it: > > http://lists.madduck.net/pipermail/vcs-home/2012-May/000806.html Right, so you seem to have a central mr config repo with all the knowledge of who has which repo checked out, so that you can then say that repo XYZ should have remotes A, B, and C, because you are pushing that repo to A, B, and C. This is one way of doing it, and I'll probably look very closely into your code soon (it's cloned). However, my question was more about ways to reuse the knowledge git-annex accumulates anyway. Say there's ~/photos and it's currently checked out on machineA and machineB as A and B. Now I bring machineC online and pull ~/photos there too (into C) With your approach, I'd then change the global mr config and add C to the remotes for ~/photos, and wait until this percolates to all clients. However, by time time I clone into C, git-annex knows whether A/B have copies. What's needed now is a way for me to specify mappings or something similar, globally for git-annex. Such a mapping would tell git-annex how each machine can be reached from each other machine, e.g. machineA → machineB machineB.local machineB → machineA machineA.local machineA → machineC - machineC → machineA machineA.rack.example.org machineB → machineC - machineC → machineB machineB.rack.example.org and maybe some path mangling stuff, since A on machineA might not be in the same place on the filesystem as B on machineB, etc. With this knowledge, at the time of cloning, git-annex could set up all the remotes and bootstrap the annex content from the fastest machine. Here's a bit of demo: % GIT_DIR=repo.git git --bare init && ( cd repo.git && git annex init centre ) Initialized empty Git repository in /home/madduck/.tmp/cdt.qu3lXa/repo.git/ init centre ok (Recording state in git...) % git clone ./repo.git one Cloning into 'one'... done. % cd one % git annex init one init one ok (Recording state in git...) % date > a && git annex add a add a ok (Recording state in git...) % git annex sync --content (merging origin/git-annex into git-annex...) (Recording state in git...) commit ok pull origin ok copy a copy a (to origin...) ok pull origin ok (Recording state in git...) push origin Counting objects: 21, done. Delta compression using up to 8 threads. Compressing objects: 100% (16/16), done. Writing objects: 100% (21/21), 1.81 KiB | 0 bytes/s, done. Total 21 (delta 3), reused 0 (delta 0) To /home/madduck/.tmp/cdt.qu3lXa/./repo.git * [new branch] git-annex -> synced/git-annex * [new branch] master -> synced/master ok % git annex whereis whereis a (2 copies) 2ec5ef5a-4ad1-4b21-b391-9667666ec014 -- centre [origin] 653ff939-5433-44cc-b32e-3d6a2b18d117 -- one [here] ok So far, so good. Now let's clone "two": % cd ../ % git clone ./repo.git two && cd two && git annex init two Cloning into 'two'... done. init two ok (Recording state in git...) % git annex whereis (merging origin/git-annex origin/synced/git-annex into git-annex...) (Recording state in git...) whereis a (2 copies) 2ec5ef5a-4ad1-4b21-b391-9667666ec014 -- centre [origin] 653ff939-5433-44cc-b32e-3d6a2b18d117 -- one ok If git-annex knew at this point that "one" was accessible as ../one (or other-machine:/path/to/one), then it could set up the remote: % git remote add one ../one && git remote update Fetching origin Fetching one From ../one * [new branch] git-annex -> one/git-annex * [new branch] master -> one/master * [new branch] synced/master -> one/synced/master % git annex sync --content […] % cat a Tue Sep 9 16:43:51 CEST 2014 And the next time that "one" is sync'd, "two" appears, and if git-annex knows that "two" is accessible as ../two, then it could set up the remote: % git annex sync […] % git annex whereis whereis a (3 copies) 2ec5ef5a-4ad1-4b21-b391-9667666ec014 -- centre [origin] 653ff939-5433-44cc-b32e-3d6a2b18d117 -- one [here] 8e720e4f-e90e-4c63-b2cc-20a50a2598cf -- two ok % git remote add two ../two && git remote update […] My point is that rather than having to maintain which repos should know about which remotes in some central place, git-annex provides these data. Now we just need to find a way to make it happen. Joey, have you considered this? -- @martinkrafft | http://madduck.net/ | http://two.sentenc.es/ "the surest way to corrupt a youth is to instruct him to hold in higher esteem those who think alike than those who think differently." -- friedrich nietzsche 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.ma
Re: git annex loses track of files it has locally
also sprach Joey Hess [2014-09-09 16:46 +0200]: > > 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. > > fsck --fast This fixed it. Weird, as I always thought --fast would be a more shallow check, but I guess the problem was that the checksums *were* ok, and the problem was at a different layer? But why didn't fsck by itself fix this? -- @martinkrafft | http://madduck.net/ | http://two.sentenc.es/ "was aus liebe getan wird, geschieht immer jenseits von gut und böse." - friedrich nietzsche spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: automating git-annex relationships
also sprach Joey Hess [2014-09-09 17:20 +0200]: > Note that the part after the -- here is just a description, and can be > any free-form text. I was going to suggest that there could be another field added to the protocol, but… > Recent versions of git-annex have a hidden feature that's used by the > webapp. The url of an existing git remote can be stored: > > git annex initremote albatross type=git > location=madduck@albatross:~/family/veronika/photos … you preempted that! > And then the same git remote can be set up elsewhere, using that stored > url: > > git annex enableremote albatross Unfortunately, the requirement for the remote to already exist kinda makes it hard to use, for two reasons: 1. The location depends on both sides of the equation, there's not always a canonical one. 2. I'd want to set up the special remote once locally, and then use it elsewhere. If I have to set it up elsewhere, I might just as well add the remote directly… % git annex initremote one type=git location=`pwd` (merging origin/git-annex into git-annex...) (Recording state in git...) initremote one git-annex: could not find existing git remote with specified location > I use mr to set up remotes. > > [lib/downloads] > checkout = > git clone ssh://j...@git.kitenet.net/srv/git/downloads > cd downloads > git remote add website > ssh://j...@git.kitenet.net/srv/web/downloads.kitenet.net/.git Yeah, like Adam. With the use-case of two machines that are more or less identical, as well as plenty of SSH hosts out there, which only get a subset of the repos, I would have to keep a list of remotes centrally maintained, and possibly a different set for each host as remote URI depends on the relationship, not a single host. Maybe Git rewrite rules can help here, as Adam suggests, but it just gets messy. The reason I am worrying about this is because rather than having a single git-annex repo for everything in $HOME, I'd rather have a different repo for each project I am involved with, and that's several dozens, so there's a lot of repetitive work ahead, and much redundancy to be created. The reason for having separate annexes is quite simply that some of them are shared with others, while most are not. So yes, I could have a single annex for $HOME and a few annexes for sharing, and use views (tags) to select which files appear where. But views don't (yet) update automatically¹ and there are strict limitations on filenames², which make views a nice query tool, but not really a tool for persistent use. ¹) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743820 ²) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743794 I would love to have real tagging because I have so many files that belong to more than one project… :/ -- @martinkrafft | http://madduck.net/ | http://two.sentenc.es/ "i believe that the moment is near when by a procedure of active paranoiac thought, it will be possible to systematise confusion and contribute to the total discrediting of the world of reality." -- salvador dali spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: git annex loses track of files it has locally
also sprach Joey Hess [2014-09-09 17:31 +0200]: > It does. Nowhere in your mail did you say you'd tried fsck. Oh, because I thought it's run as part of repair. But looking again: % git annex repair Running git fsck ... […] this is git-fsck, not git-annex-fsck ;) -- @martinkrafft | http://madduck.net/ | http://two.sentenc.es/ ... the ravenous bugblatter beast of traal (a mind-bogglingly stupid animal, it assumes that if you can't see it, it can't see you -- daft as a bush, but very very ravenous); -- douglas adams, "the hitchhiker's guide to the galaxy" spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: git annex loses track of files it has locally
also sprach Joey Hess [2014-09-09 18:09 +0200]: > You forgot to mention that you have (based on irc log) been using > git annex forget. If anything is going to cause git-annex to lose > location tracking information it would be that. Good point. But on the upside of things, now I know a bit more about it ;) -- @martinkrafft | http://madduck.net/ | http://two.sentenc.es/ during the voyage of life, remember to keep an eye out for a fair wind; batten down during a storm; hail all passing ships; and fly your colours proudly! 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
ls tricks for git-annex?
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? -- @martinkrafft | http://madduck.net/ | http://two.sentenc.es/ "work consists of whatever a body is obliged to do. play consists of whatever a body is not obliged to do." -- mark twain spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: ls tricks for git-annex?
also sprach Axel Beckert [2014-09-25 08:58 +0200]:
> direnv - Utility to set directory specific environment variables
> environment-modules - Modular system for handling environment variables
> envstore - save and restore environment variables
Yeah, I know about those and it's a possible usecase, except it
requires you to chdir() and the last time I tried these solutions,
they were brittle and could get messy. Setting variables on chdir()
is trivial to do. The problem has always been clearing the
environment when leaving the directory.
But direnv looks good and I will give it a try.
Does anyone have other ideas too?
What would be nice would be /bin/ls with a flag e.g.
ls --dereference-if-reference-matches=*.git/annex/objects/* …
Unfortunately, I fear that we won't be able to get that (still:
#762922)…
Of course, I could do something along the lines of
myls() {
local usecolor; usecolor=never
[ -t 1 ] && usecolor=always
ls --color=$usecolor "$@" |
while read line; do
case "$line" in
(*-\> *.git/annex/objects/*)
echo "@${${line#l}% ->*}";;
(*)
echo "$line";;
esac
done
}
but there is something in me that says it's a really bad idea to use
a pipe here, even if I could live with parsing the output of ls for
this cause.
--
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
"a human being should be able to change a diaper, plan an invasion,
butcher a hog, conn a ship, design a building, write a sonnet,
balance accounts, build a wall, set a bone, comfort the dying, take
orders, give orders, cooperate, act alone, solve equations, analyze
a new problem, pitch manure, program a computer, cook a tasty meal,
fight efficiently, die gallantly. specialization is for insects."
-- robert heinlein
spamtraps: madduck.bo...@madduck.net
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home
Re: ls tricks for git-annex?
also sprach David Edmondson [2014-09-26 15:27 +0200]: > Not your area of interest, I believe, but John Wiegley’s > git-annex.el has proven useful. See > https://github.com/jwiegley/git-annex-el. Yeah, so that's basically a macro for the edit-write-add-commit cycle, and a filter on dired output. I have the former, and my suggested parsing of /bin/ls-output is the latter, but it doesn't feel right at all :/ Anyway, I think I will try it and see… -- @martinkrafft | http://madduck.net/ | http://two.sentenc.es/ "prisons are built with stones of law, brothels with bricks of religion." -- william blake spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: ls tricks for git-annex?
also sprach martin f krafft [2014-09-26 13:00 +0200]: > But direnv looks good and I will give it a try. So direnv hooks into zsh with a precmd hook. I already use those hooks for vcs_info, and it should be trivial to extend this for Shell and consequently all tools such as /bin/ls (via $GIT_ANNEX_LS_OPTS as you suggest). So this leaves /usr/bin/mc and sundry other tools that don't expect to find symlinks-to-readonly-files… -- @martinkrafft | http://madduck.net/ | http://two.sentenc.es/ "wer schmetterlinge lachen hört, der weiss wie wolken schmecken." -- freiherr friedrich von hardenberg spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: ls tricks for git-annex?
also sprach martin f krafft [2014-09-26 13:00 +0200]:
> myls() {
> local usecolor; usecolor=never
> [ -t 1 ] && usecolor=always
> ls --color=$usecolor "$@" |
> while read line; do
> case "$line" in
> (*-\> *.git/annex/objects/*)
> echo "@${${line#l}% ->*}";;
> (*)
> echo "$line";;
> esac
> done
> }
After some experimentation, I have to confess that this won't work.
The above is fine, but you get the mode and filesize of the link,
not the reference. Trying to dereference in the loop works, but
messes up the output as /bin/ls aligns columns…
Does anyone have any experience with LD_PRELOAD? Theoretically one
should be able to inject a readdir() that dereferences git-annex
links, right?
--
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
"marriage is the only adventure open to the cowardly."
-- voltaire
spamtraps: madduck.bo...@madduck.net
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home
Re: vcsh: use branches instead of repos?
also sprach Sitaram Chamarty [2015-06-26 08:37 +0200]: > 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? How would this work? Would you then simple create checkouts of each branch with a detached worktree? What's the benefit of using a single repo (presumably with separate branches that never share history) over multiple ones? -- @martinkrafft | http://madduck.net/ | http://two.sentenc.es/ "'this must be a thursday,' said arthur to himself, sinking low over his beer. 'i never could get the hang of thursdays.'" -- hitchhiker's guide to the galaxy spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: integrating an existing git repo in vcsh
also sprach Alan Schmitt [2016-02-04 00:34 +1100]: > I could not find how to do the following in the documentation. > I already have my .emacs.d under git, and I’m looking into vcsh > for other configuration files. Is it possible to integrate this > existing repo in vcsh? It should be as easy as cloning the repo with vcsh, though I suspect you'll have to first modify the contents and move all files to ./.emacs.d/, assuming that that's currently the worktree of your Git repo. vcsh uses ~/ as the worktree, and so your files would otherwise all be checked out to ~/ instead of ~/.emacs.d/ . -- @martinkrafft | http://madduck.net/ | http://two.sentenc.es/ in seattle, washington, it is illegal to carry a concealed weapon that is over six feet in length. spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: To use vcsh or not to use vcsh, that is the question
also sprach Samuel Hodgkins [2017-01-12 17:20 +1300]: > In comparison to vcsh, I also use myrepos which is excellent at managing a > set of repositories, and although I haven't used it much it can also do > commands. I think (but cannot confirm) that it can be extended with > additional commands just like vcsh and has the benefit of also using normal > git repositories, enabling easier usage from the command-line. I think mrsetup already supports vcsh, so you can use it to manage a combination, as you see fit. -- @martinkrafft | http://madduck.net/ | http://two.sentenc.es/ "the well-bred contradict other people. the wise contradict themselves." -- oscar wilde spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital GPG 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
Dealing with .gitmodules
Hey, The file .gitmodules (man 5 gitmodules, for use with git-submodule) is hardcoded to reside in $GIT_WORK_DIR/.gitmodules. As vcsh repositories all share the same work dir, there's a conflict. Has anyone come up with a smart way to handle this? Thanks, -- @martinkrafft | http://madduck.net/ | http://two.sentenc.es/ "william blake, you're a dead man!" -- nobody spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: Dealing with .gitmodules
also sprach Joshua Haase [2017-03-31 05:37 +0200]: > > The file .gitmodules (man 5 gitmodules, for use with git-submodule) > > is hardcoded to reside in $GIT_WORK_DIR/.gitmodules. As vcsh > > repositories all share the same work dir, there's a conflict. > > Why do you need git modules? For instance, my awesome config relies on the lain plugin, and I also use subprojects for e.g. pass, mutt, vim, and others. How else would you do it? Note that I consider a checkout as part of a configuration, so I want to decide myself when I pull a new version and commit that to config, along with possibly required changes therein. Thus, using myrepos to just recursively pull doesn't really do what I expect. git-submodules is exactly what I want. -- @martinkrafft | http://madduck.net/ | http://two.sentenc.es/ "i can stand brute force, but brute reason is quite unbearable. there is something unfair about its use. it is hitting below the intellect." -- oscar wilde spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: Dealing with .gitmodules
also sprach Kevin Lyda [2017-03-31 09:50 +0200]: > Personally I prefer git subtree over git submodules. And that > said, you're using vcsh which allows for multiple git repos. So > instead of git submodules, just use additional repos. I don't think vcsh/myrepos is a good solution, but git-subtree does seem to work much better. Thanks for the hint. -- @martinkrafft | http://madduck.net/ | http://two.sentenc.es/ the united nations did a poll about food. the only question they asked was: "could you please give your honest opinion about a solution for the shortage of food in the rest of the world?" this poll failed because: - in africa they didn't know what food was - in eastern-europe they didn't know what honest was - in western-europe they didn't know what shortage was... - in china they didn't know what opinion was... - in the middle-east they didn't know what solution was... - in south-america they didn't know what please was... - and in the usa they didn't know what "the rest of the world" was... spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital GPG 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
