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
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,
On Tue, Jun 3, 2014 at 6:42 PM, Nico Williams n...@cryptonector.com 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
On Tue, Jun 3, 2014 at 7:09 PM, Stephan Beal sgb...@googlemail.com 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
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 sgb...@googlemail.com wrote:
On Tue, Jun 3, 2014 at 7:09 PM, Stephan Beal sgb...@googlemail.com wrote:
precision differences in 4
On Tue, Jun 3, 2014 at 12:09 PM, Stephan Beal sgb...@googlemail.com 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
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
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).
Awesome! Time
On Tue, Jun 3, 2014 at 1:32 PM, Andy Bradford
amb-sendok-1404412362.ophlclhccgjkadkek...@bradfords.org 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
On Tue, Jun 3, 2014 at 8:07 PM, Nico Williams n...@cryptonector.com 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
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
On Tue, Jun 3, 2014 at 2:03 PM, Stephan Beal sgb...@googlemail.com wrote:
On Tue, Jun 3, 2014 at 8:07 PM, Nico Williams n...@cryptonector.com 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
On Tue, Jun 3, 2014 at 10:05 PM, Nico Williams n...@cryptonector.com
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
On Tue, Jun 3, 2014 at 10:49 PM, Nico Williams n...@cryptonector.com
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
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 one
On Tue, Jun 3, 2014 at 4:15 PM, Stephan Beal sgb...@googlemail.com wrote:
On Tue, Jun 3, 2014 at 10:49 PM, Nico Williams n...@cryptonector.com
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
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
branch?
On Tue, Jun 3, 2014 at 5:49 PM, Andy Bradford amb-fos...@bradfords.org
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
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
19 matches
Mail list logo
