On Nov 1 2007, Bernd Jendrissek wrote: >I took a clone of gaf.git AGES ago and started working on my slotting >mechanism, but in the meantime master has moved along (conflictishly >too), so I'm wondering how best to organize my changes. Should I just >git-rebase and fix up the conflicts, leaving the intermediate commits >in a potentially non-building state, or should do a series of merge >commits?
I'm not sure what will work best for your code, but if the original work followed a logical series of steps, e.g.. (Add "X" function, fix "Y", add "Z"), then it might be best to export a series of patches from your old checkout, then re-apply them as commits (stgit is REALLY useful here), on top of the new master checkout. In general, anything committed to the master repository should compile, and work to some degree, but as far as I recall, that should also be the case if you merge from the new master branch and roll in appropriate changes. I personally prefer the "patch" approach, as its how I've worked in the past, and produces a cleaner looking log in the main repository. Best wishes, Peter C. _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
