Is there anything stopping us from hacking together a git/darcs/hg/old-pijul-format to current-pijul-format import script that simply unrecords commits or patches and replays the recording of each one with pijul record?
We would want to keep the original timestamps and would not want to add patch inverses for each of the patches we replay.
Unlike some others I have less interest in riding the fence with my tools with something like a pijul-git-pijul bridge, but I had thought the bridge would also be doable by replaying with pijul record.
But now my understanding is that other dvcs don't capture everything needed for a bijection. This is not a problem if it's just you -- you can use a wrapper script that does pijul record and git commit but other people may not be using your wrapper script.
Git cares about stuff that is flexible in pijul. Pijul records information that git is oblivious to. A mapping would need to be created or found.
@pmeunier knows more about this sort of thing, but I thought I would stake out a new discussion topic for it.
So, I started playing with libgit2 a while ago, and converting git commits directly into pijul patches (and vice versa) seems doable, but lossy sometimes.
If I manage to quickly hack together a prototype of this, would you be interested in working on it?
This is a bit late but I would be interested in working on improving a prototype. I'm currently trying to decide how best to convert an existing git repo to pijul and manually recording commits and losing the timestamps isn't that appealing of an option.
Ok, I was in the middle of uploading all my projects to the Nest again a few days ago (after the patch format change), but something broke at the same time, and I couldn't. I'll try to do it again today.
So I was playing around with this last night and discovered a very problematic issue with converting a git repo to pijul. Consider the following git commit history:
Lets iterate through the commits with a topological sort: A, C, D, B, E. The issue arises that commit B will not contain the changes at C and D, meaning that pijul will then undo those patches when B is checked out and a patch made since it will detect file modifications. I think this could be worked around by creating a diff with B and its parent but I don't think libpijul has a way to manually state what file modifications have happened. As far as I can tell that happens automatically. This also happens with new files that were introduced in C and D; commit B will no longer have those files and pijul will automatically delete them from the repo it seems.
Does pijul apply now exist sufficiently to serve as "manually state what file modifications have happened", or are the formats very incompatible?