Damien

On Thu, Jul 10, 2014 at 9:59 AM, Damien Pollet <[email protected]>
wrote:

> as far as I am concerned (I'm certainly not up-to-date on recent
> enhancements)…
>
> - filetree is a pain because of the double-commit workflow (MC with
> dummy message to serialize, then git)
>
Thierry's MergeDriver has made the monticello meta data conflicts a
non-issue ... since using his merge driver they've gone away as far as I am
concerned ...

I don't think the meta data can go away until a firm break with mcz files
has been made and this cannot really happen until the image has full tool
support for working with pure git repos and even then there will be a
transition period ...

- gitfiletree is a pain because it insists on using a file browser
> that shows all dotfiles and starts in the stupidest of places
> - github is just a snapshot (no updates, no contributions)
> - there is a mysterious new "remote git repo" that either uses
> gitfiletree or the new libgit2 bindings, but I'm not sure what all the
> parameters are exactly (name of what? subdirectory of where?)
>
> This promises to coalesce into a nice workflow, though. Can't wait :D


I cannot comment on the other things, but for GemStone I am building git
support into tODE and have created a `project list` that I think supports
git work flow in the "right way" (I am doing a pre-alpha release shortly, I
will find out:) ... but the point of this is that I think you almost have
to build a new tool suite for managing projects and git repos together and
that just takes time ... the old package-base tools are not quite at right
 level, since with git it is possible to look at method history, class
history, package history and project history and when you do a commit, you
should be committing all of the packages in the project at the same time
(or at least have the option of doing so)...

Dale

Reply via email to