[fossil-users] Bookmarks (Re: git->fossil->git does not obtain the same commit hashes.)

[Nico Williams]

Mercurial too had "heavy-duty" branches only, then they added
"bookmarks" that are very similar to git branches. Since a "bookmark"
is just a symbolic name for a commit... this is just a new table at
best, with two columns.

Bookmarks. That's a nice idea, actually. Added to my TODO list.

It's interesting that I just sold you on the git branching model, by
using the Mercurial analog.

I don't know what that says. To me any heavy-duty branching model is
difficult to explain, but clearly bookmarks are easy to explain, or at
least easier to explain when you start from a heavy-duty branching
model. Regardless of what it means, it's good! :)

You might find that it helps to have boomarks and something like
"detached HEAD mode". Detached HEAD mode is a fancy name for
"checking out a commit (or adding one to a detached HEAD) that may not
be reachable from a branch name / bookmark / tag". But it's not
critical. If checking out a commit requires giving it a name
(bookmark), that's annoying, but workable.

Nico
--

[Stephan Beal]

Post by Nico Williams

Mercurial too had "heavy-duty" branches only, then they added
"bookmarks" that are very similar to git branches. Since a "bookmark"
is just a symbolic name for a commit... this is just a new table at
best, with two columns.

Bookmarks. That's a nice idea, actually. Added to my TODO list.

It's interesting that I just sold you on the git branching model, by
using the Mercurial analog.

i was thinking more generically:

f bookmark add blah trunk
f bookmark add 'oops!' deadbeefabcdef0123

f bookmark ls
[blah] = trunk
[oops!] = deadbeefabcdef0123

f co bk:oops
f merge bk:trunk

i.e. a system with which to assign non-version-tracked aliases to arbitrary
other symbols which we already know how to resolve. They needn't be
push/pull'able, but it might be nice to be able to. We already have
precedents for "special symbols" like bk:NAME, e.g.:

fossil checkout rid:1

will (unless your repo was created with no empty initial commit) check out
the first version of the repo (i.e. (WHERE blob.rid = 1)).

[Stephan Beal]

Post by Stephan Beal
f merge bk:trunk

typo, but you get the idea.

[Nico Williams]

Post by Stephan Beal

Bookmarks. That's a nice idea, actually. Added to my TODO list.

f bookmark add blah trunk
f bookmark add 'oops!' deadbeefabcdef0123
f bookmark ls
[blah] = trunk
[oops!] = deadbeefabcdef0123
f co bk:oops
f merge bk:trunk
i.e. a system with which to assign non-version-tracked aliases to arbitrary
other symbols which we already know how to resolve. They needn't be
push/pull'able, but it might be nice to be able to. We already have

To be truly useful it has to be possible to [selectively] push/pull bookmarks.

Strictly speaking, bookmarks needn't be versioned, but it's nice to
have something like the git "reflog" to help you recover from
accidentally clobbering a bookmark. In effect, bookmarks' history
needs to be versioned, because let's face it, the git reflog is an odd
bolt-on thing, odder still when you consider that git has a powerful
history mechanism.

So, yeah, bookmarks should be versioned.

Nico
--

[Stephan Beal]

Post by Nico Williams
To be truly useful it has to be possible to [selectively] push/pull bookmarks.

If that's the case then they really provide no benefits over propagating
tags (which are versioned), but note that Fossil cannot selectively
push/pull with the exception of "private" branches (tags applied to them
are also private). Tags can, in principal, tag arbitrary repo content, but
historically they've only been applied to checkins. The mechanism allows,
e.g., us to tag individual content blobs, wiki pages, or even to tag other
tags, but so far we've never had any uses for such things. (i did tinker
with the idea of using tags-on-tags to implement comment threads, e.g. for
code reviews, but never got far enough to figure out if it would work.)

[Nico Williams]

Post by Stephan Beal

Post by Nico Williams
To be truly useful it has to be possible to [selectively] push/pull bookmarks.

If that's the case then they really provide no benefits over propagating
tags (which are versioned), but note that Fossil cannot selectively

See my notes about the differences between tags and branches in git,
the most important of which I'll repeat and expand on here:

- when you checkout a tag and then commit something, the tag doesn't
move with the HEAD of your workspace -- you're in detached HEAD mode
when you checkout a tag

- when you checkout a branch and you commit something, the branch's
HEAD moves with the HEAD of your workspace.

E.g.,

% git clone somerepo myclone
% cd myclone
% git tag
<list of tags; pick one>
% git checkout footag
Note: checking out 'footag'.

