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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 (
> 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
>>
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
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
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
22 matches
Mail list logo
