[[Hmm, I noticed this got off-list accidentally. Resending to list as well.]]
Op donderdag 8 december 2016 00:39:23 CET schreef David T.: > Geert, > > Thanks for noticing the errors. > > As for makefile.am, it seems I missed that with the Reports chapter I added > a little while back, too. I will see about fixing that, too. > > With regard to the earlier makefile.am omission, how should I handle that? > Should I do a new branch? Branching from where? maint? my bug-specific > branch? Somehow add it to my previous commit? And if I do a new branch now, > how will I handle the fact that both the glossary change and the reports > change are affecting the one file? I am aware that versioning addresses > this, but my grasp of these tools is rudimentary at best, and up to now I > have made changes in different files in the repository purposefully so as > to avoid being presented with this deep existential question. > > As for the xsltproc thing, as I said, I suspect some local oddity that is > causing the errors to fly. Maybe someday I will figure it out. > > David Hi David, To fix the reports chapter omission, just create a new commit on your current PR. It's not strictly related but it's a rather trivial change so I don't see the need for you to go through all the hoops of creating a separate branch and pull request. Have your commit message for this additional commit clearly state it's fixing an omission to your previous work. You can mention the other bug number in there. Then everybody can follow what is going on. In general, once a commit is integrated in the main repositories, you shouldn't change them anymore. So your question of 'somehow adding it to my previous commit' is a no-go, because that commit is already in the main gnucash-docs repository. While it's not needed at all in this case, the formal way would have been to create a new branch from maint and make the change on that branch. If you change the same file on two branches, this may indeed result in a merge conflict later on, but only if the changes are near to each other in the file. "Near" usually means less than 4 lines apart. If they're further away, git still knows how to perform the merge. As the changes in this case are easy to understand for the more experienced developers, we would have been able to resolve this conflict if the changes were too close together. In general this becomes more difficult with the number of conflicts in one merge. Regards, Geert _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
