Michael Sperber writes:
I don't know what to say to that: I find git's base UI rather
complex,
It is complex, overly and unnecessarily so. It's slowly evolving
toward a sane state, with a couple of big improvements in the last
year (ie, since we switched to hg). The most important one for
distributed development I think is a separate namespace for tracking
branches (sort of like automated CVS vendor branches). An important
UI improvement is interactive versions of the add and rebase commands.
The Git Community Book (
http://book.git-scm.com) helps simplify things
for the new user by describing ONLY the commands used in a normal
workflow, although you're probably past the stage where it sort of
peters out.
and I'm still banging my head against it whenever I have to use
it.
I'm probably trying to use it the wrong way, but I've found its
documentation to be of little help.
Heh. As I told a guy who came busting into the local LUG mailing list
with "My Ubuntu fell down and no matter how hard I kick it it won't
get up!!", "You really ought to stop trying to 'fix' the thing and
start trying to *understand* it." The difference between you and him
of course is that *your* "thing" is hg, not git, and it ain't broken
(for you), leaving you with very little incentive to sit under a tree
and meditate on the git-ness of it all. That is undoubtedly a lot of
my problem with hg, too.
(No doubt due to my predisposition, so there.) With Mercurial, the
most efficient ways of using it are clearly documented---it seems
you just don't like using them.
Well, it's a little worse than that. I don't find the documented
practices efficient or effective compared to git (for my task list, of
course; I make no claims about how I would feel if I were managing a
"gamma" and getting not tens of patches a week, but hundreds a day).
> Also, I found the way that changesets disappeared and changed
identity
> across a pop/push cycle was disconcerting.
Huh?
As documented in the Mercurial book, when you pop a patch, the
corresponding changeset disappears, and when you push it, the
changeset that is created will often (always?) have a new identity. I
had notes that referred to things by changeset id, and they were
invalid afterward.
Since I accomplish the same kind of effect in git with "reset" and
typically rebase any new parallel patches on the existing ones, I am
used to stability of changesets, and to moving up and down the stack
in git, not in some auxiliary tool like MQ or quilt.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta