Re: VC mode and git

[Stefan Monnier]

> Those are basically crippled bound branches IMHO;

That's one way to look at them.

But being an avid user of git-new-workdir, I think it goes further than
that.  All the lightweight checkouts don't just share the storage space
but they also share the "git remote" setup, the stash space, and things
like that, which makes a big difference to me (regarding the stash
space, Bzr's shelves were "per checkout" and I often ended up copying
them from one checkout to another, so I appreciate the fact that they're
per-repository in Git).

> if you want to count them separately, that makes sense since Richard
> is always concerned about using Emacs on machines that are seriously
> underpowered by today's standards in OECD countries.

I hate fans, so my computers tend to be seriously underpowered as well.

> Or, for most of bzr's history, you could just use git and get the same
> reduction in space used, without losing disconnected operation. :-)

The .git directory (mine's at 420MB right now) is not significantly
smaller then the .bzr was (I remember mine hovering around 500MB).

>> It also has situations where it handles file-renames better (see
>> the corresponding vc-print-log bug report mentioned recently).
> I wouldn't call that "flexibility"; it's a different approach, and
> IIRC bzr never learned to detect those automatically so you had to use
> bzr rename or bzr copy to get the right answer.

It had "bzr automove" or something like that, but it didn't work very well.

> If bzr can autodetect renames, then it would be more flexible.

Auto-detection is nice (tho I use "git mv" anyway, but it does help when
you forget it).  But the bug-report points out the difficulty of getting
from "this changelog entry" to "the corresponding diff" because you need
to pass the "file name used back then".  It's a difficult problem in
general, but in my experience Bzr handled it better.


        Stefan