[fossil-users] git-fossil-git does not obtain the same commit hashes.
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, which would give us the ability to a) use Fossil for informational purposes, b) use Fossil as a high-level backup/restore for git. 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 git-Fossil-git conversion, the only differences are: - the commit author information (Fossil loses the comment part of the author's RFC5322 email address) - the date (Fossil changes the timezone to +, that is, it loses the timezone of the original). If these two issues were fixed then at least the initial commit of the repo I was testing this on would end up with the same commit hash. I'm guessing there will be other minor differences in, for example, merge commits, but first things first... Two ideas occur for fixing this: either add metadata so that Fossil can reproduce git commits exactly, or store the commit headers as-is in Fossil along with Fossil's parsed metadata from the same. The latter will work better, but seems like a hack. The former might prove to be a lengthy iterative process and may be git version sensitive. Nico -- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] git-fossil-git does not obtain the same commit hashes.
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 a test run of a git-Fossil-git conversion, the only differences are: - the commit author information (Fossil loses the comment part of the author's RFC5322 email address) - the date (Fossil changes the timezone to +, that is, it loses the timezone of the original). The date conversion is very problematic for round-trip fidelity. When developing libfossil, one of the initial test challenges was to make sure libfossil has 100% fidelity with fossil in terms of manifest generation. It turns out that it's impossible to convert the timestamps to and from Julian Days with 100% fidelity all of the time. i spent a great deal of time finding conversion tweaks and acceptable difference rates for the general case, but my current tests (run across the 1645 current event table entries in libfossil) have 1ms precision differences in 4 records (0.24%) when converting those timestamps round-trip (from Julian to RFC8601, then back to Julian). 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. 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). Two ideas occur for fixing this: either add metadata so that Fossil can reproduce git commits exactly, or store the commit headers as-is in Fossil along with Fossil's parsed metadata from the same. The latter will work better, but seems like a hack. The former might prove to be a lengthy iterative process and may be git version sensitive. 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? -- - 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, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] git-fossil-git does not obtain the same commit hashes.
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 test app): 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). If that 4 gets too high (i think i've got it set for 1%) then the test fails. The failure rates sway across different platforms, too. -- - 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, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] git-fossil-git does not obtain the same commit hashes.
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 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 == 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). If that 4 gets too high (i think i've got it set for 1%) then the test fails. The failure rates sway across different platforms, too. -- - 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, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] git-fossil-git does not obtain the same commit hashes.
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
Re: [fossil-users] git-fossil-git does not obtain the same commit hashes.
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 the timezone of the user making the commit, but that is informational only and not actually relevant to the commit timestamp (at least as far as Fossil is concerned). Here's an example: author User Name u...@domain.dom 1401819503 -0600 committer User Name u...@domain.dom 1401819503 -0600 Note that 1401819503 is a UTC timestamp and the -0600 while stored as part of the record, does not change when 1401819503 happened. I would *almost* consider this a bug in git fast-export as it might lead one to believe that the timestamp is offset by -0600. Fossil doesn't really care about timezones (all timestamps are in UTC), but perhaps a git-timezone tag could be added to the artifact? Andy -- TAI64 timestamp: 4000538e14e8 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] git-fossil-git does not obtain the same commit hashes.
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 is such a crufty business! Andy -- TAI64 timestamp: 4000538e152f ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] git-fossil-git does not obtain the same commit hashes.
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 UTC and have no timezone offset. There may be additional metadata associated with a commit that records the timezone of the user making the commit, but that is informational only and not actually relevant to the commit timestamp (at least as far as Fossil is concerned). Right. Fossil doesn't really care about timezones (all timestamps are in UTC), but perhaps a git-timezone tag could be added to the artifact? Right, that was one suggestion. Nico -- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] git-fossil-git does not obtain the same commit hashes.
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 translate accurate (at the msec level). Getting radical architectural changes to git accepted seems likely to be impossible. Bingo! Same here :). I'd rather convince the Fossil developers/community to support the git features we need: Good luck with that ;) - by default only push the branch that's checked out Some work was done a year or two ago(?) on pushing only certain branches, but i don't know where that ended up (not in the trunk, AFAIK). Things my colleagues and I are used to: - the index, of course - workflows with feature branches and clean history at integration ... - workflows with distributed and hierarchical teams - merge-heavy workflows with multiple remote repos and trunks Something to consider: the only thing git's lacking from your wish-list, apparently, is durable storage. Conversely, Fossil seems to be lacking all features you rely on _except_ durable storage. -- - 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, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] git-fossil-git does not obtain the same commit hashes.
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/506f0f3cffafe4e5b4014554e6c09a2204b04f03?ln=575-795 and http://core.tcl.tk/akupries/fx/artifact/506f0f3cffafe4e5b4014554e6c09a2204b04f03?ln=356-380 is the control on top. (*) While the core is a fossil export --git | git fast-import see http://core.tcl.tk/akupries/fx/artifact/506f0f3cffafe4e5b4014554e6c09a2204b04f03?ln=727-728 there is apparently quite a bit around it to manage git helper repos. On Tue, Jun 3, 2014 at 11:44 AM, Nico Williams n...@cryptonector.com wrote: On Tue, Jun 3, 2014 at 1:07 PM, Nico Williams n...@cryptonector.com wrote: On Tue, Jun 3, 2014 at 12:09 PM, Stephan Beal sgb...@googlemail.com 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 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: BTW, another thing is that if Fossil could support git remote repos to push to, that would be great. Yes, tickets and wiki artifacts would't go. But it'd allow one to push to github/gitorious/... repos from Fossil workspaces. Yes, there's Chiselapp, but I think there's value in this. Get users hooked, then direct them to Fossil and Chiselapp for all that which git lacks. Nico -- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Andreas Kupries Senior Tcl Developer Code to Cloud: Smarter, Safer, Faster™ F: 778.786.1133 andre...@activestate.com http://www.activestate.com Learn about Stackato for Private PaaS: http://www.activestate.com/stackato EuroTcl'2014, July 12-13, Munich, GER -- http://www.eurotcl.tcl3d.org/ 21'st Tcl/Tk Conference: Nov 10-14, Portland, OR, USA -- http://www.tcl.tk/community/tcl2014/ Send mail to tclconfere...@googlegroups.com, by Sep 8 Registration is open. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] git-fossil-git does not obtain the same commit hashes.
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 doubles to and from ISO format. Some percentage of the records will not translate accurate (at the msec level). It's possible by storing additional metadata. Redundant, annoying even, but to be ignored most of the time (except when computing hashes and when exporting to git). 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: Good luck with that ;) 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 intrusive (FYI, git went through that same evolution, in that initially the default was to push all branches unless you named a branch(es) to push.) - by default only push the branch that's checked out Some work was done a year or two ago(?) on pushing only certain branches, but i don't know where that ended up (not in the trunk, AFAIK). See? Things my colleagues and I are used to: - the index, of course - workflows with feature branches and clean history at integration ... - workflows with distributed and hierarchical teams - merge-heavy workflows with multiple remote repos and trunks Something to consider: the only thing git's lacking from your wish-list, apparently, is durable storage. Conversely, Fossil seems to be lacking all features you rely on _except_ durable storage. You're missing one item: a relational approach to history. I'm sure git can be fixed to recover more cleanly from interruptions during receives, commits, and so on. Composition of atomic operations from filesystem operations is difficult but not impossible. I'm sure eventually git will improve in this area, probably getting to good enough. But SQL? It'll never happen. One could bolt-on a metadata-only SQLite3 DB using git hooks, I'm sure, but being external would make it fragile. Nico -- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] git-fossil-git does not obtain the same commit hashes.
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 really very intrusive (FYI, git went through that same evolution, in that initially the default was to push all branches unless you named a branch(es) to push.) The main limiting factor here, from my understanding, is internals of fossil which _might_ change _older_ data, making it dependent on the newer data. e.g when saving a file, fossil might transform its older version into a delta based on the new version (which is stored in undeltad form). Whether or not it actually does that is left for it to decide. All of that is a side effect of Fossil's original design philosophy: once it's in, it stays in. Because it was built with that philosophy in mind, it makes optimizations based on that which make undoing it (e.g. so a staged or unpushed commit could be undone) amazingly hard. About 6 months ago or so i investigated what it would take to support undo of popping the top-most change from a repo (be it a tag, wiki change, or whatever), and the checklist of TODOs (and associated complexity) quickly grew longer than my hair :/. Some work was done a year or two ago(?) on pushing only certain branches, but i don't know where that ended up (not in the trunk, AFAIK). See? AFAIK it wasn't ever usable/completed, but i can't speculate on the reasons (e.g. lack of interest, complexity, or architectural limits). You're missing one item: a relational approach to history. i get that - fossil has it and git doesn't. That's _one_ feature from your list which fossil has and git does not, whereas git has _lots_ of features you want but fossil does not have. It sounds to me like it would be less work to collect git data into a db than it would to change fossil's to match git in these regards. The relational storage and the durable storage go very much hand in hand here - they're both side effects of using (as DRH recently put it) sqlite3_open() instead of fopen(). I'm sure git can be fixed to recover more cleanly from interruptions...enough. But SQL? It'll never happen. One could bolt-on a metadata-only SQLite3 DB using git hooks, I'm sure, but being external would make it fragile. Not only that, but there would still be windows of opportunity where what the filesystem says isn't consistent with what the db says. The db is likely to be in a consistent state, but possibly not match the current state. That's a matter for the git developers, though. In principal it's a simple matter of swapping out storage back ends. In practice, the impl code is closely tied to the storage back-end, making the conceptually simple port into a physically difficult one to do. Porting fossil's underlying model to MySQL or Oracle is a good example of such a case - conceptually easy but more work than anyone's willing to do. -- - 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, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] git-fossil-git does not obtain the same commit hashes.
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 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. (That said, i'm not the one you'd need to convince ;) git branches are really just symbolic names for commits. And commits not reachable from any branch or tag can be removed if you prune dead branches, but I'm not asking that Fossil have this functionality. Fossil's internals would indeed make it very difficult to do that. Because it was built with that philosophy in mind, it makes optimizations based on that which make undoing it (e.g. so a staged or unpushed commit could be undone) amazingly hard. The index has nothing to do with this. Deltas in the index are not in the repo. They are just the deltas that will be in the next commit, that's all. The index is in the db, along with everything else. Fossil would currently need a separate set of delta tables and algorithms to accommodate that, or some way to say do not consider these artifacts for delta purposes. About 6 months ago or so i investigated what it would take to support undo of popping the top-most change from a repo (be it a tag, wiki change, or whatever), and the checklist of TODOs (and associated complexity) quickly grew longer than my hair :/. Right, and that's just not something I'm interested in. But it would provide a git-like staging area in that you would have one level of undo. And then another level of undo... and another, all the way back to the first commit. As long as the repo wasn't synced, that could provide a staging area-like (like, but not identical) feature. Examples of primitives needed: - a cherry-pick that has the option to commit or not commit the given commit - the ability to commit with timestamps other than now, arbitrary committer info, ... i thought 'commit' had flags to override the timestamp and user, but apparently not. - metadata for referring to an original commit (so that one can chase cherry-picks and rebases) What you're asking for is that fossil add the infrastructure for 100% fidelity with a 3rd-party system which can change at any time, breaking fossil's 100% fidelity. Any solution would be based on assumptions made about git, and that way lies madness. - preventing some operations (e.g., push, change branch) from running while a long-running interactive operation (e.g., merge, rebase, ...) is in-progress the db locking generally takes care of that (by failing for the second and subsequent ops). - for the index all that's needed is a way to apply a commit without referring to the checked out files, and a way to prevent switching to other branches while the index is not empty The commit model in fossil is fundamentally based on the sha1 of the contents of the file. How do we get that without referencing the files? None of these strike me as in conflict with Fossil principles. Not necessarily the principals, but they would, by and large, require new infrastructure which would be added for the sole sake of 100% fidelity with git, so that Fossil can be used as a git backup/recovery system when git suffers an untimely power outage. That way lies madness. (Headed off to bed, so please don't take a lack of further responses personally! ;) -- - 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, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] git-fossil-git does not obtain the same commit hashes.
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 can chase cherry-picks and rebases) I might be misunderstanding, but if you merge --cherrypick, it keeps track of this in the Q-card of the manifest. It does look like timeline does not display/represent the relationship of the Q-card. Not sure if that's intentional. - preventing some operations (e.g., push, change branch) from running while a long-running interactive operation (e.g., merge, rebase, ...) is in-progress Fossil has the ``dont-push'' setting, or autosync can be set to ``pull-only.'' Pardon my intrusion if I have misunderstood some of these comments. :-) Andy -- TAI64 timestamp: 4000538e430a ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] git-fossil-git does not obtain the same commit hashes.
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 new commits. Therefore rebase doesn't violate that constraint. 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. (That said, i'm not the one you'd need to convince ;) 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. (A rebase of a branch that had been referenced from downstreams will break them, which is why one should not do it to a public branch. And the old commits may be left unreachable from any branch name, so you might think your repo is broken, but you can still find those commits and create branches that refer to them.) git branches are really just symbolic names for commits. And commits not reachable from any branch or tag can be removed if you prune dead branches, but I'm not asking that Fossil have this functionality. Fossil's internals would indeed make it very difficult to do that. 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 is just a new table at best, with two columns. Because it was built with that philosophy in mind, it makes optimizations based on that which make undoing it (e.g. so a staged or unpushed commit could be undone) amazingly hard. The index has nothing to do with this. Deltas in the index are not in the repo. They are just the deltas that will be in the next commit, that's all. The index is in the db, along with everything else. Fossil would currently need a separate set of delta tables and algorithms to accommodate that, or some way to say do not consider these artifacts for delta purposes. It could be in the DB, but it doesn't need to interfere with anything. The only requirements: - if the index is not empty, then the user can't change branches - if the index is not empty, then commit should commit only what's in the index Any tools to manage the index could then be totally external (contributed). About 6 months ago or so i investigated what it would take to support undo of popping the top-most change from a repo (be it a tag, wiki change, or whatever), and the checklist of TODOs (and associated complexity) quickly grew longer than my hair :/. Right, and that's just not something I'm interested in. But it would provide a git-like staging area in that you would have one level of undo. And then another level of undo... and another, all the way [...] You misunderstand the index. It's not about undo. It's about capturing a subset of the extant deltas for committing. - for the index all that's needed is a way to apply a commit without referring to the checked out files, and a way to prevent switching to other branches while the index is not empty The commit model in fossil is fundamentally based on the sha1 of the contents of the file. How do we get that without referencing the files? The index captures the content to be committed. It's like having a logical snapshot of the workspace set aside. You add things to the index (copy, if you like) from the workspace, then you commit what's in the index. If your index is empty and you commit, you get the same behavior as today. None of these strike me as in conflict with Fossil principles. Not necessarily the principals, but they would, by and large, require new infrastructure which would be added for the sole sake of 100% fidelity with git, so that Fossil can be used as a git backup/recovery system when git suffers an untimely power outage. That way lies madness. Forget the backup/restore -- that's a different problem set. We're now on the subject of about allowing me to get the workflows I use with git, but with Fossil instead, and with minimal changes to Fossil. Give me the bare primitives I need, and I can build the rest as external components. Nico -- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] git-fossil-git does not obtain the same commit hashes.
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? But it would provide a git-like staging area in that you would have one level of undo. And then another level of undo... and another, all the way back to the first commit. As long as the repo wasn't synced, that could provide a staging area-like (like, but not identical) feature. You have a git staging area with Fossil already (at least one level anyway): cd /tmp fossil clone /tmp/clone.fossil /path/to/fossil mkdir clone; cd clone; fossil open /tmp/clone.fossil fossil set autosync pull-only fossil set dont-push 1 # make changes, commit, etc Now, after you've done all your work, you have a decision. Do you turn off dont-push and push? Do you pull and see if there are any merge conflicts? Do you want to toss out all the changes? Ok, let's toss out all the changes: fossil close rm -rf /tmp/clone.fossil /tmp/clone i thought 'commit' had flags to override the timestamp and user, but apparently not. $ fossil ci --user-override nobody -m Test --date-override '2013-06-03 21:59:00' Autosync: file:///tmp/new.fossil Round-trips: 1 Artifacts sent: 0 received: 0 Pull finished with 266 bytes sent, 527 bytes received ancestor check-in [6bdbdcd602] (2013-06-03 21:59:00.000) is not older (clock skew?) Use --allow-older to override. # OK WHATEVER COMMIT IT $ fossil ci --user-override nobody -m Test --date-override '2013-06-03 21:59:00' --allow-older Autosync: file:///tmp/new.fossil Round-trips: 1 Artifacts sent: 0 received: 0 Pull finished with 267 bytes sent, 527 bytes received New_Version: 14ffb751ae45dc810e3a4a04d4a5fda2069fbdb8 Fossil gracefully handles the backwards commit in the timeline too and shows this commit even prior to the initial commit. :-) Andy -- TAI64 timestamp: 4000538e4614 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] git-fossil-git does not obtain the same commit hashes.
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 Q-card. It does not at this time. Can you suggest a look for how cherrypick merges should appear on the timeline? -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] git-fossil-git does not obtain the same commit hashes.
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 cherry-red line of dots? Could the line be styled with CSS in case people don't like red? I notice that there is a somewhat dark-red line for backwards checkins in the timeline, maybe a different color would be better. Andy -- TAI64 timestamp: 4000538e4eb7 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Question regarding ancestors and Q-card relations.
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 738e72e3d9cfe5568c94940c09ada1b78341ac68 C six D 2014-06-04T03:48:59.091 F file 2dfb8ca405192b966ad859171e7a52141fa90d73 P 6b8b667ee4c9f7176410c90f99d0a43aa33f30b0 Q +c14a4a93d5a353f1a887b0ddd7c37f33ce45569f R 36855f79a36bd6536f8584211e9077df U amb Z 03e53539308b57abb68256d198c87954 Does the Q-card here not imply any relation with c14a4a93d5a3 which will be picked up in trunk? After c14a4a93d5a3 there are two more commits which is where trunk is currently, yet when I try to merge it cannot find a common ancestor. If I try to merge with the checkin from which I just cherry picked I get: $ fossil merge c14a4a MERGE file fossil undo is available to undo changes to the working checkout. $ fossil diff Index: file == --- file +++ file @@ -1,2 +1,3 @@ 21443 +3661 3661 So it added a second copy of the change? Thanks, Andy -- TAI64 timestamp: 4000538e99bc ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Question regarding ancestors and Q-card relations.
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 check-in. But whereas a P-card defines the immediate ancestor or a merge ancestor, the Q-card is used to identify a single check-in or a small range of check-ins which were cherry-picked for inclusion in or exclusion from the current manifest. Which I suppose means that there is no ancestral relationship. $ fossil merge c14a4a MERGE file fossil undo is available to undo changes to the working checkout. Should a merge in this case result in a conflict? Or is it correct to merge in the content a second time? Or should it recognize that the Q-card UUID and the UUID of the version being merged in are the same and include a warning or even error? Andy -- TAI64 timestamp: 4000538e9b89 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
