this particular use case cleanly. It
must use patience diff by default when merging. I might switch to bzr.
On Mon, Apr 26, 2010 at 06:12:35PM +0100, chombee wrote:
> Thanks all. Patience diff may be what I was looking for. I don't want to
> patch git, but perhaps I can implement patien
Thanks all. Patience diff may be what I was looking for. I don't want to
patch git, but perhaps I can implement patience-diff in my merge driver.
I haven't tested but apparently bzr uses patience diff, it may be that
if I put my notes file in bzr it will just work.
On Sun, Apr 25, 2010 at 03:00:49PM +0100, chombee wrote:
> Yeah. I've been looking around, and it looks like there are a couple of
> options. You can get diff3 style or svn style merge conflicts, but
> neither seems like it will be any more useful. And you can provide your
> own
On Sat, Apr 24, 2010 at 12:22:13PM -0700, Gary Johnson wrote:
> Git (or the merge tool that git uses) doesn't know that those
> changes are unrelated. From its perspective, the top of the file
> has been added to with different sets of lines that should resolve
> to one change. It does its best,
On Sat, Apr 24, 2010 at 09:16:20PM -0500, Chanoch (Ken) Bloom wrote:
> Since the order of the entries in the BibTeX file doesn't matter (each
> is identified by its key), I found a very simple solution: every time I
> add a new entry, I add it at a *random* location somewhere in the middle
> of the
I'd like to keep a text file in my homedir called 'notes' which contains
all my notes to myself, and track this file and sync it between
computers using git. I write the file in markdown syntax and each new
entry usually begins with a header. So on machine A I add a new entry to
the top of my notes
On Thu, Mar 11, 2010 at 01:50:01PM +0100, martin f krafft wrote:
> > 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
I kept all my files in a git repo. Eventually the repo got too big to
handle. I archived the .git file and started afresh with git init. Now
I'm looking at some really old work (from a couple of years back), from
my notes I can't figure out some exact details that I need, and the
history of my git
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 St
This looks promising:
http://github.com/commandline/flashbake
As I understand it the basic idea behind flashbake is this: it's a
python script that controls git, when you run flashbake on a directory
it commits any new files or changes to existing files. The idea is to
have flashbake run every fi
On Fri, Feb 27, 2009 at 01:55:16PM -0500, Joey Hess wrote:
> So, some of the specific problems include:
>
>
> * Wanting to check large data files into a repo, but not having space
> to put that repo on some machines.
I think a good idea might be to have a special repo for big files
only. So y
Ok, I see the points regarding why you should use symlinks, why it's worth
putting things in a dotfiles directory, and why you can't just use a
single ln command to create the symlinks. I wonder what you should use
instead then? A simple script seems to be in order. If I were to write a
script I wo
I was doing this briefly in the past (and spoke about it on this list),
but the system I setup was too awkward and it soon got left behind. Now
I'm revisiting the idea, and I want to do it in as simple and convenient a
way as possible. For one thing, I'm planning on using GitHub as the
central serv
Has anyone considered bazaar for homedir versioning?
It seems like it would be pretty good, perhaps better than git, though
I'm not sure yet what gotchas there might be, or how it would deal with
the odd requirements like large binary files, keeping track of file
metadata, etc.
This guy was sort
On Sun, Nov 25, 2007 at 09:45:02PM -0500, Joey Hess wrote:
>
> > * Don't make the git repository directly in your homedir. You don't
> > want git operating on 'live' config files, as this isn't what git was
> > designed for, and who knows what might happen. If git dumps some merge
> > conflicts in
On Tue, Nov 27, 2007 at 11:02:53AM +0100, martin f krafft wrote:
> 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 f
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.
On Mon, Nov 26, 2007 at 12:14:22PM -0500, Joey Hess wrote:
> Yes, that's mr http://kitenet.net/~joey/code/mr/
mr is really nice, it's so simple to get working
Thanks Joey,
I have some questions:
Do you use the same setup as me, with a single centralised bare repo that every
other repo pushes to and pulls from?
It looks as if you have a number of git repositories inside your first git
repository. Do you just .gitignore them?
Also do you have somethi
So is anybody successfully versioning their homedir with git? And do they have
any advice? I have just begun doing
it, and am still working out the process. I'm not versioning everything in my
homedir, I leave out music, photos,
videos and the like, and email, and I only version certain config
19 matches
Mail list logo