You are in 'detached HEAD' state. [...]
...
% date > f
% git add f
% git commit -m "example"
% git show HEAD
<the commit we just did>
% git show footag
<the commit we were on before>

Now branches:

% git checkout master
% date > f
% git add f
% git commit -m "another example"
% git status -uno
# On branch master
nothing to commit (use -u to show untracked files)
% git show HEAD
<the commit we just added>

See? Tags are precious: they are for noting releases and such, so
mostly they are not intended to be modified. Branches are intended
for ongoing development, so adding a commit with a given branch
checked out moves that branch's HEAD.

Nico
--

[Stephan Beal]

Post by Nico Williams
- when you checkout a tag and then commit something, the tag doesn't
move with the HEAD of your workspace -- you're in detached HEAD mode
when you checkout a tag
- when you checkout a branch and you commit something, the branch's
HEAD moves with the HEAD of your workspace.

fossil supports both propagating and non-propagating tags, with propagating
tags being used primarily (but not solely) for branches.

[Richard Hipp]

Post by Nico Williams

Post by Stephan Beal

Post by Nico Williams
To be truly useful it has to be possible to [selectively] push/pull bookmarks.

If that's the case then they really provide no benefits over propagating
tags (which are versioned), but note that Fossil cannot selectively

See my notes about the differences between tags and branches in git,
- when you checkout a tag and then commit something, the tag doesn't
move with the HEAD of your workspace -- you're in detached HEAD mode
when you checkout a tag

Like a non-propagating tag.

Post by Nico Williams
- when you checkout a branch and you commit something, the branch's
HEAD moves with the HEAD of your workspace.

Like a propagating tag.

So what extra do you get from the Git approach? I mean other than having a
separate "detached HEAD mode" which behaves differently from normal
operation and might leave you with orphaned check-ins that get purged
during a cleanup?

So right now in the SQLite repository, the latest check-in has three
separate tags:

"version-3.8.5" is a unique non-propagating tag. Whenever you do "fossil
co version-3.8.5" you always get that particular check-in.

"release" is a non-unique non-propagating tag. Whenever you do "fossil co
release" you get the most recent release.

"trunk" is a propagating tag. Whenever you do "fossil co trunk" you get
the latest check-in on the trunk branch.

If you were to check-in a new change, the change would inherit only the
"trunk" tag, not the "version-3.8.5" nor "release" tags.

[Richard Hipp]

Post by Nico Williams

Mercurial too had "heavy-duty" branches only, then they added
"bookmarks" that are very similar to git branches. Since a "bookmark"
is just a symbolic name for a commit... this is just a new table at
best, with two columns.

Bookmarks. That's a nice idea, actually. Added to my TODO list.

It's interesting that I just sold you on the git branching model, by
using the Mercurial analog.

The Fossil and Git branching model are already the same, with the one
exception that branch names in Fossil are global (they sync to other
repositories) whereas in Git they are local to a single repository.

Fossil also has something analogous to "bookmarks" - namely propagating
tags. You set a tag on a particular check-in, and that tag is
automatically added to all direct descendents. When you can check-out that
"tag" and Fossil selects the most recent, which is the same thing as a
bookmark that automatically moves to the head of the branch.

[B Harder]

Indeed, non-propagating tags are also "checkout-able" items.

What am I missing about bookmarks that we can't already enjoy w/ tags,
outside of new syntax ?

-bch

Post by Richard Hipp

Post by Nico Williams

Mercurial too had "heavy-duty" branches only, then they added
"bookmarks" that are very similar to git branches. Since a "bookmark"
is just a symbolic name for a commit... this is just a new table at
best, with two columns.

Bookmarks. That's a nice idea, actually. Added to my TODO list.

It's interesting that I just sold you on the git branching model, by
using the Mercurial analog.

The Fossil and Git branching model are already the same, with the one
exception that branch names in Fossil are global (they sync to other
repositories) whereas in Git they are local to a single repository.
Fossil also has something analogous to "bookmarks" - namely propagating
tags. You set a tag on a particular check-in, and that tag is
automatically added to all direct descendents. When you can check-out that
"tag" and Fossil selects the most recent, which is the same thing as a
bookmark that automatically moves to the head of the branch.
--
D. Richard Hipp

[Richard Hipp]

Post by B Harder
Indeed, non-propagating tags are also "checkout-able" items.
What am I missing about bookmarks that we can't already enjoy w/ tags,
outside of new syntax ?

