emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PROPOSAL: Move to git, now that bzr is no longer a req.


From: Stephen J. Turnbull
Subject: Re: PROPOSAL: Move to git, now that bzr is no longer a req.
Date: Sat, 04 Jan 2014 05:15:24 +0900

Antonio Nikishaev writes:

 > There is hg. It's pretty popular.

True, but it doesn't have the momentum of git.

 > (And it has nice ui and far less wtfs than git)

Git has not WTF'ed me since the first week I used it.  But then, I
thought the concept was cool and read the whole theory of operations
part of the old man page (several times until I understood it).  Most
developers don't want to do that, which is not a problem.  But many of
those developers also want git to fit their preconceptions, which it
doesn't, and that is a problem.

Mercurial, OTOH, has several WTFs, sufficiently F-ed up that I don't
ever use the corresponding features ("named branches", rebase, there
are several others less important).

I also don't really understand the complaints about the git CLI.  I
have a fairly complex set of practices in git, but I use the same
number of commands and *fewer* options in git than I do in hg or bzr.
(This can be improved by using plugins.)  And when I want to do
something complex in git (like filter-branch), I *can* do it, whereas
I can't in hg or bzr.

I'll grant that git's ref-relative commit addressing (including the
whole ref algebra of HEAD^2~6^3) was a bit disconcerting at first, but
it saves me substantial keystrokes compared to the bzr and hg
equivalents (not to mention a lot of screen space that isn't used up
with log or id commands to get hold of a revno).

It's true that Bazaar has some useful features, such as shared repos,
whose performance characteristics are hard to emulate accurately in
git.  I can't speak to Stefan's experience, of course, but when I look
at my git repos, in fact sharing is quite high because branches in
separate repos tend to be very divergent (so only the original shared
objects *can* be shared), and when the main feature branch gets
merged, the whole repo usually gets deleted so the failure of "git
fetch" to hardlink pulled objects isn't a big space leak.  I also
periodically clean up dormant branches by pulling them into a
"warehouse" repo, and then deleting the separate repo.  (I have plenty
of space, this is to clean up the directory listing, not the disk
usage.  But it sure helps conserve disk.)

The only bzr features that I don't see how to emulate effectively in
git are "log -n ...", bound branches, and lightweight checkouts.  But
I've never missed them in git.  I suspect that when the move to git
happens, Stefan will find alternative, functionally equivalent,
workflows appropriate to git after a while.  Unfortunately I can't
promise that.  (In the case of log -n, I far prefer the graphical DAG
displays anyway.)

Steve




reply via email to

[Prev in Thread] Current Thread [Next in Thread]