Hey!

Just for fun, I parsed that schema to see if it would help looking at it in
a Squeak ObjectExplorer.  Mmmm.. a little, but not really...  It's the
sheer volume, check out the attached screenshot.  I looked for something
basic sounding, and came across "User".  Look, it has 64 fields!  :-o   And
this is just one of 978 types in total.  If you can figure out which of
these to map to Monticello's 40 (or whatever it is) types, you could use
this parser and Engine in combination with WebServer to host a Git server
with MC backend..  MC users could ignore git, while Git users could ignore
MC.    :-D

To me, it looks very intimidating, though...

[image: Git-parsed-GraphQL-schema.png]

On Mon, Oct 5, 2020 at 1:47 PM Jakob Reschke <forums.jakob at resfarm.de>
wrote:

> Hi Eliot,
>
>
> Eliot Miranda-2 wrote
> >> On Oct 4, 2020, at 6:14 PM, Jakob Reschke <
>
> > forums.jakob@
>
> > > wrote:
> >>
> >> In other ways, Monticello just looks simpler because something is in
> fact
> >> missing. Consider branches: most Git tools have knobs to deal with them
> >> in
> >> various ways, while Monticello tools just deny to talk about branches.
> >> Monticello ancestry does support branching, yet I think Monticello lacks
> >> first-class objects for branches, with all the implications for
> >> repository
> >> handling. The tools might look simpler without branch management, but it
> >> is
> >> not a feature but rather the lack of one. Note that you can also avoid
> >> branch management in Git: just stay on the mainline branch forever and
> >> merge
> >> your commits back and forth with the upstream repository's mainline.
> >> While
> >> it might appear simpler that way, you might as well call it less
> >> organized.
> >
> > Monticello supports branches.  And merging between them is as easy as
> > merging any other version of a package.  And Monticello does support
> > recording histories across branches.
>
> That is what I wrote: Monticello ancestry does support branching. But there
> is no list of branches and there is no object for a branch. Instead one has
> to find the loose ends in a sea of versions. Chris's first tool suggestion
> would alleviate this, but it may be quite expensive and would still not
> give
> names to branches.
>
> Anyway, to have branches was not what Christoph and I were after. Topic
> tracking and integrated conversations it is.
>
>
> Eliot Miranda-2 wrote
> > The two things that Monticello has over git are
> > - that it is used without leaving the image.  I’ve yet to see a git
> > integration where at some stage one was forced to try and fix things in
> > git, or that the image and the git repository got out of sync, or that if
> > one tried to use more than one image against a git repository something
> > horrible broke
> > - that it can be extended using our own tools.  Git is written in C and
> > controlled by a separate community.  One gives up great autonomy when
> > allowing ones core VCS to be in a foreign system.  When git crashes it
> > crashes.  It doesn’t raise a friendly debugger in which one can determine
> > and fix and proceed from the bug, it segfaults, in optimized code, and
> > you’re hosed.
>
> I can see your point. Although I cannot remember seeing Git crash for me in
> the last ten years. And we are in a serious lock-in if we extend this
> notion
> to everything in the world. I'm glad the other programming languages did
> not
> all have to implement their own VCS first, otherwise there would be even
> more of these around.
>
> Luckily, we already have a Git implementation in Smalltalk. Thank Tobias
> for
> urging me to salvage this rather than concentrating on FFI and libgit2
> three
> years ago. The Git Browser tools are as Squeak as they can be for dealing
> with Smalltalk packages. Except maybe that the Git repository is still
> stored outside, but what is a commit worth if it gets trapped in an
> unsaved,
> unexpectedly broken image.
>
> Even if we didn't have this Smalltalk implementation, the canonical Git has
> lots of plumbing tools that could be controlled via OSProcess to query and
> manipulate repositories. It wouldn't crash the VM like errors in libgit2
> might, at the cost of being much slower.
>
>
> Eliot Miranda-2 wrote
> > Personally I don’t want to work in that kind of world.  The Pharo crowd
> > do.  I will do everything in my power to prevent Squeak going the same
> > way.  And if I’m unsuccessful I’ll go somewhere else.
>
> Understood. I don't wish to see you leave.
>
> Yet in my opinion Squeak really needs to get along with the outside world
> for the mutual benefit; we cannot afford to always reimplement everything
> in
> Smalltalk just to be able to comfortably debug the issues we wouldn't have
> if we had used something mature.
>
> Originally this thread was about the development process and how it can be
> improved. Sorry for drifting into the Squeak vs. the World discussion
> again.
> Some things just trouble me and make me sad.
>
> Kind regards,
> Jakob
>
>
>
> --
> Sent from: http://forum.world.st/Squeak-Dev-f45488.html
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20201008/455f4bc4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Git-parsed-GraphQL-schema.png
Type: image/png
Size: 202806 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20201008/455f4bc4/attachment-0001.png>