There is obviously some kind of resentment and tension unrelated to this thread.

If the result is that we can't dicuss possible solutions, then it's bad, because this is an important point.

What happens if two concurrent commits modify the same method but not the same lines?

Is it a conflict like in MC?

If yes, then there is nothing stopping the last author/timestamp metadata to be included in source files (either directly or in a sister file).

The problem we had previously with metadata was that it did include history which necessarily conflicts...

(Or not, there was a viable specific merge developped for that case, may I remind https://github.com/ThierryGoubier/GitFileTree-MergeDriver)

Also the format was not adequate initially (single line in the eyes of git).

Author and timestamp are somehow redundant with git own metadata...

Or not if there are exchange with other flavours an other backends.

The very first exchange is the one way conversion to iceberg which magically erase all the metadata.

Please note that these data are not temporary lost but definitely, so it's indeed a sacrifice.

Then if I pick a method verbatim from Squeak to Pharo or Pharo to Squeak, that doesn't make me an author.

If I wish to maintain cross compatibility for a library that means exchanging too.

Minimizing the existence of such libraries or the will of maintainers is like counting a whole part of this community for nothing.

If I speculate on the intentions, which is a bit dangerous in such explosive atmosphere,

what are the plans for restoring the most elementary features of a VCS that are authorship and history?

Use git data exclusively?

2018-01-13 17:52 GMT+01:00 Ben Coman <btc@openinworld.com>:

On 13 January 2018 at 20:12, Norbert Hartl <norbert@hartl.name> wrote:
>>
>> Am 13.01.2018 um 12:39 schrieb Eliot Miranda <eliot.miranda@gmail.com>:
>>
>> On Jan 13, 2018, at 2:08 AM, Stephan Eggermont <stephan@stack.nl> wrote:
>>>
>>> Git support turns out to be much more work than we hoped and expected. Too
>>> many library updates needed, support for different workflows and platforms,
>>> switch to file per class. The Iceberg channel on Discord is one of the
>>> busiest channels.
>>
>> You don't say?�� One of Cl��ment's themes in recent talks on VM performance is
>> that we, as a very small team, are able to develop such a sophisticated
>> optimizer because we use Smalltalk.�� We are hugely productive in the vm
>> simulator.�� People using Smalltalk, including the Pharo, Squeak and Cuis
>> dialects that constitute our community, report the same in many different
>> domains, notably Bloc, GT Toolkit and Rossal.
>>
>> Then why on /earth/ would one stop using Smalltalk in /the most central
>> part/ of the collaborative programming process, version control?�� This is a
>> huge blunder.�� Now a major part of the Pharo community's efforts goes into
>> an external component, upon which Pharo is entirely dependent, and slowly
>> but surely it is cutting itself off from its sibling communities.�� Iceberg
>> is well named.�� People rearranged the chairs on deck while the Titanic sank.
>
> Can we agree that a class/method/�� stops being smalltalk after it has been
> serialized to text?

I sure Eliot referred to the external C library of libgit2
regarding stepping outside of the Smalltalk environment.
Its the root source of the segfaults that is killing the reliability.

> If you can agree to this I don��t know what you are
> talking about. We exchange the to-text-serializer monticello-backend with
> git-backend. The rest (the important part) stays nearly the same. The
> exchange is necessary because the possibilities of collaboration are limited
> when using monticello only. So what would be the alternative?

The alternative would be a Smalltalk implementation of git.
This would surely reduce segfaults and make debugging easier with a
wider pool of contributors.
The downside would be tracking the evolution of git.�� Perhaps when
libgit2 was selected the balance
was foreseen in its favour.�� However with current experience perhaps
this balance is worth review.

For POC, here are some other language native implementations of git...
http://www.eclipse.org/jgit/
https://github.com/jelmer/dulwich
https://github.com/mirage/ocaml-git
https://github.com/danlucraft/git.js
https://github.com/henon/GitSharp

THIS ARTICLE is really informative...
http://stefan.saasen.me/articles/git-clone-in-haskell-from-the-bottom-up/
Can anyone here familiar with Haskell help with converting those code
examples to Smalltalk?

@Eliot, Given that Pharo is likely to continue down the git path, how
interested do you think the Squeak community
would be in a Smalltalk implementation of git to facilitate future
collaboration.
Maybe the question could be raised there separately?

@Juan, IIUC Cuis already primarily uses git for Smalltalk source code
management.
How is this currently done and would you partake in a Smalltalk
implementation of git?

> There are even a lot of people that don��t like git (including me). But I
> like the collaboration model because that can do what no smalltalk tool can
> do to my knowledge.

Simply we either stay the same;�� Or we move.�� Moving does risk that a
wrong path is started,
or we go a long way round, but even on a non-optimal paths much can be learnt.
Pharo zen is "Learning from mistakes."�� and while I don't believe
libgit2 was a mistake
since it allowed Iceberg development to start�� at a higher level,
perhaps replacing it with a native Smalltalk implementation is worth a trial.
Some subparts of this might make a good GSoC project (?)

cheers -ben

P.S. No-one has mentioned the "content addressable" nature of git
which I believe
is the *real* paradigm shift in VCS that we should pursue.�� With a
CompiledMethod referencing
a hash of its method-source rather than a location in a particular
file on a filesystem,
opens the possibility of a dozen different providers for locating that
method-source that
are all equivalent and substitutable with one another for maintaining
compatibility between Smalltalk dialects.
The hash could reference a "git object" of that hash, or an entity on
IPFS (https://ipfs.io)
or http://my.simpleServer.com/methodhash.