On Sat, Jul 01, 2017 at 02:22:53PM +0200, Damien Pollet wrote: > On 1 July 2017 at 13:28, Peter Uhnak <[email protected]> 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
