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

2014-06-03 Thread Andy Bradford
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

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

2014-06-03 Thread Andy Bradford
Hello, While experimenting with --cherrypick I stumbled upon this situation: $ fossil merge trunk cannot find a common ancestor between the current checkout and trunk $ f stat | grep checkout checkout: 738e72e3d9cfe5568c94940c09ada1b78341ac68 2014-06-04 03:48:59 UTC $ fossil artifact 738e72e3

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

2014-06-03 Thread Andy Bradford
Thus said Richard Hipp on Tue, 03 Jun 2014 18:04:22 -0400: > > It does look like timeline does not display/represent the > > relationship of the Q-card. > > It does not at this time. Can you suggest a "look" for how cherrypick > merges should appear on the timeline? I'm not sure... A

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

2014-06-03 Thread Richard Hipp
On Tue, Jun 3, 2014 at 5:49 PM, Andy Bradford wrote: > I might be misunderstanding, but if you merge --cherrypick, it keeps > track of this in the Q-card of the manifest. Correct. > It does look like timeline > does not display/represent the relationship of the Q-card. > It does not at

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

2014-06-03 Thread Andy Bradford
Thus said Stephan Beal on Tue, 03 Jun 2014 23:15:38 +0200: > Based on that description, that "sounds doable," but i'm inherently > dubious of "rebase" because i've broken my git repos more than once > when using it. Isn't rebase effecitvely merge from trunk (or any other branch) into a br

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

2014-06-03 Thread Nico Williams
On Tue, Jun 3, 2014 at 4:15 PM, Stephan Beal wrote: > On Tue, Jun 3, 2014 at 10:49 PM, Nico Williams > wrote: >> git rebase... doesn't remove commits from the repo. It only creates >> new commits and then updates a branch's head to point to the newest of >> the new commits. >> >> Therefore rebas

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

2014-06-03 Thread Andy Bradford
Thus said Nico Williams on Tue, 03 Jun 2014 15:49:19 -0500: > - the ability to commit with timestamps other than "now", arbitrary > committer info, ... Fossil has both --user-override and --date-override when doing a checkin. > - metadata for referring to an original commit (so that

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

2014-06-03 Thread Stephan Beal
On Tue, Jun 3, 2014 at 10:49 PM, Nico Williams wrote: > git rebase... doesn't remove commits from the repo. It only creates > new commits and then updates a branch's head to point to the newest of > the new commits. > > Therefore rebase doesn't violate that constraint. > Based on that descripti

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

2014-06-03 Thread Nico Williams
On Tue, Jun 3, 2014 at 3:26 PM, Stephan Beal wrote: > On Tue, Jun 3, 2014 at 10:05 PM, Nico Williams > wrote: >> >> These aren't architectural changes. >> >> For example, rebase == scripted sequence of cherry-picks. The index >> is more architectural, but not really that intrusive. Pushing only

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

2014-06-03 Thread Stephan Beal
On Tue, Jun 3, 2014 at 10:05 PM, Nico Williams wrote: > These aren't architectural changes. > > For example, rebase == scripted sequence of cherry-picks. The index > is more architectural, but not really that intrusive. Pushing only > > one branch, and so on, are also not really very intrusi

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

2014-06-03 Thread Nico Williams
On Tue, Jun 3, 2014 at 2:03 PM, Stephan Beal wrote: > On Tue, Jun 3, 2014 at 8:07 PM, Nico Williams wrote: >> >> Being able to round-trip this way might allow more users to test-drive >> Fossil. > > > It's not possible due to the limitations of round-tripping doubles to and > from ISO format. Som

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

2014-06-03 Thread Andreas Kupries
The tool FX http://core.tcl.tk/akupries/fx/index has commands to push from fossil repositories to git repositories. (fx help peer) (Relevant: add-git, remove-git, state, exchange) All the various git magic commands (*) can be seen at http://core.tcl.tk/akupries/fx/artifact/506f0f3cffafe

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

2014-06-03 Thread Stephan Beal
On Tue, Jun 3, 2014 at 8:07 PM, Nico Williams wrote: > Being able to round-trip this way might allow more users to test-drive > Fossil. > It's not possible due to the limitations of round-tripping doubles to and from ISO format. Some percentage of the records will not translate accurate (at the

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

2014-06-03 Thread Nico Williams
On Tue, Jun 3, 2014 at 1:07 PM, Nico Williams wrote: > On Tue, Jun 3, 2014 at 12:09 PM, Stephan Beal wrote: >> FWIW: Fossil was never intended to be a round-trip safety hatch for other >> SCMs which aren't as data-robust. Maybe convince the git developers to move >> their metadata into sqlite ins

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

2014-06-03 Thread Nico Williams
On Tue, Jun 3, 2014 at 1:32 PM, Andy Bradford wrote: > Thus said Nico Williams on Tue, 03 Jun 2014 11:42:44 -0500: > >> - the date (Fossil changes the timezone to +, that is, it loses >> the timezone of the original). > > Timestamps in Git are UTC and have no timezone offset. There may b

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

2014-06-03 Thread Andy Bradford
Thus said Stephan Beal on Tue, 03 Jun 2014 19:14:20 +0200: > iso8601 <==> julian tests... > Running all event.mtimes through the julian<==>iso converters... > 1645 Julian timestamps tested from event.mtime. > 4 record(s) (0.24%) differed round-trip by 1ms (this is "normal"/not > unexpected). Awes

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

2014-06-03 Thread Andy Bradford
Thus said Nico Williams on Tue, 03 Jun 2014 11:42:44 -0500: > - the date (Fossil changes the timezone to +, that is, it loses > the timezone of the original). Timestamps in Git are UTC and have no timezone offset. There may be additional metadata associated with a commit that records

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

2014-06-03 Thread Nico Williams
On Tue, Jun 3, 2014 at 12:09 PM, Stephan Beal wrote: > My point being: at least some small percentage of round-trip timestamp > conversions will fail because Julian Days to not have a 1-to-1 mapping for > all millisecond-level ranges in use today. Yes, though perhaps Fossil could store the Date (

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

2014-06-03 Thread B Harder
> Maybe convince the git developers to move their metadata into sqlite instead? Ha! Thanks for putting a smile on my face Stephan. -bch On 6/3/14, Stephan Beal wrote: > On Tue, Jun 3, 2014 at 7:09 PM, Stephan Beal wrote: > >> precision differences in 4 records (0.24%) when converting those >>

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

2014-06-03 Thread Stephan Beal
On Tue, Jun 3, 2014 at 7:09 PM, Stephan Beal wrote: > precision differences in 4 records (0.24%) when converting those > timestamps round-trip (from Julian to RFC8601, then back to Julian). > ISO8601, of course. Maybe this clarifies what i meant there (output from a libfossil test app): iso8601

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

2014-06-03 Thread Stephan Beal
On Tue, Jun 3, 2014 at 6:42 PM, Nico Williams wrote: > However, a git->Fossil->git doesn't produce the same commit hashes. > It seems like it ought to be possible to reproduce the exact same > commits, therefore the exact same commit hashes. > Looking at the very first commit in a test run of a

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

2014-06-03 Thread Nico Williams
So git doesn't handle power failures so well... And Fossil's use of SQL, and SQLite3 in particular, is awesome. But my colleagues and I like git workflows, and anyways we have git repos we can't just migrate to Fossil. The obvious idea is to use a git post-receive hook to backup git to Fossil, w