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 could store the Date (and Author) headers from git exactly, for reconstruction of git repos from Fossil. >> I'm guessing there will be other minor differences in, for example, >> merge commits, but first things first... > > ANY difference results in a different hash, so the email change is enough > (regardless of all my blather about timestamp precision changes). I'm aware. > 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 instead? Being able to round-trip this way might allow more users to test-drive Fossil. Getting radical architectural changes to git accepted seems likely to be impossible. I'd rather convince the Fossil developers/community to support the git features we need: - workflows that use rebase (not on public branches, of course), including interactive rebasing - the git index, including git add -e/-p - by default only push the branch that's checked out Since Fossils can cherry-pick, rebase shouldn't be difficult. We'd not mind if rebase always results in a new branch being created, for example. BTW, even non-power users can make powerful use of the git index. I've been using SourceTree on OS X lately to teach a novice how to use git, and SourceTree's interface to the index is shockingly straightforward, easy to understand, and easy to use. I'd expected that a GUI just would not be able to provide a decent git add -e/-p interface, but SourceTree delightfully surprised me. Things my colleagues and I are used to: - the index, of course - workflows with feature branches and clean history at integration into master time, preserving interesting history (e.g., bug fixes for cherry-picking onto maintenance release branches, feature-related commits) but not uninteresting commits (fix intra-feature branch history typos/bugs) - workflows with distributed and hierarchical teams - merge-heavy workflows with multiple remote repos and trunks (different product vendors collaborating and competing using an originally common codebase) Nico -- _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
