First lets get a basic understanding of git, filetree and metadata. The process of using both filetree and git are simple and short , the only problem is Monticello with a GUI that is not well designed.
With filetree you do what you would have done anyway 1) You pick a package 2) You create a filetree repo for it 3) You tell to filetree where to save your files 4) You edit/add code 5) You tell filetree to save your files In another language you would have done something similar using an IDE 1) Create a project 2) Tell to the IDE where to save your project 3) Create new source files 4) edit code in those source files 5) save those source files Git is also very simple , git is a version control system which basically what it does is create a history of changes (= versions) which calls commits , it also allows you to have versions of your history which calls branches which are basically variations of the same project and you end up with a nice history tree Git has 3 basic actions , push, pull and commit The first thing is pull which what it does is that it pull from another git repo, usually this is a github or other online repo used as the main repo but it can be also local too. In a pull git does again what you would expect , it takes a look at the history of the other repo and the history of the repo you want to pull to and first makes sure that the repos do not contain different histories. If they do then git ask 2 logical questions 1) Are these commits just additional commits that the receiver repo does not have ? If yes then just bring this commits and add them to the receiving repo history 2) Are these commits not only additional but also in between , which means they can be the commits for example no 1, 6 , 23 , 45 and 64 ? if yes then I do not know what to do , alert the user there are conflicts, which commits do conflict and exactly which code and which source files git commit just add commits to your repo history. git push does the opposite of git pull its sends your commits to the other repo but again it asks those two questions There is also git clone which basically creates a repo and git pulls from another repo This means that conflicts cannot exist , under usual circumstances, for single user repos. Because a user cannot create randomly diffirent commits in his/her own repo unless she works from different computers and forgets to git pull and thus creates different histories. Commits appear when you have multiple people with their own repos pushing to the same repo, in that case its much easier to create conflicts. However it may surprise people that if you remove the metadata you will not greatly reduce git conflicts. What greatly reduces conflicts is first to always remember to git pull BEFORE adding new commits , this way there is less chance for histories to go out of sync and of course having small teams. The less people the less chance to create conflicts. A way around this is to make branches or forks, it does not actually solve the problem. A branch as we said is a version of the history of a repo and it evolves separately. A fork is basically another repo that has its own history and also of course its own branches. Both branches and forks can merge with another history at any point along the way, still they will have conflicts. The big diffirence here is that you deal with those conflicts only when you do that merge (in the case of a fork we call it "pull request" because you request from another repo to pull your commits). So basically what you do is delay the inevitable. If you work alone you don't need to worry about conflicts and thus not need to worry about metadata. There is very little chance to cause conflicts , close to zero. if you work as a team, conflicts will be more and more frequent , the less properly your teammates use git, aka forget to git pull and push often, thus metadata will end up being the lest of your concerns. Basically because metadata are just information about your code and your project, there is nothing really complex about it and thus a conflict with metadata will be a minor concern. A conflict on the code on the other hand is a big deal, if your teammate forgets to git push and pull often , there is also a big chance he does an even bigger mistakes and commits less often. This is a huge deal because that means his commits will contain huge chunks of code which in return will make conflict resolution a nightmare. Again the problem does not originate from git or filetree , the problem is understanding the code and making sure that what you merge which basically means you decide which code is rejected and which is accepted inside the history is code that works, is reliable and does not create a stream of bugs and mostly does not take your project backward instead of forward. So complexity is multiplied much more by the human factor and much less from the technology factor. A work around this is to use powerful git tools that make some common decisions for you and help you understand those conflicts , but in the end conflict resolution is an art and a science by itself and its directly related on how well you understand not only the code of the project itself but also the code others provide. Why all this lengthy post ? I am not saying you do not know all this, I have no means to know what you do or what you do not know . My purpose is to make sure people reading this post realise this is not a metadata, git or filetree problem . The problem is the actual code conflicts. It does not matter so much if metadata is removed from the equation if your or anyone else reading does not understands the nature of those code conflicts. Where this leaves you with your initial question how to do this easier for newcomers ? DONT Because any means to simplify a already simple process is hiding important steps of that process which means the confusion your will try to avoid know will multiply later for the newcomer when he end up not only having to learn all you tried to help me avoid to learn but also having to resolve an army of problems he generates because of his or her ignorance. Or to put this entire lengthy post in one sentence Laziness always comes with a high price to pay ;) On the matter of auto save, sure you can do that but again its not that necessary because any change you make to the code is already saved to changes files. But yes sure you can make filetree auto save to files , that could make things a tiny bit easier. Hoi, > > I want to have a quick "cheat mode" for loading and saving the Smalltalk > packages in my project. This is to make life easy for newbies who are not > very familiar with Monticello and Metacello. > > The "cheat" is to assume that there is one filetree:// repository that > contains all of the relevant packages, and all we need to do is load or > save each of those packages in that repository. > > I have the loading part working already: > > repo := MCFileTreeRepository new directory: '/foo/bar/baz' > asFileReference. > repo allFileNames do: [ :file | > (repo versionFromFileNamed: file) load. > ]. > > but now I am wondering how to do the saving part? That is, given a path to > a filetree repo like '/foo/bar/baz', how do I save each package in that > repo i.e. export the code in the image? > > Ideally I would like the same operation to skip metadata that is likely to > cause conflicts when the code is checked into Git later e.g. package > timestamps and versions. > > Tips would be appreciated :). > >
