Nicolas, I was thinking about it and I ended up with this : If in repository A, I have packages B and C, as well as the C library named libY, in my branch dev-thierry, then if I merge package B from dev-thierry and master, then: - This is a merge for package B, - but, for git, this isn't a merge from the combination of package B, C and libY; this is a kind of cherry picking (or I'm not sure what it is :( ). I already have an idea of how it would be difficult to make Monticello / gitfiletree recognize that the MC merge is coming from two different branches of the git repo (and not from merging from git and a smalltalkhub repo), but even then, at the git level, making that a merge? It isn't; it's something else, an intermediate merge (or kind of). Now, what could work is something like : - git mergetool pharo And then a gui in pharo could: - let us resolve all conflicts the usual way for git users (aka meld) - translate all packages related conflicts into the right operations What do you think? Thierry ________________________________ De : Pharo-dev [pharo-dev-bounces@lists.pharo.org] de la part de Nicolas Cellier [nicolas.cellier.aka.nice@gmail.com] Envoyé : vendredi 25 avril 2014 19:44 à : Pharo Development List Objet : Re: [Pharo-dev] Modifications to be integrated in Pharo 3.0 VM 2014-04-25 17:38 GMT+02:00 GOUBIER Thierry <thierry.goubier@cea.fr<mailto:thierry.goubier@cea.fr>>: Hi Nicolas, from what you describe (double merge: one in git, one in MC), I wonder if my decision to maintain compatibility between gitfiletree and FileTree by writing the metadata (version / methodProperties) in gitfiletree is a good thing? Thierry Very good question indeed. This is spoiling the efficiency of git for merging... I think that the answer is yes though, because not every one is using git (think Eliot's branch). Esteban is not publishing the MC packages back on SmalltalkHub for nothing. Those MC package would not be usable if they loosed their history, and I'm not sure that we are ready to loose that... Yet, resolving the (real code) merge conflicts in an external tool does not feel so cool to me, I'd like to specify git mergetool --pharo ;) Another way would be to not attempt a merge at all via git, it would be simpler to just pick the mc package somewhere, but I don't like it, we're loosing git traceability (and those nice github networks). Otherwise, if development was exclusively git driven, then we would be more comfortable with git tools. But still, we have the image which is a working copy, and not necessarily in sync with gitfiletree, so we have a more complex process than file based environments anyway : one more indirection. image <-> files <-> staged files <-> repo There is still one super-cool feature where git shines that we can use: jumping from one branch to another (modulo the image sync with files), the most usefull one IMO when we are mixing external platform files and Smalltalk code that require some sync. Nicolas