without Monticello file back-end no?
No, in fact it's very much dependent on Monticello filetree back end. This backend has the granularity which allow a use of git querying / fetching facilities to the level associated with changesets.
I could implement a use of a gitfiletree:// repo as a complete replacement of a live changeset + monticello repository in one, if needed.
Still wondering if this is the way to go.
I think it is a very good start :), eventually we have to come up with second version of the filetree format as the current one has a major limitiation: categories are stored in the method source Impact: - md5 hashes of the pure ST method sources do not correspond the md5 hashes in the git repository - each file-in requires another strip-the-category-path of course there are workarounds for that. Additionally I would love to have a filetree version that doesn't store all this MC metadata. The changes in these files generate so much noise that is it hard to see the actual changes. Anyway, most of it is future talk, I guess the current approach will work :) Though I wonder what we will do once we have custom slots :/. I guess we need some hacks to make that run on top of Monticello.