[OT] Question about Git branches
timothy.c.delaney at gmail.com
Wed Sep 17 03:47:48 CEST 2014
On 17 September 2014 02:25, Chris Angelico <rosuav at gmail.com> wrote:
> On Wed, Sep 17, 2014 at 2:08 AM, Robert Kern <robert.kern at gmail.com>
> > Yes, but this is due to different design decisions of git and Mercurial.
> > prioritized the multiple branches in a single clone use case; Mercurial
> > prioritized re-cloning. It's natural to do this kind of branching in git,
> > and more natural to re-clone in Mercurial.
I disagree that it's more natural to re-clone in Mercurial. It's just that
the preferred workflow of the Mercurial developers is to use clones,
anonymous branches and bookmarks (almost the same as git branches) rather
than named branches - and so that is the workflow that is most associated
with using Mercurial.
Mercurial fully supports multiple lines of development by:
2. anonymous branching (i.e. multiple heads on the same branch) - normally
combined with bookmarks;
3. named branching (the branch name is an integral part of the commit);
4. all of the above combined.
Eventually if you want to merge between lines of development then you end
up with multiple branches (either anonymous or named) in the one repo.
> Ah, I wasn't aware of that philosophical difference. Does hg use
> hardlinks or something to minimize disk usage when you clone, or does
> it actually copy everything? (Or worse, does it make the new directory
> actually depend on the old one?)
If you clone a repo to the same filesystem (e.g. the same disk partition)
then Mercurial will use hardlinks for the repository files (i.e. things in
.hg). This means that clones are quick (although if you don't prevent
updating the working directory while cloning that can take some time ...).
Hardlinks may be broken any time changesets are added to the repo e.g. via
a commit or pull. Only the hardlinks involved in the commit (and the
manifest) will be broken.
Mercurial provides a standard extension (relink) to re-establish hardlinks
between identical storage files. For example, running hg relink in my
current feature branch repo:
[feature_branch_repo:65179] [feature_branch]> hg relink default
relinking d:\home\repos\feature_branch_repo\.hg/store to
tip has 22680 files, estimated total number of files: 34020
collected 229184 candidate storage files
pruned down to 49838 probably relinkable files
relinked 359 files (221 MB reclaimed)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-list