Philippe,
You are not a party pooper ... these are exactly the kinds of questions I'm looking for They are excellent questions.
I'm going to highlight several of your points and then answer:
"keeping the Monticello and git metadata in sync. For example since it's still Monticello there has to be all the Monticello metadata which is laying around in "strange" files ... makes it quite unlikely that you can edit the source with a text editor and not screw up the Monticello metadata."
"If you'll just be using it through the in-image tools why bother with a nice source layout at all?"
"And a lot of information is duplicated."
"If you embrace git then why not go for a source format that you can actually edit with a text editor like [3] and use all the git metadata (author, timestamp)?"
"If you embrace Monticello then why bother with git at all?"
I'm going to address your last point first, since everything else follows from that... I think...
Why bother with git at all?
Monticello versions individual packages (source files), it is not an SCM[1]. In many respects Monticello is closer to RCS[2] than Git[3].
Git manages versions of entire directory structures...making it possible to version collections of packages along with the entire range of ancillary files that are typically required for modern software development.
Monticello manages versions of a single package. A single file.... If you find yourself needing to do anything beyond managing a single mcz file, Monticello does not help. Need I say more?
Why bother with Monticello at all?
When it comes to image-base development Monticello's declarative model (i.e, definition snapshot) is a REQUIRED component.
If you can afford to file in code fresh every time you start an image (non-image-based development), then you don't need to monkey with snapshots, because when you REMOVE a method from a file, it will not be present the next time you file in the source.
In image-based the development, the act of REMOVING a method from a file is not sufficient ... you have to arrange to physically remove the method from the image as well. The Monticello snapshot manages the bridge between Smalltalk source and the image quite well.
Synthesis of Monticello and Git
The idea then is to preserve the Monticello snapshot (required for image-based development) while taking advantage of Git (required to bring modern SCM capatabilties to Smalltalk).
BTW, Git does a great job of tracking file identity and file history ... Putting a single method in each .st file, it is possible to track the revision history of a single method as it is moved form package to package and class to class ... pretty cool...
Monticello Meta Data
The 'package' file can be eliminated with no loss of information.
The 'version' file is kept in order to allow one to explicitly preserve package ancestry (package author, timestamp, UUID, ancestry, etc.). The project maintainers should be given the option to preserve package ancestry. If the maintainers decide to preserve the package ancestry, then they can make informed decisions when doing merges. If they choose to not preserve the package ancestry, then it should be safe to remove the 'version' file. Issue 2[5] and Issue 6[6] for the filetree project covers the thinking in a bit more detail.
The method author/date timestamp information is kept (for the moment at least) because the MCMethodDefintion>>= uses the timstamp, until the Monticello logic can be changed (in GemStone, Squeak, and Pharo) it makes sense to continue to use the timestamp [7].
If I'm not mistaken this covers the redundant data and the 'strange' files.
Summary
This project isn't about replacing SqueakSource...this project is about bringing the power of git to Smalltalk development and leverage github for the features that far surpass anything that we have in Smalltalk[8][9][10][11][12][13].
BTW, Git is not the only target. The mapping of Monticello/Metacello to disk is SCM neutral. SVN or mercurial can be used just as easily with the proposed disk format.
I suggest that git/github is a good choice for the Smalltalk community at large, but it isn't a requirement.
Dale
[1] http://en.wikipedia.org/wiki/Software_configuration_management [2] http://linuxcommand.org/man_pages/rcs1.html [3] http://en.wikipedia.org/wiki/Git_(software) [4] https://github.com/dalehenrich/sample/tree/master/core/Sample-Core.pkg [5] dalehenrich/filetree#2 [6] dalehenrich/filetree#6 [7] finworks/smallsource#12 [8] https://github.com/features/projects [9] https://github.com/features/hosting [10] https://github.com/features/community [11] https://gist.github.com/ [12] http://pages.github.com/ [13] http://developer.github.com/