Bookmarks - Tutorial / Git comparison
ml_alexand...@gmx.at
I must confess, I do not really understand the concept of bookmarks, and a could not find a proper tutorial about it. Also the "Definitive guide" does not cover the topic; the "branching" tutorial is also a little bit thin.
Can anyone point me to a more detailed source? Particularly now with 1.6, where pushing of bookmarks is possible?
I also do not quite understand the comparison with git. As far as I understand, git has the (nice) feature of cheap (feature) branches that can be also removed without "traces". How bookmarks are similar here, I miss to understand.
thanks a lot
Alex
_______________________________________________
Mercurial mailing list
Merc...@selenic.com
http://selenic.com/mailman/listinfo/mercurial
Christian Ebert
> I must confess, I do not really understand the concept of
> bookmarks, and a could not find a proper tutorial about it.
> Also the "Definitive guide" does not cover the topic; the
> "branching" tutorial is also a little bit thin.
>
> Can anyone point me to a more detailed source? Particularly now
> with 1.6, where pushing of bookmarks is possible?
http://mercurial.selenic.com/wiki/BookmarksExtension
> I also do not quite understand the comparison with git. As far
> as I understand, git has the (nice) feature of cheap (feature)
> branches that can be also removed without "traces". How
> bookmarks are similar here, I miss to understand.
http://blog.experimentalworks.net/2008/11/mercurial-bookmarks/
Note that I don't use bookmarks myself, but this might get you
started.
c
--
theatre - books - texts - movies
Black Trash Productions at home: http://www.blacktrash.org/
Black Trash Productions on Facebook:
http://www.facebook.com/blacktrashproductions
ike
Hi,
This link explains teh different ways of branching too.
http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/
Best regards,
Ike
--
View this message in context: http://mercurial.808500.n3.nabble.com/Bookmarks-Tutorial-Git-comparison-tp957770p958724.html
Sent from the General mailing list archive at Nabble.com.
Daniel Carrera
I am no expert on either Hg or Git, but I'll try to help. If you don't
mind, I'll take a step back and explain branching in git and Hg from
the start:
* A "head" is a changeset without any children.
* A head defines a branch (by going from parent to parent).
So far this is the same for Git and Mercurial. The first difference is
that Git expects you to give each head a name, and Hg does not. The
above two lines fully define branches in Hg. For Git, you also need a
name for each head. This name is in a separate file, not part of the
history. When you make a commit, this file is updated to point to the
new head. This defines branching in Git.
In Mercurial, bookmarks are an add-on feature. It is a name for a
head, stored in a separate file, not part of history, etc etc. In
other words, they are entirely analogous to Git branches. And if you
understand branching in Hg and Git, you will understand why the UI for
bookmarks looks a bit different from branching in Git:
1) In Git, a branch is born with a name:
git branch feature-X
This creates a new branch called feature-X.
2) In Hg, you don't create branches explicitly. They happen naturally
whenever you have heads. So, when you run:
hg bookmark feature-X
What you are doing is assigning a label to an already existing branch
- the one you are on right now. This has some interesting
consequences. You can assign a bookmark to *any* head:
hg bookmark --rev 3fb0a feature-X
Also, there is no reason why a head cannot have several bookmarks
pointing to it:
hg bookmark foo
hg bookmark bar
hg bookmark biz
hg heads <-- will show a head with three bookmarks.
Why you would want to do that, I have no idea. But the point is to
help you grok how Hg bookmarks work.
You can also see why Git has two flags to delete branches:
-d Delete a branch. The branch must be fully merged with HEAD.
-D Delete a branch irrespective of its merged status.
But Hg bookmarks has only one:
-d Delete bookmark.
In Hg, if you delete a bookmark, you've only deleted a line in a file.
A pointer. The branch itself is intact and it doesn't care one bit if
it is merged with anything or not.
Anyway, please let me know if that helps. I'd like to know if I
managed to explain things from the Git point of view.
Cheers,
Daniel.
--
No trees were killed in the generation of this message. A large number
of electrons were, however, severely inconvenienced.
François Gannaz
> I also do not quite understand the comparison with git. As far as I
> understand, git has the (nice) feature of cheap (feature) branches that can
> be also removed without "traces". How bookmarks are similar here, I miss to
> understand.
I'm not an expert at Mercurial, but I think I understood a major difference
between hg and git: Mercurial prefers workflows that use several (cheap) clones.
So if you want a feature branch, work in a new clone. Then you'll decide if you
push your branch back or drop your whole clone.
You can also have a look at the LocalBranch extension (I haven't tried it
myself): http://mercurial.selenic.com/wiki/LocalbranchExtension
--
François
Dave Brosius
I assume that in Git, a branch name refers to the head of the branch ongoing -- even when new revisions are added to the branch, whereas I assume, in Hg the bookmark refers to a revision (potentially a non head revision) of a branch -- and never moves by itself?
Steve Borho
If you enable the feature, bookmarks are moved at commit time.
--
Steve Borho
Bill Barry
Le 2010-07-11, ml_alexand...@gmx.at a écrit :I also do not quite understand the comparison with git. As far as I understand, git has the (nice) feature of cheap (feature) branches that can be also removed without "traces". How bookmarks are similar here, I miss to understand.I'm not an expert at Mercurial, but I think I understood a major difference between hg and git: Mercurial prefers workflows that use several (cheap) clones.
I personally have 3 different projects that use 3 different branching mechanics:
* One repository, never making a second clone, never allowing to have multiple heads (across any named branches). Feature versions are tagged, and if bugfix releases are to be done, they are done on a named branch using the feature tag name (ex: "foo 1.2.0" is the tag and "foo 1.2.1" would be made on the "foo 1.2" named branch). We use MQ a lot on this one to work on new features; I have a habit of swapping out my mq dir for other queues when needed. (there isn't any actual restriction on having multiple clones, but IIS makes life very difficult when working on an asp.net web app that is several gigs large and you change the physical dir constantly).
* Unlimited local clones, multi-headed central repo, bookmarks manage named heads on an individual's machine (nobody else cares about any particular head). Still it is useful to have more than one local clone of this repo for any particular project. Users are merely encouraged to push often to the central hydra-monster repo for the backup it provides. I barely use MQ on this at all (almost exclusively use attic).
* 1 "published repo" per dev that others can pull from to push to their own published repo. Non-core devs are expected to provide MQ patches via email. As a non-core dev myself, I prefer to use pbranch with this one. I have a local pristine copy that I recreate working copies from when I begin new items (local clones are considerably faster than remote clones and in some cases faster than remote pulls).
Martin Geisler
> Le 2010-07-11, ml_alexand...@gmx.at a écrit :
>> I also do not quite understand the comparison with git. As far as I
>> understand, git has the (nice) feature of cheap (feature) branches
>> that can be also removed without "traces". How bookmarks are similar
>> here, I miss to understand.
>
> I'm not an expert at Mercurial, but I think I understood a major
> difference between hg and git: Mercurial prefers workflows that use
> several (cheap) clones.
The Definitive Guide to Mercurial promotes this way of working, but it
is not your only option. It is important to realize that Mercurial has
always supported *multiple light-weight branches* within a single
repository.
Many blog posts describe this as a Git-only feature and fail to realize
that Mercurial supports it too.
--
Martin Geisler
aragost Trifork
Professional Mercurial support
http://aragost.com/mercurial/
Daniel Carrera
> I'm not an expert at Mercurial, but I think I understood a major difference
> between hg and git: Mercurial prefers workflows that use several (cheap) clones.
I do not think that Mercurial in any way prefers clones. You might
argue that clones work better than in Git (e.g. if Git doesn't use
hard links, or if some features in Git don't work with clones - like
cherry picking). But this is very far from saying that Mercurial
*prefers* clones. It doesn't. It just doesn't punish you for using
them.
Daniel.
--
No trees were killed in the generation of this message. A large number
of electrons were, however, severely inconvenienced.
Daniel Carrera
> The Definitive Guide to Mercurial promotes this way of working, but it
> is not your only option. It is important to realize that Mercurial has
> always supported *multiple light-weight branches* within a single
> repository.
>
> Many blog posts describe this as a Git-only feature and fail to realize
> that Mercurial supports it too.
Not only that, but Mercurial's support is inherent to the very nature
of Mercurial, just as it is with Git. Cheap branches in the same
repository are not an add-on feature for either Hg or Git. In fact,
they have the same basic branching model except that Git expects heads
to have names and Hg does not. This one difference is responsible for
probably most of the UI differences between Hg and Git branching.
--
No trees were killed in the generation of this message. A large number
of electrons were, however, severely inconvenienced.
Daniel Carrera
> Good explaination. A follow up question then.
> I assume that in Git, a branch name refers to the head of the branch ongoing
> -- even when new revisions are added to the branch, whereas I assume, in Hg
> the bookmark refers to a revision (potentially a non head revision) of a
> branch -- and never moves by itself?
No. What you are describing sounds like a *tag* (as in "hg tag" or
"git tag"). As I said in my post, when you make a new commit (aka
revision, aka changeset) the bookmark pointer goes to the new head
automatically, just like Git branch names. Let's do an experiment:
~/repo % hg init
~/repo % echo "Hello world" > file
~/repo % hg add file
~/repo % hg commit -m 'Initial commit'
Ok, so we have a repository. Let's add a bookmark:
----------------%<-------------
~/repo % hg bookmark 'Feature X'
~/repo % hg log --style compact
0[Feature X,tip] 4f7714ebf23d 2010-07-12 09:35 +0200 dcarrera
Initial commit
----------------%<-------------
Now add a revision and see what happens with the bookmark.
----------------%<-------------
~/repo % echo "Salutations" > file
~/repo % hg commit -m 'Updated greeting'
~/repo % hg log --style compact
1[Feature X,tip] bc5cc272a968 2010-07-12 09:36 +0200 dcarrera
Updated greeting
0 4f7714ebf23d 2010-07-12 09:35 +0200 dcarrera
Initial commit
----------------%<-------------
As you can see, the bookmark did move when we added a new revision.
Masklinn
> You can also see why Git has two flags to delete branches:
>
> -d Delete a branch. The branch must be fully merged with HEAD.
> -D Delete a branch irrespective of its merged status.
>
> But Hg bookmarks has only one:
>
> -d Delete bookmark.
>
> In Hg, if you delete a bookmark, you've only deleted a line in a file.
> A pointer. The branch itself is intact and it doesn't care one bit if
> it is merged with anything or not.
FWIW neither does it in git, fundamentally, and you can get at the "lost" commits via the reflog. The point would mostly be UI and clarity, the difference between deleting the branch label and deleting the branch itself (and all of its content, though as I mentioned above you can get that content back via the reflog).
Daniel Carrera
> FWIW neither does it in git, fundamentally, and you can get at the "lost" commits via the reflog.
...until the next garbage collection.
Notice that I said that Git "expects" a name, not that it mandates
one. When explaining the basic feature I didn't want to confuse the
issue with minutiae.
In Git, normal day to day commands require a branch name. If a head
doesn't have a name, you can still get at it by jumping through the
reflog hoop, but only if you don't wait too long because the next
garbage collection will wipe it out. I think this justifies the
statement that Git "expects" a branch name.
In Git you cannot reasonably work without branch names. Trying to do
so would be both very difficult and very dangerous. In Mercurial, this
isn't a problem and the issue of names is truly at the developer's
discretion. This is the reason why Mercurial can offer more than one
way to keep track of branches:
1) You can use bookmarks.
2) You can use named branches.
3) You can use clones.
4) Heck, you can use nothing at all. The "hg heads" command shows you
all the heads. If you can figure out which head is which without using
a special label, go for it. For example, if I pull from you, the
branch with your changes is going to have your name attached. I might
decide that this is enough and I don't need to label it further.
Daniel.
--
No trees were killed in the generation of this message. A large number
of electrons were, however, severely inconvenienced.
Masklinn
> On Mon, Jul 12, 2010 at 9:47 AM, Masklinn <mask...@masklinn.net> wrote:
>> FWIW neither does it in git, fundamentally, and you can get at the "lost" commits via the reflog.
>
> ...until the next garbage collection.
>
git gc calls expire with the standard/configured expiration time (it defaults to 90 days, or 30 days for unreachable objects). They can be configured via gc.reflogExpire and gc.reflogExpireUnreachable.
Daniel Carrera
> Actually, that's not the case. I had the same misconception but reflog is only pruned after
> a set time limit (or explicitly via git reflog expire, which end users pretty much never call).
Ok, I stand corrected. But everything else I said still applies, even
the part that if you wait too long your commit will be lost.
--
No trees were killed in the generation of this message. A large number
of electrons were, however, severely inconvenienced.
Daniel Carrera
An important design feature of Mercurial is that it will never delete
or overwrite a revlog out of concern for data safety. Therefore, the
only way to perform a "destructive" operation in Hg (e.g. delete a
branch) is to use clones. The only exception is rollback - this is the
only Hg command capable of losing data.
This is an interesting design decision, and it points to a difference
between Git and Hg: If you *want* to destroy data, Hg does require
you to use clones. Whereas Git is willing to perform destructive
operations on its own.
Destroying data is the only way in which Mercurial might require you
to use clones.
Daniel.
2010/7/12 Daniel Carrera <dcar...@gmail.com>:
Tony Mechelynck
> I'd like to make a public correction:
>
> An important design feature of Mercurial is that it will never delete
> or overwrite a revlog out of concern for data safety. Therefore, the
> only way to perform a "destructive" operation in Hg (e.g. delete a
> branch) is to use clones. The only exception is rollback - this is the
> only Hg command capable of losing data.
>
> This is an interesting design decision, and it points to a difference
> between Git and Hg: If you *want* to destroy data, Hg does require
> you to use clones. Whereas Git is willing to perform destructive
> operations on its own.
>
> Destroying data is the only way in which Mercurial might require you
> to use clones.
>
> Daniel.
There are, however, extensions (among which rebase, mq, transplant IIRC)
which will rewrite your history (as a result of a specific command); but
hg will never rewrite history on its own indeed: the base idea remains
that Mercurial history is cast in bronze.
Best regards,
Tony.
--
MONK: ... and the Lord spake, saying, "First shalt thou take out the
Holy Pin,
then shalt thou count to three, no more, no less. Three shalt be the
number thou shalt count, and the number of the counting shalt be
three.
Four shalt thou not count, neither count thou two, excepting that
thou
then proceed to three. Five is right out. Once the number
three, being
the third number, be reached, then lobbest thou thy Holy Hand
Grenade of
Antioch towards thou foe, who being naughty in my sight, shall
snuff it.
"Monty Python and the Holy Grail" PYTHON (MONTY)
PICTURES LTD
Daniel Carrera
<antoine.m...@gmail.com> wrote:
> There are, however, extensions (among which rebase, mq, transplant IIRC)
> which will rewrite your history (as a result of a specific command); but hg
> will never rewrite history on its own indeed: the base idea remains that
> Mercurial history is cast in bronze.
MQ and transplant do not destroy anything. MQ manages patches outside
of history, and transplants lets you cherry pick a patch from another
branch and apply it to this branch. Neither of these is a destructive
operation, and neither carries the risk of losing data.
I don't know how Hg rebase works. I would be interested to know if it
overwrites the revlog or not. It need not be destructive, it depends
on how it is implemented. For example, suppose you have:
E -> F
/
A -> B
\
C -> D
If you want to rebase E+F so that they come after D, you do not
necessarily have to destroy E and F. You could just keep them in
history and close the branch:
E -> F -> close
/
A -> B
\
C -> D -> E' -> F'
This would be a non-destructive way to implement Rebase, and probably
a more natural way to implement it in Hg. I wonder if this is what Hg
Rebase actually does.
Daniel.
--
No trees were killed in the generation of this message. A large number
of electrons were, however, severely inconvenienced.
Mads Kiilerich
> On Mon, Jul 12, 2010 at 3:13 PM, Tony Mechelynck
> <antoine.m...@gmail.com> wrote:
>> There are, however, extensions (among which rebase, mq, transplant IIRC)
>> which will rewrite your history (as a result of a specific command); but hg
>> will never rewrite history on its own indeed: the base idea remains that
>> Mercurial history is cast in bronze.
>
> MQ and transplant do not destroy anything.
That is usually true.
> MQ manages patches outside
> of history, and transplants lets you cherry pick a patch from another
> branch and apply it to this branch. Neither of these is a destructive
> operation, and neither carries the risk of losing data.
That is not true.
Core Mercurial is append-only and thus as safe as anything on a computer
can be.
MQ (which isn't a part of core Mercurial) strips revisions from the
repository and thus circumvents the usual safe-by-design guarantee. MQ
is a very powerful tool but it can be dangerous.
/Mads
Dan Villiom Podlaski Christiansen
On 12 Jul 2010, at 15:47, Daniel Carrera wrote:
> On Mon, Jul 12, 2010 at 3:13 PM, Tony Mechelynck
> <antoine.m...@gmail.com> wrote:
>> There are, however, extensions (among which rebase, mq, transplant IIRC)
>> which will rewrite your history (as a result of a specific command); but hg
>> will never rewrite history on its own indeed: the base idea remains that
>> Mercurial history is cast in bronze.
>
> MQ and transplant do not destroy anything. MQ manages patches outside
> of history, and transplants lets you cherry pick a patch from another
> branch and apply it to this branch. Neither of these is a destructive
> operation, and neither carries the risk of losing data.
This is not entirely accurate. Thanks to the wonders of the ‘qimport’ command and its -r/--rev option, you can use MQ to modify, reorder or destroy regular changesets. For example:
hg qimport -r tip -n tip.diff
hg qpop
hg qdel tip.diff
--
Dan Villiom Podlaski Christiansen
dan...@gmail.com
Bill Barry
On 2010-07-12, at 10:16 , Daniel Carrera wrote:On Mon, Jul 12, 2010 at 9:47 AM, Masklinn <mask...@masklinn.net> wrote:FWIW neither does it in git, fundamentally, and you can get at the "lost" commits via the reflog....until the next garbage collection.Actually, that's not the case. I had the same misconception but reflog is only pruned after a set time limit (or explicitly via git reflog expire, which end users pretty much never call). git gc calls expire with the standard/configured expiration time (it defaults to 90 days, or 30 days for unreachable objects). They can be configured via gc.reflogExpire and gc.reflogExpireUnreachable.
example:
User A clones repo from github and deletes some portion of history. User B clones the repo from A's machine. Does the repo have the bits that A deleted so they may be undeleted (or must B pull from github to get them back, or if he pulls from github what happens)?
Daniel Carrera
> MQ (which isn't a part of core Mercurial) strips revisions from the
> repository and thus circumvents the usual safe-by-design guarantee. MQ is a
> very powerful tool but it can be dangerous.
Wait... MQ works by saving stuff to the revlog and then mucking about
with the revlog? Yikes!
--
No trees were killed in the generation of this message. A large number
of electrons were, however, severely inconvenienced.
Masklinn
> Is this the case even for remote clones?
>
> example:
> User A clones repo from github and deletes some portion of history. User B clones the repo from A's machine. Does the repo have the bits that A deleted so they may be undeleted
So commits which are not reachable from a tag or branch should not be pullable or pushable
> (or must B pull from github to get them back, or if he pulls from github what happens)?
Git is a bit different from hg in that regard, in that it's entirely built with the idea of multiple remote repositories. So to pull, you first add a remote (a remote repository) then fetch from it. This will not create "local" branches, it will actually create *remote* branches (stored locally, in the refs/remotes namespace and generally immutable).
From these remote branches the user can create whatever remote-tracking branches (a local branch which will follow the remote branch on pull) or non-tracking branches he wants, local branches don't have to have the same name as remote ones (so I could track remotes/origin/master[1] through a local branch called "penguin", and I could track remotes/bbarry/master through a local branch called "ostrich"[2]).
The result is that B would have remotes/origin/master pointing to the github repository and remotes/A/master pointing to A's repo (which at this point would be origin/master minus a bunch of commits) and would be free to use either, or both using different tracking branches.
I believe hg has a much stronger integration between remote repositories and local branches.
[1] `origin` is the default remote name, when using `git clone <repository>`, <repository> will be setup as the origin remote unless it's overridden with -o. Think of it as hg's `default` path. `master` is the default branch, it's equivalent to hg's `default`.
[2] we're of course collaborating on the most amazing omelette recipe ever, the original recipe creator hates penguins with a passion so his recipe calls for penguin eggs, but you're a firm believer that "less is more" so your recipe uses a single ostrich egg as that's enough to make an omelette for 14.
Martin Geisler
I'm sending this back on the mailinglist -- please remember to send your
reply there as well.
>> The Definitive Guide to Mercurial promotes this way of working, but
>> it is not your only option. It is important to realize that Mercurial
>> has always supported *multiple light-weight branches* within a single
>> repository.
>>
>> Many blog posts describe this as a Git-only feature and fail to
>> realize that Mercurial supports it too.
>
> The first post requested "branches that can be also removed without
> traces". Do you mean that can be done within a single Mercurial
> repository, with no extension? Please explain me how or point me to
> some reference.
Mercurial lets you build your history graph in whatever shape you like.
When you have a graph, you can use 'hg clone -r R' to obtain the subset
of the graph that lead to revision R.
This can be used to remove a feature branch by cloning the other heads:
you can repeat the -r option as needed or you can use 'hg pull -r'
afterwards to bring in the changesets you want.
Whether it is practical to remove a branch does not depend on whether
you use clones or not. Clones can always be combined into single
repository, and such a combined repository can be split into separate
clones again.
Removing a branch only depends on how widely it has been published. When
using clones, you can delete the clones and ask others to do the same,
when using in-repository light-weight branches, you can ask people to
clone away the unneeded heads.
Deleting a clone is of course considered much easier than deleting a
head and the error message people get when they try to continue work on
a deleted branch is different -- when you delete a central clone they
are told
abort: no suitable response from remote hg!
whereas they are merely told that
abort: push creates new remote heads!
if their branch has disappeared from the central repository.