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 committe

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

[fossil-users] Outside contribution feature

As far as I can tell, Fossil offers two ways to allow outsiders to submit changes to an open source software project: 1. Give them Develop privs 2. Ask them to "fossil diff" and mail you a patch file In my open source project, I only give repo checkin privileges to contributors who have

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-

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 > wrote: On Wed, Jun 4, 2014 at 3:27 PM, Scott Robison mailto:sc...@casaderobison.com>> wrote: I really want to steal this in tweet form: "To get to a place where you understand Gi

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

Re: [fossil-users] Autosync retry?

Thus said Matt Welland on Thu, 29 May 2014 09:00:56 -0700: > Retry on autosync would be a big help in my environment. Autosync > failures due to overlapping access are a regular and annoying > occurrence. I like Stephan's approach of 0, 1, N for off, on, > multi-try Have y

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

On Wed, Jun 4, 2014 at 1:34 PM, Richard Hipp wrote: > On Wed, Jun 4, 2014 at 2:20 PM, Nico Williams wrote: >> >> I never need to diff the staging area to the HEAD. Only the workspace >> to the HEAD+staging area, which is what git diff does. > > > Huh. I didn't not realize that was the default b

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 wrote: > On Wed, Jun 4, 2014 at 3:27 PM, Scott Robison > 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 w

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

On Wed, Jun 4, 2014 at 3:27 PM, Scott Robison 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.

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 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

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 > 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

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

On Wed, Jun 4, 2014 at 12:56 PM, Joel Bruick 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 ef

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 Beal wrote: On Wed, Jun 4, 2014 at 12:02 AM, Nico Williams 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 comm

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

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

On Wed, Jun 4, 2014 at 2:20 PM, Nico Williams wrote: > I never need to diff the staging area to the HEAD. Only the workspace > to the HEAD+staging area, which is what git diff does. > Huh. I didn't not realize that was the default behavior for Git. It clearly would not work for me. I'm typic

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

sent too soon. On Wed, Jun 4, 2014 at 11:50 AM, Richard Hipp wrote: > 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-spa

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 wrote: > On Wed, Jun 4, 2014 at 12:30 PM, Stephan Beal > wrote: > > On Wed, Jun 4, 2014 at 7:25 PM, Nico Williams > wrote: > >> > >> To be truly useful it has to be possible to [selectively] push/pull > >> bookmarks. > > > > > > If that's the case t

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 wrote: > On Wed, Jun 4, 2014 at 11:58 AM, Nico Williams > 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". > >

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 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 >

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 wrote: > On Wed, Jun 4, 2014 at 7:25 PM, Nico Williams 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 vers

Re: [fossil-users] Question regarding ancestors and Q-card relations.

Thus said Richard Hipp on Wed, 04 Jun 2014 13:48:48 -0400: > 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. Ok, thanks. I just wanted to make sure I wasn't misunderstanding. I can offer up the repositor

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

On Wed, Jun 4, 2014 at 12:02 PM, Richard Hipp wrote: > On Wed, Jun 4, 2014 at 12:53 PM, B Harder 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 t

Re: [fossil-users] Question regarding ancestors and Q-card relations.

On Wed, Jun 4, 2014 at 1:42 PM, Andy Bradford 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.

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 cherr

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 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(). Tha

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 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 di

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 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 th

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 wrote: > On Wed, Jun 4, 2014 at 6:03 PM, Nico Williams wrote: >> On Wed, Jun 4, 2014 at 9:07 AM, Stephan Beal >> wrote: >> > Bookmarks. That's a nice idea, actually. Added to my TODO list. > > i was thinking more generically: > > f bookmark add blah

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 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 woul

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

On Wed, Jun 4, 2014 at 7:16 PM, B Harder wrote: > I'm shaking my head, wondering "why?" My current mental image is: > http://perl-begin.org/humour/perl6_perl_6_cover_lg.jpg Reminds me of the on-on-on-oh-so-nausiatingly-ongoing JSON standardization efforts on the IETF mailing lists ;). But yeah,

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 wrote: > Because the internet can be a poor medium to express emotional intent

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:

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 wrote: > On Wed, Jun 4, 2014 at 12:53 PM, B Harder 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 yo

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 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

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 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 wit

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 wrote: > On Wed, Jun 4, 2014 at 12:03 PM, Nico Williams > wrote: > >> On Wed, Jun 4, 2014 at 9:07 AM, Stepha

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 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

