[Numpy-discussion] DVCS at PyCon

David Cournapeau david@ar.media.kyoto-u.ac...
Mon Apr 13 03:10:02 CDT 2009

Martin Geisler wrote:
> Ondrej Certik <ondrej@certik.cz> writes:
>> Plus with git, you can fetch the remote repository with all the
>> branches and browse them locally in your remote branches, when you are
>> offline. And merge them with your own branches. In mercurial, it seems
>> the only way to see what changes are there and which branch and which
>> commits I want to merge is to use "hg in", but that requires the
>> internet connection, so it's basically like svn.
> No, no, ... I think you're misunderstanding how the history graph works
> in Mercurial. It works like it does in Git -- changesets are in a
> parent-child relationship. So if I cloned a repository at changeset T:
>   ... --- T
> I'm free to make new commits:
>   ... --- T --- A --- B
> And you can do the same:
>   ... --- T --- X --- Y --- Z
> I can pull in your changesets without disrupting my own work:
>             X --- Y --- Z
>            /
>   ... --- T --- A --- B
> Your changesets will be attached to the graph at the point where you
> made them, the same for my changesets. I don't have to merge at this
> point, instead I can continue with my work even though the repository
> has multiple heads (changesets with no childre). So I make C:
>             X
>            /
>   ... --- T --- A --- B --- C
> I might now decide that I like your X, Y changesets but not Z, so I
> merge them Y into my line of work to create D:
>             X --- Y --- Z
>            /       \
>   ... --- T         `---- D
>            \             /
>             A --- B --- C
> or I might decide that I don't need your changesets and discard them by
> cloning or by the strip command from mq (one or the other):
>   hg clone -r C repo repo-with-C
>   hg strip X
> The result is a repository that has only the history up to C:
>   ... --- T --- A --- B --- C
> So I think it's nonsense to say that Mercurial is like Subversion here:
> you pull in changesets when online and you can make new commits, merge
> commits, delete commits while offline.
> Git has the advantage that it names these branches in a nice way, and
> you can work with these names across the network. The bookmarks
> extension for Mercurial is inspired by this and lets you attach local
> names to heads in the graph.

Thanks a lot for this information, that's really useful.

I am still a bit confused about how this works at the UI level, though,
w.r.t one clone/branch. In bzr, there is one branch and at most one
working tree / repository (at least that's how it is used generally). It
looks like hg, while being based on one branch / repository, is a more
flexible. One thing which converted me to git from bzr was the UI for
branch comparison. My basic reference is for release process. Currently,
in numpy, we have the trunk, and potentially several release branches,
which would be one head each if I get the vocabulary right:

                   ------ A ------------ B --------------- C (1.2.x head)
trunk ------ Release 1.2.0 -------- Release 1.3.0 -------- (mainline head)
                                             D--------- E ------- F
-------- (1.3.x head)

How do you refer to different branches from one clone ? For example, if
I want to see the differences between mainline and 1.3.x branch,
cherry-pick things from mainline into both 1.3.x and 1.2.x, etc... How
does it work with bookmarks ?

Also, do we have to agree on everyone using bookmark to communicate each
other (one repository for everything on main numpy web repository), or
can people still use clones for every branch, and "putting things back
into bookmarks" when they push things in the official repo ?



More information about the Numpy-discussion mailing list