Re: [fossil-users] script-friendlier progress-indicator when cloning
On Wed, 04 Jun 2014 10:36:41 +0200, Michai Ramakers m.ramak...@gmail.com wrote: Hello, is there a way to make 'fossil clone' a bit less verbose for use in scripts? I am using clone to make a consistent temporary copy of a repo. Ideas are welcome, what about something like fossil clone url filename | awk '/^Repo/' or fossil clone url filename /dev/null #;-) Michai ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ 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] script-friendlier progress-indicator when cloning
right, something like that would work, I guess... Thanks, Michai On 4 June 2014 10:44, j. van den hoff veedeeh...@googlemail.com wrote: On Wed, 04 Jun 2014 10:36:41 +0200, Michai Ramakers m.ramak...@gmail.com wrote: Hello, is there a way to make 'fossil clone' a bit less verbose for use in scripts? I am using clone to make a consistent temporary copy of a repo. Ideas are welcome, what about something like fossil clone url filename | awk '/^Repo/' or fossil clone url filename /dev/null #;-) Michai ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ 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] Question regarding ancestors and Q-card relations.
On Wed, Jun 4, 2014 at 12:07 AM, Andy Bradford amb-fos...@bradfords.org wrote: Thus said Andy Bradford on Tue, 03 Jun 2014 21:59:21 -0600: Does the Q-card here not imply any relation with c14a4a93d5a3 which will be picked up in trunk? It seems I did not understand this very well: A Q-card is similar to a P-card in that it defines a predecessor to the current check-in. But whereas a P-card defines the immediate ancestor or a merge ancestor, the Q-card is used to identify a single check-in or a small range of check-ins which were cherry-picked for inclusion in or exclusion from the current manifest. Which I suppose means that there is no ancestral relationship. Right. Q-cards are informational only and are not used by merge logic, or currently for any other purpose. At some point it would be nice to show cherry-pick lines in the timeline graph, and for that the Q-cards will be used. $ fossil merge c14a4a MERGE file fossil undo is available to undo changes to the working checkout. Should a merge in this case result in a conflict? Or is it correct to merge in the content a second time? Or should it recognize that the Q-card UUID and the UUID of the version being merged in are the same and include a warning or even error? The merge logic in Fossil recognizes when the same exact change is merged more than once and avoids conflicts in that case. The Q-cards are not necessary for this. -- 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
[fossil-users] diff file in checkout against its previous version
Hello, perhaps a quick question: is it possible to diff a file in the current checkout against a previous version of itself, regardless of how long ago the last change occurred? (diff --from prev --to current does not always work, in case the file was changed some checkins ago) Of course using hashes as from-revision work, but perhaps there's an easier way. Thanks, Michai ___ 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] diff file in checkout against its previous version
On 4 June 2014 15:12, Richard Hipp d...@sqlite.org wrote: On Wed, Jun 4, 2014 at 9:05 AM, Michai Ramakers m.ramak...@gmail.com wrote: Hello, perhaps a quick question: is it possible to diff a file in the current checkout against a previous version of itself, regardless of how long ago the last change occurred? You can view the complete change-history of a file in the UI. For example: http://www.fossil-scm.org/fossil/finfo?name=src/diff.c And on the timeline of that display, you can click on any to boxes to get a diff between any two historical versions of the file. Ah, that I knew. I should have mentioned: when using command-line. Michai ___ 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] diff file in checkout against its previous version
On Wed, Jun 4, 2014 at 9:21 AM, Michai Ramakers m.ramak...@gmail.com wrote: On 4 June 2014 15:12, Richard Hipp d...@sqlite.org wrote: On Wed, Jun 4, 2014 at 9:05 AM, Michai Ramakers m.ramak...@gmail.com wrote: Hello, perhaps a quick question: is it possible to diff a file in the current checkout against a previous version of itself, regardless of how long ago the last change occurred? You can view the complete change-history of a file in the UI. For example: http://www.fossil-scm.org/fossil/finfo?name=src/diff.c And on the timeline of that display, you can click on any to boxes to get a diff between any two historical versions of the file. Ah, that I knew. I should have mentioned: when using command-line. I don't recall implementing anything to do that from the command-line. But on the other hand, there is a lot of stuff in Fossil that others have implemented and a lot of stuff that I implemented but then forgot about. -- 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] diff file in checkout against its previous version
On Wed, Jun 4, 2014 at 3:24 PM, Richard Hipp d...@sqlite.org wrote:
I don't recall implementing anything to do that from the command-line.
But on the other hand, there is a lot of stuff in Fossil that others have
implemented and a lot of stuff that I implemented but then forgot about.
i don't recall a way, either, but here's a halfway ugly workaround if you
have the libfossil tools laying around:
f-adiff HASH1 HASH2
where HASH{1,2} are the sha1's of the two versions of your file. You can
get those using:
f-ls -v=VERSION --glob=*filename*
(oops: -v without a value inverts the --glob option - need to use a
different flag for that to avoid confusion)
Be sure to see the help for more options:
[stephan@host:~]$ f-adiff -?
Showing app-specific help only. Use the --global option in conjunction with
--help|-? to show framework-level options.
Usage:
f-adiff [options] fromArtifactUuid toArtifactUuid
Generates diff of individual blobs (not checkin versions!). Options:
--no-color|-bw Disables color output.
--context-lines|-c=### Specifies the number of context lines around
differences.
--html|-h Specifies HTML-format output, marked for styling via CSS.
--invert|-v Inverts the to/from arguments for diff purposes.
--sbs-width|-w=### specifies a side-by-side diff with the given column
width.
Results may be weird if specifying conflicting options (-i and -w).
The two versions to compare may be specified as non-flag arguments or via
the -v1=x and -v2=y flags.
--
- 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] diff file in checkout against its previous version
On 4 June 2014 15:51, Martin Gagnon eme...@gmail.com wrote: On Wed, Jun 04, 2014 at 03:21:10PM +0200, Michai Ramakers wrote: On 4 June 2014 15:12, Richard Hipp d...@sqlite.org wrote: On Wed, Jun 4, 2014 at 9:05 AM, Michai Ramakers m.ramak...@gmail.com wrote: Hello, perhaps a quick question: is it possible to diff a file in the current checkout against a previous version of itself, regardless of how long ago the last change occurred? You can view the complete change-history of a file in the UI. For example: http://www.fossil-scm.org/fossil/finfo?name=src/diff.c And on the timeline of that display, you can click on any to boxes to get a diff between any two historical versions of the file. Ah, that I knew. I should have mentioned: when using command-line. For myself, I do it that way using regular fossil command line: fossil finfo foo.bar # double select and copy desired checkin hash to copy-paste buffer fossil diff --from paste hash here foo.bar Ok, thanks; that's basically what I do here too. Michai ___ 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] git-fossil-git does not obtain the same commit hashes.
On Wed, Jun 4, 2014 at 12:02 AM, Nico Williams n...@cryptonector.com wrote: You're mixing things up :) Rebase is just a script around new branch starting at given base, cherry-pick all the commits from the base to the head of what's being rebased. It's a script, literally. It can't break your repo. You're right, i'm confusing rebase and reset (and its --hard option). Thank you for so politely pointing that out :). 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. - if the index is not empty, then the user can't change branches - if the index is not empty, then commit should commit only what's in the index Neither of those seems to pose any problems, so long as the index isn't using the current versioning-related infrastructure (concretely: doesn't have any unique content which is referenced by other commits). This is certainly a use case i'll explore in libfossil (where i've got a bit more leeway in making changes). But it would provide a git-like staging area in that you would have one level of undo. And then another level of undo... and another, all the way [...] You misunderstand the index. It's not about undo. It's about capturing a subset of the extant deltas for committing. i've only ever used the index for (basically) an undo area, but you're right, that's probably not what most people use it for. In my mind the index is basically autosync=0, but of course that's a hugely oversimplified world view. The commit model in fossil is fundamentally based on the sha1 of the contents of the file. How do we get that without referencing the files? The index captures the content to be committed. i have some ideas about how this could be done. In libf it would be relatively straightforward, i think, because it allows the client more control over the source and destination of the content bytes. In fossil it would require more infrastructure, but probably not prohibitively much. It's like having a logical snapshot of the workspace set aside. You add things to the index (copy, if you like) from the workspace, then you commit what's in the index. The stash is similar, at least in principal, so there may already be a basis in place for something like this. If your index is empty and you commit, you get the same behavior as today. Sounds reasonable. Forget the backup/restore -- that's a different problem set. We're now on the subject of about allowing me to get the workflows I use with git, but with Fossil instead, and with minimal changes to Fossil. Give me the bare primitives I need, and I can build the rest as external components. Fair enough. i've just jotted down some ideas to play with, but i can't commit to any timeframe. Ideas on implementation strategies are of course welcomed! -- - 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
[fossil-users] anyone have a fossil binary for Android ARM9?
Hi, all! i just got an ODROID-U3 device and i'm now looking for a fossil binary... does one of you have a link to a Fossil binary for Android running on an ARM9 processor? ODroid: http://hardkernel.com/main/products/prdt_info.php Many thanks in advance! -- - 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] anyone have a fossil binary for Android ARM9?
On Wed, Jun 4, 2014 at 11:20 AM, Stephan Beal sgb...@googlemail.com wrote: Hi, all! i just got an ODROID-U3 device and i'm now looking for a fossil binary... does one of you have a link to a Fossil binary for Android running on an ARM9 processor? http://www.fossil-scm.org/fossil-beagle.gz compiled for BeagleBoard. -- 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] anyone have a fossil binary for Android ARM9?
On Wed, Jun 04, 2014 at 05:20:11PM +0200, Stephan Beal wrote: Hi, all! i just got an ODROID-U3 device and i'm now looking for a fossil binary... does one of you have a link to a Fossil binary for Android running on an ARM9 processor? ODroid: http://hardkernel.com/main/products/prdt_info.php Many thanks in advance! I have a linux arm-gnueabi binary (not specifically android). Since android use a linux kernel, it might work. (It's not armhf, but armle) Actually, it is running on that: http://www.embeddedarm.com/products/board-detail.php?product=TS-7800 which is ARM9. If you want to try, I can send it to you. (it run on 2 different arm platform that I use for now, with different kernel version and glibc version...) -- Martin G. ___ 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] anyone have a fossil binary for Android ARM9?
On Wed, Jun 4, 2014 at 5:30 PM, Richard Hipp d...@sqlite.org wrote: On Wed, Jun 4, 2014 at 11:20 AM, Stephan Beal sgb...@googlemail.com wrote: Hi, all! i just got an ODROID-U3 device and i'm now looking for a fossil binary... does one of you have a link to a Fossil binary for Android running on an ARM9 processor? http://www.fossil-scm.org/fossil-beagle.gz compiled for BeagleBoard. That's giving me a no data received response :-? (Chromium browser, if it makes a difference.) @Martin: if you would please mail me yours (or a link)? Maybe a shared GDrive folder would be easiest? -- - 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] anyone have a fossil binary for Android ARM9?
On Wed, Jun 04, 2014 at 05:37:21PM +0200, Stephan Beal wrote: On Wed, Jun 4, 2014 at 5:30 PM, Richard Hipp d...@sqlite.org wrote: On Wed, Jun 4, 2014 at 11:20 AM, Stephan Beal sgb...@googlemail.com wrote: Hi, all! i just got an ODROID-U3 device and i'm now looking for a fossil binary... does one of you have a link to a Fossil binary for Android running on an ARM9 processor? http://www.fossil-scm.org/fossil-beagle.gz compiled for BeagleBoard. That's giving me a no data received response :-? (Chromium browser, if it makes a difference.) @Martin: if you would please mail me yours (or a link)? Maybe a shared GDrive folder would be easiest? here it is: https://drive.google.com/file/d/0B_-jB7mK7jpXUUZKQW5vcEFnRkE/edit?usp=sharing Regards, -- Martin G. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Index (was 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: You're mixing things up :) Rebase is just a script around new branch starting at given base, cherry-pick all the commits from the base to the head of what's being rebased. It's a script, literally. It can't break your repo. You're right, i'm confusing rebase and reset (and its --hard option). Thank you for so politely pointing that out :). This is a very polite crowd. When in Rome... :) - if the index is not empty, then the user can't change branches - if the index is not empty, then commit should commit only what's in the index Neither of those seems to pose any problems, so long as the index isn't using the current versioning-related infrastructure (concretely: doesn't have any unique content which is referenced by other commits). This is certainly a use case i'll explore in libfossil (where i've got a bit more leeway in making changes). Right, the index is a very light-weight mechanism for giving the user power in deciding what to commit. I.e., more fine-grained control than choose what files to commit. [...]. It's not about undo. It's about capturing a subset of the extant deltas for committing. i've only ever used the index for (basically) an undo area, but you're right, that's probably not what most people use it for. In my mind the index is basically autosync=0, but of course that's a hugely oversimplified world view. The index is very ephemeral, unlike stashing. I never use git stash, and I don't care for it. stage is close to stash, so I can see the confusion. i have some ideas about how this could be done. In libf it would be relatively straightforward, i think, because it allows the client more control over the source and destination of the content bytes. In fossil it would require more infrastructure, but probably not prohibitively much. In terms of primitives it's not much. You should play briefly with the index in git: % git init % date somefile % git add somefie % git commit -m initial % date somefile % sleep 1 % date somefile % git add -e somefile select the one hunk and choose to edit it so as to take one, but not the other of the two new lines % git commit -m add a date % git diff % git commit -m add another date % git log -p Now picture working on some bug and then you realize you've written a fix for two different things, and you want to disentangle them into two commits. How? You could checkout a clean workspace and manually add the changes for one fix, commit, and go from there. Or, you can use git add -p or git add -e and it's much, much easier. It's like having a logical snapshot of the workspace set aside. You add things to the index (copy, if you like) from the workspace, then you commit what's in the index. The stash is similar, at least in principal, so there may already be a basis in place for something like this. The stash is much more permanent. The index is much more ephemeral. These are the things you can do with an index: - add to it - inspect it - remove from it - commit it A stash is a more complicated beast, as it's really saving extant changes in a bundle with a name. But you're right that the stash too is something that can be bolted on the side of the VCS with relatively little help from the VCS. In a sense the index and stashing are alike. But the index is much easier to use and explain. If you can use OS X and try out the SourceTree app.. that will make it even easier, self-evident even, straightforward. I mean, my wife discovered the SourceTree equivalent of git add -e and just used it, even though she was days into learning how to use SourceTree. It allowed her to really solve a real problem without having to learn how to rebase to split commits (which is a much more difficult thing to explain!). Sounds reasonable. :) I have to use Mercurial in some cases. My commit history for git projects tends to be much cleaner than for Mercurial projects, and this is largely due to the index and git add -p/-e (and the way _I_ go about writing code). Fair enough. i've just jotted down some ideas to play with, but i can't commit to any timeframe. I ask for no commitments. I wanted only to plant seeds. :) Ideas on implementation strategies are of course welcomed! I will look at Fossil source and think about it. Nico -- ___ 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] anyone have a fossil binary for Android ARM9?
On Wed, Jun 4, 2014 at 5:43 PM, Martin Gagnon eme...@gmail.com wrote: https://drive.google.com/file/d/0B_-jB7mK7jpXUUZKQW5vcEFnRkE/edit?usp=sharing Thanks! i just got it compiled on Xubuntu 13.10 on the ODroid. Running from a MicroSD (as opposed to eMMC, because Android is on my eMMC chip), compile time for fossil trunk: 3m24s. IIRC the Pi took about 20m compiling on an external USB drive. i will try your binary out on Android the next time i'm booted into it. -- - 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] Index (was Re: git-fossil-git does not obtain the same commit hashes.)
On Wed, Jun 4, 2014 at 11:58 AM, Nico Williams n...@cryptonector.com wrote: Right, the index is a very light-weight mechanism for giving the user power in deciding what to commit. I.e., more fine-grained control than choose what files to commit. My view is that the Git staging area (I really dislike the use of the word index in that context) merely makes Git more difficult for people to understand and complicates the interface without adding any new capability. The staging area is another element of state on a check-out. It is one more thing that the developer must keep in mind. Better to minimize the amount of mind-space required for the VCS in order to leave as much mind-space available to the application as possible. Mind-space is a finite resource. Use it wisely. The staging area complicates the interface. Instead of just a diff between the current check-out and the most recent check-in, now you have to add syntax for a diff between the checkout and the staging area and a diff between the staging area and the most recent check-in. Multiply that by as many commands as you have that involve both the repository and the current check-out. Does undo/redo effect the staging area? What if you update in order to pull in changes made by a collaborator before you commit - how does that effect the staging area? How does the staging area interact with the stash? If you are making a change in one branch and decide you'd really rather have that change in a different branch (or you just happen to discover that you were mistakenly on the wrong branch - which is the usual reason this comes up for me) and you move all your changes to a different branch prior to check-in, does your staging area move with you or not? Thousands of details like this need to be considered. And all of these details and complications and the associated mental clutter can be quickly and easily eliminated simply by omitting the staging area. My understanding is that the Git staging area arose as part of the implementation showing through into the interface. In Git-speak, it is plumbing that is visible from the porcelain. It is a misfeature. My readings on the matter suggest that most people agree with me on that point. Please keep all thoughts of a staging area far, far away from Fossil. -- 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] Question regarding ancestors and Q-card relations.
Thus said Richard Hipp on Wed, 04 Jun 2014 07:47:43 -0400: The merge logic in Fossil recognizes when the same exact change is merged more than once and avoids conflicts in that case. The Q-cards are not necessary for this. What am I doing wrong then? In this case, I did a cherrypick and committed to get 738e72e3d9; then right after I merge from the same checkin as the Q-card, but the diff shows that it duplicated the content (I did not add the line in the diff, the merge did): $ fossil stat | grep checkout checkout: 738e72e3d9cfe5568c94940c09ada1b78341ac68 2014-06-04 03:48:59 UTC $ fossil art 738e72e3d9cfe5568c94940c09ada1b78341ac68 C six D 2014-06-04T03:48:59.091 F file 2dfb8ca405192b966ad859171e7a52141fa90d73 P 6b8b667ee4c9f7176410c90f99d0a43aa33f30b0 Q +c14a4a93d5a353f1a887b0ddd7c37f33ce45569f R 36855f79a36bd6536f8584211e9077df U amb Z 03e53539308b57abb68256d198c87954 $ fossil merge c14a4a MERGE file fossil undo is available to undo changes to the working checkout. $ fossil diff Index: file == --- file +++ file @@ -1,2 +1,3 @@ 21443 +3661 3661 Thanks, Andy -- TAI64 timestamp: 4000538f5a94 ___ 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] Question regarding ancestors and Q-card relations.
On Wed, Jun 4, 2014 at 1:42 PM, Andy Bradford amb-fos...@bradfords.org wrote: Thus said Richard Hipp on Wed, 04 Jun 2014 07:47:43 -0400: The merge logic in Fossil recognizes when the same exact change is merged more than once and avoids conflicts in that case. The Q-cards are not necessary for this. What am I doing wrong then? In this case, I did a cherrypick and committed to get 738e72e3d9; then right after I merge from the same checkin as the Q-card, but the diff shows that it duplicated the content (I did not add the line in the diff, the merge did): No merge is perfect. Apparently you hit a bad case. But I do similar things all the time on actual source code and rarely have problems. -- 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: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] Index (was Re: git-fossil-git does not obtain the same commit hashes.)
On Wed, Jun 4, 2014 at 11:50 AM, Richard Hipp d...@sqlite.org wrote: On Wed, Jun 4, 2014 at 11:58 AM, Nico Williams n...@cryptonector.com wrote: Right, the index is a very light-weight mechanism for giving the user power in deciding what to commit. I.e., more fine-grained control than choose what files to commit. My view is that the Git staging area (I really dislike the use of the word index in that context) merely makes Git more difficult for people to understand and complicates the interface without adding any new capability. I felt it was a power feature that made my power user life better. Then I showed my wife how to use SourceTree on OS X. I had figured that I'd never show her the index. ETOOHARD I thought. Until something came up where she needed to discard some changes and keep others she had made to a file. SourceTree's GUI interface to the index turns out to be very natural and easy to you. I couldn't believe it, but she picked it up immediately even though she'd never before used git and I'd never thought of how to build a UI to the index. In retrospect the thing is this: at a CLI level, yes, the index requires that users know how do deal with and even edit patch chunks in order to make powerful use of it, and for most users that's just a lot of detail. But in a GUI it turns out that the index can be made a very easy to use feature. The staging area is another element of state on a check-out. It is one more thing that the developer must keep in mind. Better to minimize the amount of mind-space required for the VCS in order to leave as much mind-space available to the application as possible. Mind-space is a finite resource. Use it wisely. The staging area complicates the interface. Instead of just a diff between the current check-out and the most recent check-in, now you have to add syntax for a diff between the checkout and the staging area and a diff between the staging area and the most recent check-in. Multiply that by as many commands as you have that involve both the repository and the current check-out. Does undo/redo effect the staging area? What if you update in order to pull in changes made by a collaborator before you commit - how does that effect the staging area? How does the staging area interact with the stash? If you are making a change in one branch and decide you'd really rather have that change in a different branch (or you just happen to discover that you were mistakenly on the wrong branch - which is the usual reason this comes up for me) and you move all your changes to a different branch prior to check-in, does your staging area move with you or not? Thousands of details like this need to be considered. And all of these details and complications and the associated mental clutter can be quickly and easily eliminated simply by omitting the staging area. My understanding is that the Git staging area arose as part of the implementation showing through into the interface. In Git-speak, it is plumbing that is visible from the porcelain. It is a misfeature. My readings on the matter suggest that most people agree with me on that point. Please keep all thoughts of a staging area far, far away from Fossil. -- 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 ___ 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] Index (was Re: git-fossil-git does not obtain the same commit hashes.)
Thus said Richard Hipp on Wed, 04 Jun 2014 14:34:31 -0400: It clearly would not work for me. As as an amateur user of Git, Git wasn't working for me---perhaps this is simply due to misunderstanding ``core'' features of Git. At any rate, thanks to Git I discovered Fossil and have been pleased with the sanity of its design. It seems that whatever I've wanted to do with Git was always easier and simpler to do with Fossil. I'm not, however, a power user and perhaps that is why Git is not my preferred tool. This doesn't mean Fossil is perfect or a perfect fit in all cases, but having used Git, Hg, Darcs, and Fossil, I definitely prefer Fossil. Of course, Git doesn't have anything like fossil all changes (AFAIK), so maybe that is why nobody has noticed how annoying the staging area might be. I've always thought the ``staging'' area was messy, even before I knew about Fossil---again, I'm no Git expert, just making some observations. Andy -- TAI64 timestamp: 4000538f6bd0 ___ 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] Autosync retry?
Thus said Martin Gagnon on Fri, 30 May 2014 05:55:58 -0400: Same for me, I always use autosync=1 together with the dont-push=1 setting for that. Look like an option got added by someone that didn't know about the other. The actually do serve different purposes. dont-push=1 prevents *all* pushes from happening. autosync=pull-only only prevents autosync from doing a push, manual push still works. Andy -- TAI64 timestamp: 4000538f88c0 ___ 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
Re: [fossil-users] Index (was Re: git-fossil-git does not obtain the same commit hashes.)
On 6/4/2014 10:50, Richard Hipp wrote: The staging area complicates the interface. Perhaps you will add some of this to the Fossil vs Git wiki page. (Section 3.4?) ___ 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] Index (was Re: git-fossil-git does not obtain the same commit hashes.)
I started to use fossil just today, but let me participate too :) Everyday I have a list of tasks that I have to work on and when I finish, I like to separate the changes of each task by commit. To do that, I just open GUI, check the lines of the files that i want to commit. (Just like this print: http://i1-linux.softpedia-static.com/screenshots/gitg_5.jpg, where I click on the - and + to stage the line). But today, using fossil, I couldn't find anyway to do that, so I had to put all the changes on the same commit. Well, in the theory I can work on one task at time and commit when I finish, but in the practice I work on all the tasks at same time. Alysson Gonçalves de Azevedo Anarcho-syndicalism is a way of preserving freedom. - Monty Python 2014-06-04 21:14 GMT-03:00 Warren Young war...@etr-usa.com: On 6/4/2014 10:50, Richard Hipp wrote: The staging area complicates the interface. Perhaps you will add some of this to the Fossil vs Git wiki page. (Section 3.4?) ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ 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] Index (was Re: git-fossil-git does not obtain the same commit hashes.)
I've heard git allows this, and occasionally wished for it. As it stands currently, it's not possible with fossil. There is a degree of freedom in this regard using the fossil stash, though, which can be used with some file jigging to separate two (or more?) logical ideas that one wants committed discretely. Otherwise, fossils workflow really does encourage the (highly regarded) tenet commit early, commit often. On Jun 4, 2014 8:09 PM, Alysson Gonçalves de Azevedo agalys...@gmail.com wrote: I started to use fossil just today, but let me participate too :) Everyday I have a list of tasks that I have to work on and when I finish, I like to separate the changes of each task by commit. To do that, I just open GUI, check the lines of the files that i want to commit. (Just like this print: http://i1-linux.softpedia-static.com/screenshots/gitg_5.jpg, where I click on the - and + to stage the line). But today, using fossil, I couldn't find anyway to do that, so I had to put all the changes on the same commit. Well, in the theory I can work on one task at time and commit when I finish, but in the practice I work on all the tasks at same time. Alysson Gonçalves de Azevedo Anarcho-syndicalism is a way of preserving freedom. - Monty Python 2014-06-04 21:14 GMT-03:00 Warren Young war...@etr-usa.com: On 6/4/2014 10:50, Richard Hipp wrote: The staging area complicates the interface. Perhaps you will add some of this to the Fossil vs Git wiki page. (Section 3.4?) ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