Re: [fossil-users] anyone have a fossil binary for Android ARM9?

On Wed, Jun 4, 2014 at 5:43 PM, Martin Gagnon 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 f

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 wrote: > On Wed, Jun 4, 2014 at 9:07 AM, Stephan Beal > wrote: > > On Wed, Jun 4, 2014 at 12:02 AM, Nico Williams > > wrote: > >> Mercurial too had "heavy-duty" branches only, then they added > >> "bookmarks" that are very similar to git branches.

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 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

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 wrote: > On Wed, Jun 4, 2014 at 9:07 AM, Stephan Beal > wrote: > > On Wed, Jun 4, 2014 at 12:02 AM, Nico Williams > > wrote: > >> Mercurial too had "heavy-duty" branches only, then they added > >> "bookmarks" that are very similar to git branches.

[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 wrote: > On Wed, Jun 4, 2014 at 12:02 AM, Nico Williams > 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

[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 wrote: > On Wed, Jun 4, 2014 at 12:02 AM, Nico Williams > 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

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 wrote: > > On Wed, Jun 4, 2014 at 11:20 AM, Stephan Beal > wrote: > > Hi, all! > > i just got an ODROID-U3 device and i'm now looking for a fossil > bina

Re: [fossil-users] anyone have a fossil binary for Android ARM9?

On Wed, Jun 4, 2014 at 5:30 PM, Richard Hipp wrote: > On Wed, Jun 4, 2014 at 11:20 AM, 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 proces

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/

Re: [fossil-users] anyone have a fossil binary for Android ARM9?

On Wed, Jun 4, 2014 at 11:20 AM, 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? > > http://www.fossil-scm.org/fossil-beagle.gz compiled for

[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://wanderingh

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

On Wed, Jun 4, 2014 at 12:02 AM, Nico Williams 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: [fossil-users] diff file in checkout against its previous version

On 4 June 2014 15:51, Martin Gagnon wrote: > On Wed, Jun 04, 2014 at 03:21:10PM +0200, Michai Ramakers wrote: >> On 4 June 2014 15:12, Richard Hipp wrote: >> > >> > On Wed, Jun 4, 2014 at 9:05 AM, Michai Ramakers >> > wrote: >> >> >> >> Hello, >> >> >> >> perhaps a quick question: is it possible

Re: [fossil-users] diff file in checkout against its previous version

On Wed, Jun 04, 2014 at 03:21:10PM +0200, Michai Ramakers wrote: > On 4 June 2014 15:12, Richard Hipp wrote: > > > > On Wed, Jun 4, 2014 at 9:05 AM, Michai Ramakers > > wrote: > >> > >> Hello, > >> > >> perhaps a quick question: is it possible to diff a file in the current > >> checkout against a

Re: [fossil-users] diff file in checkout against its previous version

On Wed, Jun 4, 2014 at 3:24 PM, Richard Hipp 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

Re: [fossil-users] diff file in checkout against its previous version

On Wed, Jun 4, 2014 at 9:21 AM, Michai Ramakers wrote: > On 4 June 2014 15:12, Richard Hipp wrote: > > > > On Wed, Jun 4, 2014 at 9:05 AM, Michai Ramakers > > wrote: > >> > >> Hello, > >> > >> perhaps a quick question: is it possible to diff a file in the current > >> checkout against a previou

Re: [fossil-users] diff file in checkout against its previous version

On 4 June 2014 15:12, Richard Hipp wrote: > > On Wed, Jun 4, 2014 at 9:05 AM, Michai Ramakers > 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

Re: [fossil-users] diff file in checkout against its previous version

On Wed, Jun 4, 2014 at 9:05 AM, Michai Ramakers 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

[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 h

Re: [fossil-users] Question regarding ancestors and Q-card relations.

On Wed, Jun 4, 2014 at 12:07 AM, Andy Bradford 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 simi

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 wrote: > On Wed, 04 Jun 2014 10:36:41 +0200, Michai Ramakers > wrote: > >> Hello, >> >> is there a way to make 'fossil clone' a bit less verbose for use in >> scripts? I am using clone to make

Re: [fossil-users] script-friendlier progress-indicator when cloning

On Wed, 04 Jun 2014 10:36:41 +0200, Michai Ramakers 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 '/^R

[fossil-users] script-friendlier progress-indicator when cloning

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, Michai ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fo