XML Parse error on Local Build
Geert Janssens
geert.gnucash at kobaltwit.be
Wed Dec 7 15:01:47 EST 2016
[[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
More information about the gnucash-devel
mailing list