From: "Stephen J. Turnbull" <stephen@xemacs.org>
To: David Reitter <david.reitter@gmail.com>
Cc: "Óscar Fuentes" <ofv@wanadoo.es>, emacs-devel@gnu.org
Subject: Re: New sync'd branch
Date: Sat, 29 Aug 2009 12:56:44 +0900 [thread overview]
Message-ID: <87y6p3tgqr.fsf@uwakimon.sk.tsukuba.ac.jp> (raw)
In-Reply-To: <98EAB66C-1F43-4B20-8F41-CAA40BDA58C1@gmail.com>
David Reitter writes:
> And I think you'd have to know [a bit about the revision DAG] for
> Bzr or Hg, too.
Not really. hg is designed to strongly encourage "virtually linear"
development, automatically managing the DAG for "small" divergences
and using the single command "merge" to manually manage "large"
divergences or those with conflicts. By "automatically" I mean that
hg dislikes having multiple heads (anonymous branches) in a single
workspace, so most users use either the fetch extension or pull -u to
pull and merge in a single operation. Thus even though most of the
time your local commit will end up being parallel to somebody else's
commit in the public repository, almost all the time you're in a state
where there's only a single head in your branch. push works to
preserve that invariant for the public repository. This keeps merges
to a minimum, and you rarely need to be aware of the DAG or even the
branch name.
The bzr command set is a big mess, intended to support a wide variety
of variant workflows with a small number of commands each. Most of
the commands are the same across workflows, but often they have wildly
varying semantics depending on how your branch is configured. In
particular, "commit" can mean "record a version in the local repo" (in
a "standalone" branch), "push a version to a remote repo without
recording locally" (in a "lightweight checkout") or "record *and*
push" (in a "heavyweight checkout" or "bound branch"). bzr is
somewhat more friendly to multiple heads than is hg, especially with
the loom extension, but the basic philosophy is the same: try to
maintain a single-headed DAG as much of the time as possible, and
merge only when tactically (the case of a conflict) or strategically
(integrating a feature) necessary. You rarely need to be aware of the
DAG or the branch name in bzr too, but you do need to be aware of the
type of branch (standalone, lightweight checkout, bound branch).
In fact, for both hg and bzr, I'd say if you become aware of the DAG
you had better be a core VCS hacker. Anybody else is in big trouble,
because it requires deep understanding of internals to safely
manipulate the DAG directly.
git can emulate all of these various workflows to some degree
(lightweight checkouts are currently impossible to fully emulate
because of restrictions on pushing from "shallow clones"), but you do
need to understand the DAG well to do so. Also, in git branching is
the cheapest possible operation (a pointer copy) and branch switching
is relatively cheap, so branches tend to proliferate. For that
reason, you need to be aware of branch names, and it's hard in git to
work with anonymous branches.
next prev parent reply other threads:[~2009-08-29 3:56 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-23 22:21 New sync'd branch Stefan Monnier
2009-08-23 22:35 ` joakim
2009-08-24 13:58 ` Leo
2009-08-24 19:24 ` Dmitry Dzhus
2009-08-25 17:44 ` Stefan Monnier
2009-08-26 8:31 ` Miles Bader
2009-08-26 19:04 ` Stefan Monnier
2009-08-27 3:09 ` Eli Zaretskii
2009-08-27 4:47 ` Miles Bader
2009-08-27 5:38 ` Teemu Likonen
2009-08-28 8:34 ` Eli Zaretskii
2009-08-27 6:33 ` Ken Raeburn
2009-08-27 7:08 ` Teemu Likonen
2009-08-27 7:14 ` Christian Faulhammer
2009-08-27 8:55 ` Ken Raeburn
2009-08-27 9:07 ` Miles Bader
2009-08-27 10:11 ` Stephen J. Turnbull
2009-08-28 9:18 ` Eli Zaretskii
2009-08-27 9:47 ` joakim
2009-08-28 9:04 ` Eli Zaretskii
2009-08-28 9:12 ` Miles Bader
2009-08-28 9:19 ` Teemu Likonen
2009-08-28 9:32 ` Eli Zaretskii
2009-08-28 13:03 ` David Kastrup
2009-08-28 13:46 ` Óscar Fuentes
2009-08-28 14:55 ` Juanma Barranquero
2009-08-28 17:11 ` Óscar Fuentes
2009-08-28 17:49 ` Juanma Barranquero
2009-08-28 18:00 ` David Reitter
2009-08-29 3:56 ` Stephen J. Turnbull [this message]
2009-08-29 20:20 ` Richard Stallman
2009-08-28 15:08 ` David Kastrup
2009-08-28 17:21 ` Óscar Fuentes
2009-08-28 19:33 ` David Kastrup
2009-08-28 21:41 ` Óscar Fuentes
2009-08-28 22:20 ` Miles Bader
2009-08-28 22:55 ` Óscar Fuentes
2009-08-29 0:17 ` Miles Bader
2009-08-29 9:08 ` David Kastrup
2009-08-29 15:25 ` Stefan Monnier
2009-08-29 0:46 ` Stefan Monnier
2009-08-28 22:00 ` Miles Bader
2009-08-28 14:01 ` Juanma Barranquero
2009-08-28 14:08 ` Eli Zaretskii
2009-08-28 14:13 ` Juanma Barranquero
2009-08-28 14:33 ` Eli Zaretskii
2009-08-28 14:44 ` Juanma Barranquero
2009-08-28 9:38 ` joakim
2009-08-28 9:48 ` Eli Zaretskii
2009-08-28 10:02 ` Eli Zaretskii
2009-08-28 11:18 ` David Kastrup
2009-08-28 15:59 ` David Reitter
2009-08-27 21:27 ` Stefan Monnier
2009-08-28 8:28 ` Eli Zaretskii
2009-08-27 21:52 ` Glenn Morris
2009-08-27 22:17 ` Chong Yidong
-- strict thread matches above, loose matches on Subject: below --
2009-08-24 22:25 Nick Roberts
2009-08-25 9:29 ` joakim
2009-08-25 14:06 ` Chong Yidong
2009-08-25 21:02 ` Nick Roberts
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y6p3tgqr.fsf@uwakimon.sk.tsukuba.ac.jp \
--to=stephen@xemacs.org \
--cc=david.reitter@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=ofv@wanadoo.es \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.