<div dir="ltr"><div dir="ltr">Hi Christoph and Jakob,</div><div dir="ltr"><br></div><div dir="ltr"><div>> Now since Squeak does not switch to Git (given the feelings of several prominent people here towards Git)</div><div><br></div><div>Hmm, that doesn't sound quite right.  What I sense are such (positive) "feelings" TOWARDS Git in some members, it has them wanting to use <u>that particular tool</u> (vs. other tools or solutions which could also address the community's needs, i.e., see below).  I sometimes think "the tool"  and the associated "popularity" is the end-goal in and of itself, rather than the output artifact.  Please pardon me if I'm mistaken about that.  For me, it's not really anything about any "feelings" about Git as the (im)practicality of integration.  It's a beast.  To bring a beast into _everyone's_ workflow that has 90% more "stuff" than we need, and requires them to sign up just to use -- I think it would be a "filter" on the community, especially of non-developers (hint:  You and Jakob are developers).  For me, being hosted by a private company is not so attractive.</div><div></div><div><br></div><div>I do think some of these issues you describe with the Inbox contribution process are shallow enough they could be largely mitigated with simple upgrades to our existing tools.  For example, you could submit an improvement that allows original contributors of Inbox items to move them to Treated themself.  You could add a button to filter out all entries in the Inbox which have further descendants also in the Inbox.  You could make an, "update from Inbox" which would only download packages for which have your loaded versions as ancestors.  There are many simple things that could be done.  A bug-tracker is a bigger deal, but it's often a lot less overhead to just FIX the bug than open, track, and close a bug report.  We do have Mantis to keep track of the longer-term bugs.</div><div><br></div><div>But, again, this is "not Git", which seems to be the desired "feature".  :/</div></div><div><br></div><div>We have *decades* of Monticello packages for Squeak across not just our own repositories, but many other "external" legacy repositories.  (i.e., see the "repositories" category of Installer class side).  Obviously, our tools and methodology will be an on-going discussion, but I don't see this legacy ever going away completely, no matter what we do, Monticello will continue to be used by some.  It seems clear that the only path to Git and other tools is a backward-compatible integration with existing tools, a "stepping stone" that doesn't require a major adjustment like losing method-level timestamp information.  But it's not going to write itself.  Only the burning interest within people like you and/or Jakob will get it done.  :)</div><div><br></div><div> - Chris</div></div>