I had a quick look at the git-migration code. From what I saw, it binds all packages together in a linear history. Though the versions are topologically sorted by the Monticello ancestry, this approach cannot preserve any branches, or parallel changes, as Nicolas noted. Thus, it produces wrong diffs. Though, it is perfectly adequate for most one-person projects or projects with a Subversion-like commit policy ("you must always merge newer versions before you save"). I guess that is the majority of Monticello projects.
For the converter in Squot, I chose to write one strand of commits for each package, ending in a branch. The history on each strand maps the package's Monticello ancestry accurately (except that the diffs for missing versions are still missing). But it is not appealing to work with each package on a different branch, of course. Unless you have Monticello configurations, that's all the model provides, is it? You can still get an idea of the inter-package history by viewing the log sorted by author timestamps ( --author-date-order https://git-scm.com/docs/git-log#git-log---author-date-order), but you cannot really bisect it, for example.
What I did in my repositories so far is import the packages on separate branches and then create an n-way merge (with the command line tools) that pulls all the packages together from the point on when I established the Git repository.
Binding the packages together in a common history needs some kind of heuristic that guesses the past configurations that were in use. For example, timestamps and authors could be used. Let's say contributors abc and xyz worked on some project in parallel and created versions in multiple packages. Then you could assume that PkgX-abc.8 and PkgY-abc.42 with similar timestamps belong to the same branch, while PkgX-xyz.8 (with the same parent as PkgX-abc.8) and PkgZ-xyz.5 with similar timestamps belong to a different branch. There will most certainly be scenarios where the heuristic breaks. For example, when the change in PkgZ-xyz.5 is also relevant for abc's work and she "invisibly" adopts it on her "branch" in Monticello. Or when abc works on her branch and then must quickly fix a bug on whatever "master" in Monticello is, but modifies a different package there (so you cannot see the "switch" in the ancestry).
So the one-nonlinear-branch-per-package approach is unwieldy, but at least it is does not produce incorrect results until someone comes up with a better solution. As written above, the git-migration approach is fine for one-person or branch-less projects.
Am So., 3. März 2019 um 09:23 Uhr schrieb Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:
Le dim. 24 févr. 2019 à 21:19, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> a écrit :
Hi Doru,
Le mar. 19 févr. 2019 à 10:39, Tudor Girba tudor@tudorgirba.com a écrit :
Hi Nicolas,
On Feb 18, 2019, at 3:12 PM, Nicolas Cellier <
nicolas.cellier.aka.nice@gmail.com> wrote:
Also note that vmmaker history as proposed in opensmalltalk pr was
broken (no respect of branch topology). Maybe retry with Squot?
https://github.com/hpi-swa/Squot There is still a problem of synching commits of other packages (cog,
various plugins ...), and if nobody is working on it, we are condemned to a mediocre solution.
IMO, a broken history has not much interest.
We know it was broken, and thank you for pointing it out. We went through multiple iterations, and we think the latest one should be better. Please take a look and let us know if you still find issues: https://github.com/feenkcom/opensmalltalk-vm/tree/pullrequest5/vmmaker
Ah OK, I'll try to have a look.
Hi Doru, as follow up, I don't see the progress in package history. If I look for example at history of ThreadedFFIPlugin, then I see this:
https://github.com/feenkcom/opensmalltalk-vm/commit/2ec3b0f6da1a5c7801f7ce89...
Normally I should see only one diff, like this:
http://source.squeak.org/VMMaker/VMMaker.oscog-nice.2109.diff
This is because true parent is VMMaker.oscog-eem.2108 But git parent is VMMaker.oscog-eem.2109 So it seems like I am undoing all the changes from Eliot... Thats is obscuring the intentions of the commit.