Re: [fossil-users] Bookmarks (Re: git-fossil-git does not, obtain the same commit hashes.)
On 6/5/2014 1:20 AM, Richard Hipp d...@sqlite.org wrote:
On Wed, Jun 4, 2014 at 12:53 PM, B Harderbrad.har...@gmail.com wrote:
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?
Mercurial supports a history querying feature they call revsets, or
revision sets. I don't often use it, but people on the Hg mailing list
have provided useful suggestions when users ask how to get some specific
changeset(s) data for reports.
From what I've seen, it's usable even on the search box available in
Mercurial's web interface (hg serve).
http://www.selenic.com/hg/help/revsets
Here's an admittedly simple example:
$ hg log -r branch(default) and date('2014-04-07') and
file('mercurial/merge.py')
changeset: 21082:0d67fccc0d43
user:Mads Kiilerich mad...@unity3d.com
date:Mon Apr 07 02:12:28 2014 +0200
summary: merge: let manifestmerge emit 'keep' actions when keeping
wd version
IIRC, there are options available in Git's git log command that will
allow querying like this as well (at least from what I've read briefly
in Git's HTML docs), but I'm no Git power user, either.
--Arnel
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Bookmarks (Re: git-fossil-git does not obtain the same commit hashes.)
On Wed, Jun 4, 2014 at 9:07 AM, Stephan Beal sgb...@googlemail.com wrote: On Wed, Jun 4, 2014 at 12:02 AM, Nico Williams n...@cryptonector.com wrote: 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 -- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Bookmarks (Re: git-fossil-git does not obtain the same commit hashes.)
On Wed, Jun 4, 2014 at 6:03 PM, Nico Williams n...@cryptonector.com wrote: On Wed, Jun 4, 2014 at 9:07 AM, Stephan Beal sgb...@googlemail.com wrote: On Wed, Jun 4, 2014 at 12:02 AM, Nico Williams n...@cryptonector.com wrote: 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 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 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Bookmarks (Re: git-fossil-git does not obtain the same commit hashes.)
On Wed, Jun 4, 2014 at 6:15 PM, Stephan Beal sgb...@googlemail.com wrote: f merge bk:trunk typo, but you get the idea. -- - 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 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Bookmarks (Re: git-fossil-git does not obtain the same commit hashes.)
On Wed, Jun 4, 2014 at 12:03 PM, Nico Williams n...@cryptonector.com wrote: On Wed, Jun 4, 2014 at 9:07 AM, Stephan Beal sgb...@googlemail.com wrote: On Wed, Jun 4, 2014 at 12:02 AM, Nico Williams n...@cryptonector.com wrote: 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 d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Bookmarks (Re: git-fossil-git does not obtain the same commit hashes.)
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 On 6/4/14, Richard Hipp d...@sqlite.org wrote: On Wed, Jun 4, 2014 at 12:03 PM, Nico Williams n...@cryptonector.com wrote: On Wed, Jun 4, 2014 at 9:07 AM, Stephan Beal sgb...@googlemail.com wrote: On Wed, Jun 4, 2014 at 12:02 AM, Nico Williams n...@cryptonector.com wrote: 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 d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Bookmarks (Re: git-fossil-git does not obtain the same commit hashes.)
On Wed, Jun 4, 2014 at 12:53 PM, B Harder brad.har...@gmail.com wrote: 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? -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Bookmarks (Re: git-fossil-git does not obtain the same commit hashes.)
On Wed, Jun 4, 2014 at 6:53 PM, B Harder brad.har...@gmail.com wrote: 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 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Bookmarks (Re: git-fossil-git does not obtain the same commit hashes.)
On Wed, Jun 4, 2014 at 7:02 PM, Richard Hipp d...@sqlite.org wrote: On Wed, Jun 4, 2014 at 12:53 PM, B Harder brad.har...@gmail.com wrote: 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 existed on some historical date, you could type: 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. -- - 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 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Bookmarks (Re: git-fossil-git does not obtain the same commit hashes.)
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: 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 On 6/4/14, Stephan Beal sgb...@googlemail.com wrote: On Wed, Jun 4, 2014 at 6:53 PM, B Harder brad.har...@gmail.com wrote: 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 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Bookmarks (Re: git-fossil-git does not obtain the same commit hashes.)
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 On 6/4/14, B Harder brad.har...@gmail.com wrote: 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: 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 On 6/4/14, Stephan Beal sgb...@googlemail.com wrote: On Wed, Jun 4, 2014 at 6:53 PM, B Harder brad.har...@gmail.com wrote: 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 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Bookmarks (Re: git-fossil-git does not obtain the same commit hashes.)
On Wed, Jun 4, 2014 at 7:21 PM, B Harder brad.har...@gmail.com wrote: 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 ;). -- - 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 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Bookmarks (Re: git-fossil-git does not obtain the same commit hashes.)
On Wed, Jun 4, 2014 at 11:15 AM, Stephan Beal sgb...@googlemail.com wrote: On Wed, Jun 4, 2014 at 6:03 PM, Nico Williams n...@cryptonector.com wrote: On Wed, Jun 4, 2014 at 9:07 AM, Stephan Beal sgb...@googlemail.com wrote: Bookmarks. That's a nice idea, actually. Added to my TODO list. 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.: 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 -- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Bookmarks (Re: git-fossil-git does not obtain the same commit hashes.)
On Wed, Jun 4, 2014 at 7:25 PM, Nico Williams n...@cryptonector.com wrote: 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.) -- - 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 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Bookmarks (Re: git-fossil-git does not obtain the same commit hashes.)
On Wed, Jun 4, 2014 at 11:53 AM, B Harder brad.har...@gmail.com wrote: 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 -- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Bookmarks (Re: git-fossil-git does not obtain the same commit hashes.)
On Wed, Jun 4, 2014 at 12:24 PM, Stephan Beal sgb...@googlemail.com wrote: 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. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Bookmarks (Re: git-fossil-git does not obtain the same commit hashes.)
On Wed, Jun 4, 2014 at 12:30 PM, Stephan Beal sgb...@googlemail.com wrote: On Wed, Jun 4, 2014 at 7:25 PM, Nico Williams n...@cryptonector.com wrote: 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 -- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Bookmarks (Re: git-fossil-git does not obtain the same commit hashes.)
On Wed, Jun 4, 2014 at 8:07 PM, Nico Williams n...@cryptonector.com wrote: - 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. -- - 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 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Bookmarks (Re: git-fossil-git does not obtain the same commit hashes.)
On Wed, Jun 4, 2014 at 2:07 PM, Nico Williams n...@cryptonector.com wrote: On Wed, Jun 4, 2014 at 12:30 PM, Stephan Beal sgb...@googlemail.com wrote: On Wed, Jun 4, 2014 at 7:25 PM, Nico Williams n...@cryptonector.com wrote: 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 Like a non-propagating tag. - 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. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Bookmarks (Re: git-fossil-git does not obtain the same commit hashes.)
Nico Williams wrote: On Wed, Jun 4, 2014 at 9:07 AM, Stephan Bealsgb...@googlemail.com wrote: On Wed, Jun 4, 2014 at 12:02 AM, Nico Williamsn...@cryptonector.com wrote: 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. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Bookmarks (Re: git-fossil-git does not obtain the same commit hashes.)
Scott Robison wrote: On Wed, Jun 4, 2014 at 12:56 PM, Joel Bruick j...@joelface.com mailto:j...@joelface.com wrote: 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? :) Consider it yours. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Bookmarks (Re: git-fossil-git does not obtain the same commit hashes.)
On Wed, Jun 4, 2014 at 1:29 PM, Joel Bruick j...@joelface.com wrote: 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! :) -- Scott Robison ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Bookmarks (Re: git-fossil-git does not obtain the same commit hashes.)
On Wed, Jun 4, 2014 at 1:56 PM, Richard Hipp d...@sqlite.org wrote: On Wed, Jun 4, 2014 at 3:27 PM, Scott Robison sc...@casaderobison.com wrote: 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! Does that quote belong on this page: 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 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Bookmarks (Re: git-fossil-git does not obtain the same commit hashes.)
Scott Robison wrote: On Wed, Jun 4, 2014 at 1:56 PM, Richard Hipp d...@sqlite.org mailto:d...@sqlite.org wrote: On Wed, Jun 4, 2014 at 3:27 PM, Scott Robison sc...@casaderobison.com mailto:sc...@casaderobison.com wrote: 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! Does that quote belong on this page: 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. :) I'd prefer the attribution Joel Bruick, blatantly biased Fossil contributor, but sure, why not? ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