Here's something that you get for free with Fossil's model that you can't
get with Hg or Git (as far as I know): the ability to look at historic
versions on particular branches as of some point in time using the
"<branchname>:<datetime>" construct. So, for example, the current Fossil
homepage can be seen at:

http://www.fossil-scm.org/fossil/doc/tip/www/index.wiki

The "tip" in that URL is a magic tag that means the most recent check-in.
What did the homepage look like on the head of the "trunk" branch at the
beginning of 2012?

http://www.fossil-scm.org/fossil/doc/trunk:2012-01-01/www/index.wiki

Similarly, if you wanted to checkout the branch "experimental" as it
existed on some historical date, you could type:

fossil co experimental:2011-06-04

I personally use that capability all the time when trying to find the
initial bounds on a bug in order to begin a bisect, or when doing things
like comparing performance of SQLite to one or five years ago. Question:
Is anything like this even possible in Git and/or Hg?

[Stephan Beal]

Post by Richard Hipp

Post by B Harder
Indeed, non-propagating tags are also "checkout-able" items.
What am I missing about bookmarks that we can't already enjoy w/ tags,
outside of new syntax ?

Similarly, if you wanted to checkout the branch "experimental" as it
fossil co experimental:2011-06-04

@Brad: Richard just gave us an example:

fossil bk add xp experimental:2011-06-04

i honestly can't imagine it being useful all that often, but it sounds
interesting.

[Nico Williams]

Post by Richard Hipp

Post by B Harder
Indeed, non-propagating tags are also "checkout-able" items.
What am I missing about bookmarks that we can't already enjoy w/ tags,
outside of new syntax ?

Here's something that you get for free with Fossil's model that you can't
get with Hg or Git (as far as I know): the ability to look at historic
versions on particular branches as of some point in time using the
"<branchname>:<datetime>" construct. So, for example, the current Fossil

In git, as long as a branch's HEAD moves linearly, you get the same effect.

A rebase, in git, ends up doing a non-linear move of the HEAD of the
branch being rebased. (Keep in mind that though I advocate rebase as
a feature, I wouldn't mind if rebase -> new branch, leaving the old
untouched.)

Now, git doesn't track the history of a branch-as-bookmark's
non-linear moves, except in the "reflog".

So in git, if I do this:

% git checkout foo
% git rebase -i master
<interactive rebase>
%
% echo "hmm, no! I don't like what I did!"

you've moved 'foo' and you can't get back what it used to be except by
doing this:

% git reflog
<scan it looking for foo's previous HEAD commit>
%
% # Delete and re-create foo as it was:
% git branch -D foo
% git branch foo <foo's previous HEAD commit>

The reflog is a very hacky thing! Very useful too. Very, very
useful, and not just for this. It's a place where git records all the
checkout and other operations, so you can see what you've been doing.

But as a recovery-from-bad-rebase tool, the reflog is a poor-man's
versioning tool.

Post by Richard Hipp
I personally use that capability all the time when trying to find the
initial bounds on a bug in order to begin a bisect, or when doing things
Is anything like this even possible in Git and/or Hg?

[git] Well, for branches that move linearly -which public branches
do-, yes. For branches subject to rebase... no, not unless one puts
"version numbers" in branch names. (Reflogs are purely local, so
there's no way to examine a remote's reflog to see if a remote branch
ever moved non-linearly.)

[hg] Branches move linearly, so, yes. Bookmarks are like git
branches, so same answer as for git.

I completely agree that the problem with these light-weight branch
(git) / bookmark (hg) concepts is the lack of public history about
past non-linear moves.

But remember: public branches should never get rebased, they should
only ever move linearly into the future, so it's not important to keep
history about non-linear move in public repos. This is why the reflog
is good enough (if hacky) in the git case.

Nico
--

[Stephan Beal]

Post by B Harder
Indeed, non-propagating tags are also "checkout-able" items.
What am I missing about bookmarks that we can't already enjoy w/ tags,
outside of new syntax ?

i envision them as being "lightweight," i.e. local, non-versioned. They'd
just be local aliases, in effect, to arbitrary other symbolic names.

[B Harder]

Because the internet can be a poor medium to express emotional intent,
let me preface this with: Stephan, you know I have the utmost respect
for your coding chops, and we _mostly_ fall in line wrt design
philosophy. That said:

I'm shaking my head, wondering "why?" My current mental image is:
Loading Image...

Is there an important, long-lived reason why we'd want this baked into
fossil? Maybe this deserves to live as a tool that happens to be
intimately familiar w/ fossil. Ie: a script that maps "bookmarks" with
the real UUID, and runs 'exec ("fossil co $UUID");'.

-bch

Post by Stephan Beal

Post by B Harder
Indeed, non-propagating tags are also "checkout-able" items.
What am I missing about bookmarks that we can't already enjoy w/ tags,
outside of new syntax ?

i envision them as being "lightweight," i.e. local, non-versioned. They'd
just be local aliases, in effect, to arbitrary other symbolic names.
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf

[Stephan Beal]

Post by B Harder
http://perl-begin.org/humour/perl6_perl_6_cover_lg.jpg

Reminds me of the on-on-on-oh-so-nausiatingly-ongoing JSON standardization
efforts on the IETF mailing lists ;). But yeah, i get your point.

Is there an important, long-lived reason why we'd want this baked into

Post by B Harder
fossil? Maybe this deserves to live as a tool that happens to be
intimately familiar w/ fossil. Ie: a script that maps "bookmarks" with
the real UUID, and runs 'exec ("fossil co $UUID");'.

No compelling reason - it was just an idea spawned by something Nico said.
i can't really think of a use for it, but may play with the idea in
libfossil and see if there's anything useful we can do with it. So far,
nothing interesting comes to mind.

[B Harder]

sb> fossil bk add xp experimental:2011-06-04

I can imagine this being useful at least occasionally. I'm still
loathe to include it in core fossil, but it'd be a great task for a
little tool.

-bch

Post by B Harder
Because the internet can be a poor medium to express emotional intent,
let me preface this with: Stephan, you know I have the utmost respect
for your coding chops, and we _mostly_ fall in line wrt design
http://perl-begin.org/humour/perl6_perl_6_cover_lg.jpg
Is there an important, long-lived reason why we'd want this baked into
fossil? Maybe this deserves to live as a tool that happens to be
intimately familiar w/ fossil. Ie: a script that maps "bookmarks" with
the real UUID, and runs 'exec ("fossil co $UUID");'.
-bch

Post by Stephan Beal

Post by B Harder
Indeed, non-propagating tags are also "checkout-able" items.
What am I missing about bookmarks that we can't already enjoy w/ tags,
outside of new syntax ?

i envision them as being "lightweight," i.e. local, non-versioned. They'd
just be local aliases, in effect, to arbitrary other symbolic names.
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf

[Stephan Beal]

Post by B Harder
sb> fossil bk add xp experimental:2011-06-04
I can imagine this being useful at least occasionally. I'm still
loathe to include it in core fossil, but it'd be a great task for a
little tool.

In the core, basically the only addition would be adding another block to
symbolic_name_to_rid(), which simply expands the "..." part from "bk:..."
from the bookmark list, then runs that result through through
symbolic_name_to_rid(). That would allow all other APIs to inherently
resolve bookmarks (or "aliases" might be a better name).

But until i can think of something interesting to do with it, i'm not
touching any code ;).

[Nico Williams]

Post by Stephan Beal
In the core, basically the only addition would be adding another block to
symbolic_name_to_rid(), which simply expands the "..." part from "bk:..."
from the bookmark list, then runs that result through through
symbolic_name_to_rid(). That would allow all other APIs to inherently
resolve bookmarks (or "aliases" might be a better name).

Right, a light-weight bookmark need to be referenceable as a symbolic
name of a commit just as any tag or branch. That's what Mercurial
does, FYI.

[Nico Williams]

Post by B Harder
Indeed, non-propagating tags are also "checkout-able" items.
What am I missing about bookmarks that we can't already enjoy w/ tags,
outside of new syntax ?

In git, tags and branches are both very light-weight bookmark-like concepts.

The differences are as follows:

- both can be pushed/pulled, but tags have a single global namespace
- while branches are namespaced by a remote repo name

- when you checkout a branch and then commit something, you
automatically move the branch to point to the new commit as its HEAD

- when you checkout a tag you're in "detached HEAD mode"; adding a
commit leaves you in the same mode -- the tag doesn't "move" or change

Nico
--

[Joel Bruick]

Post by Nico Williams

Mercurial too had "heavy-duty" branches only, then they added
"bookmarks" that are very similar to git branches. Since a "bookmark"
is just a symbolic name for a commit... this is just a new table at
best, with two columns.

Bookmarks. That's a nice idea, actually. Added to my TODO list.

It's interesting that I just sold you on the git branching model, by
using the Mercurial analog.
I don't know what that says. To me any heavy-duty branching model is
difficult to explain, but clearly bookmarks are easy to explain, or at
least easier to explain when you start from a heavy-duty branching
model. Regardless of what it means, it's good! :)

