2015-03-03 23:38 GMT+01:00 Peter Uhnák <i.uh...@gmail.com>: > Well, as you have noticed in Java, C or C++, switching branches does >>> not call make automatically :) >>> >>> You can use git hooks for that. >>> >> >> Ok. Then I would suggest you take the code source of CLANG, LLVM, >> OpenOffice or of the Linux kernel, you add the git hooks to call make, and >> you admire how fast changing branches becomes ;) > > Sure; large project would take long regardless but comparatively small > (~10kloc) project would get checkouted fast, also it doesn't just > completely rewrite the filesystem, but only the actual changes (which is > for my use cases most of the time in the order of tens of files) >
As GitFileTree stands, some things are easy to do; others could be added. Note that: GitFileTree makes it easy to browse a specific commit without touching or branching or checking out the repository. > > >> Want to switch branches before committing? Can do. >> > How? :-o If I switch the branch from git (command line) then there is > disparity. > Well, yes and no. What you are working on is stashed inside your image (your current working copy). That you change, branch or checkout the underlying git repository doesn't matter. On a refresh or the repository inspector, GitFileTree will pick all the changes without any perturbation on your working copy. You have to understand that Monticello coupling of a package with a repository is very loose. Each time you do something with Monticello, it won't go straight for the repository the package came from, but instead will scan all repositories if they have something relevant. I'll try to rephrase, maybe it'll be clearer. Your working copy in the Pharo image (the modified package you are working on) is, to take a git concept, your staging area / changes to head. If you checkout / change branch / pull the git repository, you make the equivalent of stash, git checkout, and recreate your changes on top of the new HEAD (not exactly like that, but this is how GitFileTree will map your changes to git). By the way, for FileTree users: FileTree does the same thing... but with next to zero control over the git status. > > I'm not a git expert, but I know enough about git (and git users:)) that >> each and everyone may have its opinion on the way git should be used, and, >> as such, I've decided on GitFileTree that I wouldn't claim to hold the way >> it should be used(tm). > > Yes, I need to think about myself a bit... I am used to certain workflow > and I guess I was greedy with wanting everything. > Maybe also I'm not very clear about the interaction between Monticello and Git. > > >> I will have to think about it. I am used to my git workflow and now I am >>> kind of lost how to use it properly from Pharo; since I am cut off from >>> git. One idea that is crossing my mind is having synchronized filedumps >>> (filetree) in a folder and not worry about git or monticello inside >>> Pharo at all. (And when I change code outside it would magically change >>> also inside). >>> >> >> Please explore the idea; just try to focus on that: >> > Adding it my (endless) todolist, I would need to learn a bit (=lot) about > monticello first and how these things actually work inside Pharo so it > could be done, but just like everybody I have a lot on my plate. (And I > have also tend to eat more than I can chew.) > I would say, probably not that much about Monticello. But it could be nice if we make the minimum a bit clearer, such as documenting a few entry points (load a package, save a package, list all dirty packages, etc...) What we need more, is things along the lines of: - If I do operation A in my git repository, I want my image Monticello to do X - If I do operation B in Monticello, I want my git repository to do the operation Y Once we have a list like that, we can: add ways to trigger X when A was done (or add a button in Pharo to do A, followed by X), and, when doing B in MC, have GitFileTree do Y. > >> At the same time, there is just me and Max (and Esteban as well, I think) >> working on getting that git support working, so don't bash us too much. >> It's hard enough to get it done (look at Max questions about libcgit) that >> we don't need too much additional pressure. > > I am really sorry if my message sounded harsh, I in no way intended > something like that. Sometimes I am more greedy and picky about software > than I should be. I'll add some positive emoticons next time so it will be > more happy. :) > > I am grateful for the work you have done, after all I do like it and I am > happy I was able to make the switch to git, despite me missing features; so > please don't my ramblings as bashing, they were intended (albeit bit > directly) only as questions/ideas. > If I can convince you to help me, then that will be great :) Thierry
