Joshua, > > What the Etoys team actually uses for our own change management is > > called "update stream" mechanism. That is a sequence of small patches > > in text. These patches are kept on an FTP/HTTP or WebDAV/HTTP server, > > and the developers submit the patches via FTP or WebDAV, and other > > users and developers fetches them via WebDAV or HTTP into their EToys > > image. The image in the git repository is made in this way. 95% of > > the case, it is enough to recreate a "practically" identical image by > > merely fetching the patches. > > 95%? Just curious, why not 100%? 5% is guesstimate (of course), but for stuff like changing the update stream mechanism itself or the ".changes file" management, changing the class hierachy around String, or the change that relying on some external file such as fonts, are something I would do in more controlled ways. (With more careful tweaking these things are usually possible with the update stream mechanism, but...) > > These small files are the result of "real development work" and > > should probably be kept as the record. > > Agreed. > > I think the proper way to do that is to clean the upgrade directory > after each commit so that the upgrade directory only keeps patches for > the current changeset. I'm not sure what is the upgrade directory, so not sure the upside of this is. Can you elaborate? > I'm going to CC the GIT mailing list just to > make sure since you could get stuck with this history for a long > time. Ah, ok. Hi, Hamano-san^^; -- Yoshiki - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html