2009/11/16 Vincent Snijders <vincent.snijd...@gmail.com>: > > Ok. That seems doable for now. It took you less time than me. :-)
Good to know. :) > I have written (or am writing) an application to identify which > revisions change the same files, so I can group them together in one > merge. What if a revision changed more that one file (which happens often)? Wouldn't that cause problems. Also how would that affect me? I use Cherry-pick, which simply applies the original commit to the fixes branch. This allows git users to see where the original commit came from - full history of changes are kept. Rolling various commits from trunk into a single commit will loose that history? That is why I don't use the standard automated branch tracking in Git for the fixes branch. I use the commit log descriptions in fixes branch to see what the original commit in trunk was, and cherry-pick that original commit. Not knowing exactly what you application does, but wouldn't that interfere with the commit log descriptions? > Currently there are about 840 revisions to be merged. Normally I would say: Damn, rather you that me. But in this case, we both do the work. :-) -- Regards, - Graeme - _______________________________________________ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ -- _______________________________________________ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus