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