Re: Rewriting bzrmerge.el

[Stephen J. Turnbull]

Lars Magne Ingebrigtsen writes:

 > If there is a way to get two separate branches checked out at the same
 > time without doubling the disk spaces used, that would be nice.

How much more than "negligible" is unacceptable, and how long before
you cross that line is acceptable?

You see, git is not bzr or hg (yes, I know about bzr shared repos, but
my bzr setup with about 5 Emacs branches including trunk, emacs-24,
and emacs-23 uses about 3X as much space as my git repo with all Emacs
git branches in it).  Simply doing "git clone source-repo target-repo"
uses very little extra space (or time) at clone time because the
objects are hard-linked across directories by default.  Of course this
will tend to diverge over time because new commits often won't be
shared, and granularity may be a few MB due to packed objects.  Still,
given the amount of existing history in an Emacs repo
-- most of which will never be GC'd -- I'd be surprised if the extra
space took less than 5 years to reach 150MB (~50% of current Emacs
repos), and I wouldn't be surprised if it took 10 years.  (No, I don't
have any actual data.)

Also, the primary use case Eli talks about is doing synchs of stable
to trunk, and the occasional cherrypick in the other direction.  In
this case, the "trunk" repository will have a copy of the stable
branch, and in the unlikely case they diverge much, you can always
"repack" the "stable" repo by fetching stable-repo into trunk-repo,
then rm -rf and git clone a new stable-repo.  Most of the time is
taken up by rm -rf ....  Whether that hack works for your favorite
feature branches, I don't know (you might not want to pollute trunk
with them before they're ready), but it probably does.

I don't see any good reason for describing any other strategies than
"if you're worried about bootstrap times, just use a second clone from
your local trunk repo".  If somebody really runs into a space issue,
it's easy enough to explain how to reduce space usage.

 > The answer currently seems to be "use git-new-workdir"

This should work OK 99.44% of the time in Emacs workflows, but if the
new user gets frisky with rebasing or commit --amend etc, they *can*
shoot themselves in the foot.  If they do, they almost certainly will
break a private part of the repo that cannot be recovered from public
sources.  I don't think that's worth it, IMHO FWIW YMMV.