git, packages, and package dependencies (also migration from sthub to git)
Hi, after many-o-hours spent on my git-migration tool ( https://github.com/peteruhnak/git-migration ), I've concluded that the migration cannot be properly done for packages. In mcz/monticello, every package has an independent history and can change independently of each other. In git, this history is merged into a single hierarchy, therefore: * a specific version of package A mandates specific versions of every other package in the project * it is not possible to do a 1:1 migration from mcz to git and keep this flexibility Both ways (mcz and git) have advantages and disadvantages of their own, however as far as I could tell, they are incompatible; so mcz flexibility and some information (history) will be lost during migration. The only solution I see is to either separate every package to a separate git project to keep the flexibility or use git subtree/git module... which are both complications... As a git commit specifies the code in the entire project, even across packages, then I wonder what is the point of expressing package dependencies _within_ the project (whether in BaselineOf or Cargo). Peter
On 1 July 2017 at 13:28, Peter Uhnak <i.uhnak@gmail.com> wrote:
In mcz/monticello, every package has an independent history and can change independently of each other. In git, this history is merged into a single hierarchy, therefore: * a specific version of package A mandates specific versions of every other package in the project * it is not possible to do a 1:1 migration from mcz to git and keep this flexibility
Did you ever use that feature (to achieve something precise, not just because it's here)? The only solution I see is to either separate every package to a separate
git project to keep the flexibility or use git subtree/git module... which are both complications...
Yes, it's a pain⦠might be useful in some cases but I think most of the time versioning each package of a project independently is just cognitive noise. As a git commit specifies the code in the entire project, even across
packages, then I wonder what is the point of expressing package dependencies _within_ the project (whether in BaselineOf or Cargo).
Load order? -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
On 01-07-17 14:22, Damien Pollet wrote:
Yes, it's a pain⦠might be useful in some cases but I think most of the time versioning each package of a project independently is just cognitive noise.
No, it is essential complexity in most cases. As soon as independent teams/people make changes you need to split projects up. How to do so to get the least friction is left as an exercise to the reader (see Parnas) Stephan
On Sat, Jul 01, 2017 at 02:22:53PM +0200, Damien Pollet wrote:
On 1 July 2017 at 13:28, Peter Uhnak <i.uhnak@gmail.com> wrote:
In mcz/monticello, every package has an independent history and can change independently of each other. In git, this history is merged into a single hierarchy, therefore: * a specific version of package A mandates specific versions of every other package in the project * it is not possible to do a 1:1 migration from mcz to git and keep this flexibility
Did you ever use that feature (to achieve something precise, not just because it's here)?
Well the implications are more problematic. Imagine you have pkg A, with commits A1,A2,A3. Now you are in A3 and you create a new package (B) and commit it (B1, which has A3 as a parent). Then you move back in history to A2, or you create A4 (as a child of A2) -- package B no longer exists. So you cannot go back in history for any package without affecting the rest of the packages. I think this is a cognitive shift for people switching. And practically speaking if you want to go back for just a single package you have to cherry pick, which is error-prone. (none of this is problem for me, as I've been using git in Pharo for a long time, but more shining light on the impending issues for people now switching)
The only solution I see is to either separate every package to a separate git project to keep the flexibility or use git subtree/git module... which are both complications...
Yes, it's a pain⦠might be useful in some cases but I think most of the time versioning each package of a project independently is just cognitive noise.
As a git commit specifies the code in the entire project, even across
packages, then I wonder what is the point of expressing package dependencies _within_ the project (whether in BaselineOf or Cargo).
Load order?
Ah, right.
-- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
On 1 July 2017 at 13:28, Peter Uhnak <i.uhnak@gmail.com> wrote:
after many-o-hours spent on my git-migration tool ( https://github.com/peteruhnak/git-migration ), I've concluded that the migration cannot be properly done for packages.
Let us hope this effort can be salvaged!
In mcz/monticello, every package has an independent history and can change independently of each other. In git, this history is merged into a single hierarchy, therefore:
Git does not strictly require you to put all of your commits into a single hierarchy. You can also have multiple root commits in the same repository i.e. multiple parallel hierarchies of commits. Then you can combine these together with merge commits if/when you want to have them in the same tree (afaik.) See 'git commit --orphan' for introducing a new root commit into the repo. So thinking aloud... Perhaps for each package could you create a dedicated branch (A, B, ...) with its own root commit? This way each package would have a distinct history on its private branch and not be prone to collisions. If you want to combine multiple packages into one tree then you could create a new branch (A+B) that merges the required per-package branches (which remain isolated and pristine.) Just an idea -- sorry if I have misunderstood your use case, and let me know if this idea requires more explanation. Cheers, -Luke
Hi Luke, On Sat, Jul 01, 2017 at 03:43:35PM +0200, Luke Gorrie wrote:
In mcz/monticello, every package has an independent history and can change independently of each other. In git, this history is merged into a single hierarchy, therefore:
Git does not strictly require you to put all of your commits into a single hierarchy. You can also have multiple root commits in the same repository i.e. multiple parallel hierarchies of commits. Then you can combine these together with merge commits if/when you want to have them in the same tree (afaik.)
See 'git commit --orphan' for introducing a new root commit into the repo.
I don't really see a difference between having orphaned branches and regular branches starting from the initial commit.
So thinking aloud...
Perhaps for each package could you create a dedicated branch (A, B, ...) with its own root commit? This way each package would have a distinct history on its private branch and not be prone to collisions. If you want to combine multiple packages into one tree then you could create a new branch (A+B) that merges the required per-package branches (which remain isolated and pristine.)
Just an idea -- sorry if I have misunderstood your use case, and let me know if this idea requires more explanation.
I do understand what you have in mind, however one aspect I didn't mention is usability. People are already complaining (for whatever reason that I do not understand) that git is too complex. And doing this kind of shenanigans with branches will certainly add extra complexity. Also as I've mentioned neither of workflows (MCZ or git) are best. With git having packages depend on commits of another packages can be a good thing (because realistically packages in a project do depend on each other). But maybe a solution for migration itself would be to strictly separate the package histories, and then in master branch perform merges based on ConfigurationOf versions... and the last commit on master would merge all the branches according the the current dev state. Or maybe I am really overthinking this and nobody actually cares about proper migration of their history. :) Peter
Cheers, -Luke
On 3 July 2017 at 11:09, Peter Uhnak <i.uhnak@gmail.com> wrote:
People are already complaining (for whatever reason that I do not understand) that git is too complex. And doing this kind of shenanigans with branches will certainly add extra complexity.
Could be simpler to think of it as each package having a separate repository with an independent history. Then you cannot have any conflicts from one package on another. This is equivalent to Monticello, right? Then if you want to combine multiple packages together then you would create a new repo that merges each package that you care about. Once you update packages this repo could either be updated (add more merge commits) or replaced (recreate from scratch with the versions you really want.) This is equivalent to Metacello, right? The orphan commit trick is then simply a way to multiplex as many "logical" repos (for Monticello packages or Metacello configurations) into the same actual Git repo (as branches with separate roots.) However -- Can still be that I am misunderstanding the overall goal here. Or maybe I am really overthinking this and nobody actually cares about
proper migration of their history. :)
One thing that I care about, and am a bit surprised that nobody else apparently cares about (?), is being able to snapshot all sources/dependencies in one file/directory/repo/etc that can be loaded from a local file without crawling the internet. Could importing projects into a Git repo that Metacello accesses be a solution? (Or is there already a way today that I am missing?)
participants (4)
-
Damien Pollet -
Luke Gorrie -
Peter Uhnak -
stephan