On May 13, 2014, at 3:53 AM, Geert Janssens <[email protected]> wrote:
> On Monday 12 May 2014 14:47:13 John Ralls wrote: >> On May 8, 2014, at 1:40 PM, Geert Janssens <[email protected]> > wrote: >>> You're welcome. I was too curious to let it pass and it was a good >>> opportunity to learn something about git merge in the process. >> >> The only actual damage seems to have been in >> src/report/report-gnome/gnc-plugin-page-report.c; at least that is >> the only file with significant diffs in `git diff 9d40512..49a5909`, >> which shows the net change from your reverting the merge, remerging, >> and re-doing the C++ fixups. All of the changes from this year were >> reversed in the original merge commit, so I must have messed up when >> handling the last or next-to-last back-merge and blithely picked the >> branch version for every diff. git rerere remembered and did the same >> when I did the forward-merge. >> > That's a reasonable explanation. > >> So I’m going to revise my earlier worry about git being able to safely >> merge a long running commit: I’m not sure *I* can safely merge a >> long-running and complex branch in the face of dozens of conflicts. I >> guess that’s an argument for merging frequently to keep the conflicts >> under control. >> > Agreed. Your kvp branch was from before the git era when it wasn't > possible to merge. We can now revise our strategy and merge master more > frequently in longer running topic branches to reduce the merge > complexity. > > It will be a matter of finding a good balance. It doesn't make sense > either to merge after each and every commit. That does indeed clutter up > the branch history and makes the history harder to read in tools such as > gitk. Yeah, it would be silly to merge after every commit. One strategy might be to frequently merge from master and then revert the merge if there are no conflicts. ISTM that relying on rerere in the face of ongoing development on both branches risks replaying what was the right answer with last week's code but isn't with this week's, so if there are conflicts resolved in the merge it stays so that new code builds on the resolved result rather than continuing to diverge. I think merges into master should happen for every module (e.g. gncguid, gncdate) so that conflicts coming into master are limited to a single subject. That should make it a bit easier for the person doing the merge to keep track of which way to resolve the conflicts. That will still produce a ladder appearance in gitk and friends. I don't find that objectionable, but apparently some people do. Regards, John Ralls _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
