XML Parse error on Local Build

[Geert Janssens]

[[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