I think Git is a great, powerful, and flexible tool that actually has a
much simpler design than it initially appears. But to get to a place
where you actually understand that design (and, thus, understand Git),
takes about 99x more effort than 99% of the software I've ever used.

Once you get to that point, though, it's wonderful! ;)

One serious problem I have with Git's branching model, though, is that
the branch names don't really name branches.

If I want to go back and dig through the history of an old "feature-x"
branch, I get the commit that the feature-x ref is currently pointing to
along with every other ancestor of that commit -- including every
ancestor of the commit that feature-x branched out of and the ancestry
of every other commit that's been merged into the feature-x branch.

Well, okay, but that's not really what reasonable human beings
conceptualize as a branch.

This is, of course, assuming that the "feature-x" ref still exists. In
Git, it is common practice for people to delete a ref (even from the
remote repository) after the branch has been merged. To me, this really
does amount to deleting history.

Fossil branches are actual branches, and I find this very helpful. As an
example, I fairly often find myself wanting to look back at a specific
commit that I remember. I obviously don't have the artifact ID
memorized. I only vaguely remember when it was created. While the
commit message was clear and descriptive, I don't remember it, and
searching for keywords that I think appear in it returns nothing. If I
could go back in time, I would give it a tag. But heck, even Git doesn't
include a time machine yet.

However, I do remember the branch name (and even if I don't, I can
easily find it in the list of closed branches). Firing up "fossil ui"
and going to /timeline?r=feature-x narrows it down to a handful of commits.

Anyway, there are some things that I wouldn't mind if Fossil stole from
Git, but the branching model is not one of them.

[Scott Robison]

Post by Joel Bruick
I think Git is a great, powerful, and flexible tool that actually has a
much simpler design than it initially appears. But to get to a place where
you actually understand that design (and, thus, understand Git), takes
about 99x more effort than 99% of the software I've ever used.
Once you get to that point, though, it's wonderful! ;)

I really want to steal this in tweet form:

"To get to a place where you understand Git's design takes 99x more effort
than 99% of software. Once you get to that point it's wonderful!"

Would you mind? :)

[Joel Bruick]

Post by Joel Bruick
I think Git is a great, powerful, and flexible tool that actually
has a much simpler design than it initially appears. But to get to
a place where you actually understand that design (and, thus,
understand Git), takes about 99x more effort than 99% of the
software I've ever used.
Once you get to that point, though, it's wonderful! ;)
"To get to a place where you understand Git's design takes 99x more
effort than 99% of software. Once you get to that point it's wonderful!"
Would you mind? :)

Consider it yours.

[Scott Robison]

Post by Joel Bruick
Consider it yours.

Thanks. Final form:

OH: To understand Git's design takes 99x more effort than 99% of software.
Once you get to that point it's wonderful! // Too true!

Curse the 140 character limit! :)

[Richard Hipp]

Post by Scott Robison
"To get to a place where you understand Git's design takes 99x more effort
than 99% of software. Once you get to that point it's wonderful!"

Does that quote belong on this page:
http://www.fossil-scm.org/fossil/doc/tip/www/quotes.wiki

[Scott Robison]

Post by Richard Hipp

Post by Scott Robison
"To get to a place where you understand Git's design takes 99x more
effort than 99% of software. Once you get to that point it's wonderful!"

http://www.fossil-scm.org/fossil/doc/tip/www/quotes.wiki

The full original definitely belongs there:

I think Git is a great, powerful, and flexible tool that actually has a
much simpler design than it initially appears. But to get to a place where
you actually understand that design (and, thus, understand Git), takes
about 99x more effort than 99% of the software I've ever used.

Once you get to that point, though, it's wonderful! ;)

Attributed to Joel Bruick. :)


SDR

[Joel Bruick]

On Wed, Jun 4, 2014 at 3:27 PM, Scott Robison
"To get to a place where you understand Git's design takes 99x
more effort than 99% of software. Once you get to that point
it's wonderful!"
http://www.fossil-scm.org/fossil/doc/tip/www/quotes.wiki
I think Git is a great, powerful, and flexible tool that actually has
a much simpler design than it initially appears. But to get to a place
where you actually understand that design (and, thus, understand Git),
takes about 99x more effort than 99% of the software I've ever used.
Once you get to that point, though, it's wonderful! ;)
Attributed to Joel Bruick. :)

I'd prefer the attribution "Joel Bruick, blatantly biased Fossil
contributor," but sure, why not?