<div dir="ltr"><div dir="ltr">Hi Jakob,<div><br></div><div>Sorry, I was delayed, getting caught up and finally swung back around to this thread..</div><div><br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I suppose many of us drawn towards Git instead of Monticello find Monticello<br>
lacking in not only minor ways. </blockquote><div><br></div><div>Like what?  Please don't say branches.  It supported it well-enough for the few times our small community used them. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The alternative or improvement needs not<br>
necessarily be Git, but given its acceptance in the wider developer<br>
community, it is an obvious choice. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
Chris Muller-3 wrote<br>
> For me,<br>
> it's not really anything about any "feelings" about Git as the<br>
> (im)practicality of integration.  It's a beast.  To bring a beast into<br>
> _everyone's_ workflow that has 90% more "stuff" than we need [...]<br>
<br>
What exactly do you think is so massive about Git? </blockquote><div><br></div><div>I wanted to grok git by approaching it via its public API.  With my new GraphQL expertise, I figured I could spank out a client prototype in an evening.  Then I found the schema:</div><div><br></div><div>   <a href="https://docs.github.com/en/free-pro-team@latest/graphql/overview/public-schema">https://docs.github.com/en/free-pro-team@latest/graphql/overview/public-schema</a></div><div><br></div><div></div><div>and the project was instantly shelved.  Why so many types?  I think due to the many "social" features that I don't really care about.  Monticello does everything I want in only a few pages of code.  It's easy to understand and has been relatively easy to extend, so I've stuck with it so far.  I'm not against Git, I just haven't been sufficiently interested by it yet.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The basics are really<br>
quite simple. The complexity comes with the vast number of possibilities to<br>
transform a graph of history, and canonical Git supporting many of them, but<br>
you do not have to do or support all of these. Other idiosyncrasies of Git<br>
can be simply omitted.  For example, you will not find anything about the</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
"index" or staging area of Git in the Git Browser tools. Git vocabulary is<br>
different from Monticello vocabulary (that is true for almost all pairs of<br>
version control systems) and Git has some different ideas of how tracking<br>
works and what to put in a single repository. But if you stick to the<br>
Monticello workflows and know the corresponding Git vocabulary, I contend<br>
that Git is not more complicated than Monticello. Fixing a Monticello<br>
ancestry is at least as complicated as doing a rebase ("advanced feature")<br>
in Git; after you have learned either, you can confidently wield either.</blockquote><div><br></div><div>A lot of extra, ignorable features, basically is the definition of over-engineered.  Don't get me wrong, it's a great tool for developers with your level of expertise.  I'm more of a "user", though, the extra stuff is harder for me.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">In other ways, Monticello just looks simpler because something is in fact<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
missing. Consider branches: most Git tools have knobs to deal with them in<br>
various ways, while Monticello tools just deny to talk about branches. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Monticello ancestry does support branching, yet I think Monticello lacks<br>
first-class objects for branches, with all the implications for repository<br>
handling. The tools might look simpler without branch management, but it is<br>
not a feature but rather the lack of one. Note that you can also avoid<br>
branch management in Git: just stay on the mainline branch forever and merge<br>
your commits back and forth with the upstream repository's mainline. While<br>
it might appear simpler that way, you might as well call it less organized.<br></blockquote><div><br></div><div>Support for branching was added to Monticello in 2012.  See MCVersionNameTest>>#testBranches.  Eliot used them during development of cog or spur, but I'm not aware of this feature having been all that critical for Squeak.  We tend to like just one master branch with occasional releases.  But, it's there and basically achieves the needed functionality.<br></div><div><br></div><div>That we were able to even add such functionality highlights one often-overlooked advantage of maintaining control over one's own software destiny.  I guess this isn't the case with Github, and yet the demand for more features from the diverse hoards of developers requires it to be all things to all of them.  Hence, it's beastly complexity.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Chris Muller-3 wrote<br>
> [...] requires<br>
> them to sign up just to use -- I think it would be a "filter" on the<br>
> community, especially of non-developers (hint:  You and Jakob are<br>
> developers).  For me, being hosted by a private company is not so<br>
> attractive.<br>
<br>
As Phil pointed out, you seem to confuse Git with GitHub here. But your<br>
arguments are applicable if we take the integrated issue tracker into<br>
account because that needs to be run by someone. In theory Squeak could host<br>
an own GitLab Community Edition server instead of relying on GitHub.<br></blockquote><div><br></div><div>I thought the social benefits (exposure and growth, I guess) were via exposure to the github user base.  If we hosted ourselves, would it be any different than the "deserted island" situation we have now?  That's all what I was referring to.  I thought the purpose was for the exposure.  If you have to host yourself anyway then we're basically down to a tool comparison?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Chris Muller-3 wrote<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> For example, you could submit an<br>
> improvement that allows original contributors of Inbox items to move them<br>
> to Treated themself.<br>
<br>
How? Only Trunk committers have access to the Squeaksource treating backend,<br>
so neither the code nor the tool is available to normal users for<br>
improvement. Guest users cannot even delete versions from the inbox<br>
repository, can they?<br></blockquote><div><br></div><div>It's public read, anyone can access the code and submit improvements to the Inbox.  But, I agree, it'd be nice if there were a way for strangers to contribute more obviously.  One idea would be for each SqueakSource repository to have it's own internal "Inbox" Repository to support some of these features...</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Chris Muller-3 wrote<br>
> You could add a button to filter out all entries in<br>
> the Inbox which have further descendants also in the Inbox.  You could<br>
> make<br>
> an, "update from Inbox" which would only download packages for which have<br>
> your loaded versions as ancestors.<br>
<br>
I don't understand how these would help in the tracking of issues, can you<br>
elaborate please? My understanding: The first shows you the tips of all<br>
loose branches in the inbox, but still without a mapping to issues (which is<br>
not necessarily a 1:1 mapping, with reinforced complexity because of the<br>
drive towards a compact ancestry...). Combined with some client-side<br>
extensions it might allow us to track branches locally, but not share them<br>
explicitly. To find remote branches, you would have to download many of<br>
these versions first because only then you can access their ancestry (you<br>
don't know in advance which versions are the tips, and combined with the<br>
redundancy among versions, this is a Monticello implementation flaw). The<br>
second would allow an update if someone moved some of your own branches<br>
forward. But it rarely happens nowadays.<br></blockquote><div><br></div><div>Yes, these are just loose ideas conjured in 10 seconds.  The point is Monticello is relatively small, simple, and malleable, and this makes it feasible to improve, even if getting it implemented requires writing email.</div><div><br></div><div>Monticello does suffer from some scalability issues that will eventually need to be addressed.  But the redundancy among versions is a feature, not a flaw.  To this day, planes have poor internet access, this redundancy is about availability.  In the Magma-based, there is only one instance of each MCDefinition shared amongst all Versions, but not everyone set that up on their laptop (I made it as easy as I could).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Chris Muller-3 wrote<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> We have *decades* of Monticello packages for Squeak across not just our<br>
> own<br>
> repositories, but many other "external" legacy repositories. [...]<br>
> Monticello will continue<br>
> to be used by some.  <br>
<br>
In my opinion this is no argument against different tools because nobody<br>
suggested to remove Monticello from Squeak. </blockquote><div><br></div><div>I agree.  It wasn't meant to be an argument against anything.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">As we already see in practice,<br>
Git tools and Monticello tools, as well as both kinds of repositories, can<br>
co-exist.<br></blockquote><div><br></div><div>Great!  Please don't mistake my lack of interest as "opposition".</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Chris Muller-3 wrote<br>
> It seems clear that the only path to Git and other<br>
> tools is a backward-compatible integration with existing tools<br>
<br>
Well, other paths have already been walked. ;-) But in which direction goes<br>
this backwards- compatibility? Do you want be able to use newer tools also<br>
on old repositories? Alright, that would be nice. Do you want to be able to<br>
use newer repositories in old tools? Why, given that it will probably<br>
restrict the newer repositories?<br></blockquote><div><br></div><div>What I had wanted to do start by sucking in their GraphQL schema into my fantastic new GraphQL Engine, and map their types to the Monticello types.  Basically appear to BE a Git server, but mapped behind the scenes to legacy MC repos that could be accessed via the legacy way, for users that wanted to.</div><div><br></div><div>Alas, the schema is longer than <i>War and Peace</i>.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Chris Muller-3 wrote<br>
> a "stepping<br>
> stone" that doesn't require a major adjustment like losing method-level<br>
> timestamp information.<br>
<br>
This seems to confound the use of Git with the use of the Tonel format with<br>
a Pharo-style implementation.<br>
<br>
Otherwise it affirms what I wrote a few messages before: maybe we do have to<br>
bite the bullet and write a proper MCGitRepository that molds Git-hosted<br>
projects into the Monticello tools, even though we have already created<br>
other tools.<br></blockquote><div><br></div><div>If you're interested in collaborating on my above idea of hosting our own server based on their v4 GraphQL API, but with an MC+ backend, I believe my GraphQL engine is ready.  If you know the essential parts of the Git model well enough to know how to hook it up to a MC backend, I could fully support the GraphQL parsing and processing aspect.  Email me if you're interested.</div><div>
<br>
</div><div> - Chris</div></div></div>