-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix Manual Beta7 Dev Branches and PRs #71
Comments
Merge PRs First, Fix Conflicts After@thoni56, maybe the simpler approach is to first review and accept the PRs on This way we'll have to focus on a single branch, instead of 4. |
I used https://draftable.com to easily diff two pdfs. It doesn't detect whitespace changes, so it misses this exact PR, but it is easy to scroll two PDFs side by side giving you this view: |
Rebasing All PRs on Master after EditorConfig Cleanup@thoni56, as mentioned in #72, I've started to enforce consistent code styles via EditorConfig in What I would like try, locally first, is:
This means that we should wait before merging any PR into Since the Also, this should not only help to solve all current conflicts, but also make it easier to keep rebasing What do you think? Is this the right way to go? Am I mistaken, or missing out something?
|
PDF Diffing
The PDF diffs of this tool look quite neat. I use BeyondCompare 4 for diffing, which does offer specialized viewers for diffing various formats (Hex, images, CSV files, MP3, and others), including PDF, but the PDF diff previewer doesn't reproduce the actual styles, it only shows the text contents representation, without whitespace differences, but more like if it was a plain text file (therefore, no images either). I haven't used it much lately, so I don't remember the details, but surely it's not as neat as the dedicated tool you pointed out. Both BeyondCompare an Draftable are commercial tools, so having already invested money on the former I'm reluctant to spend further money on another tool — having to renew license when there's a major update, as well as having to learn a new tool and keeping it updated on the machine — but, surely, Draftable is quite tempting for someone who has to diff PDFs frequently. BeyondCompare 4 is a quite a powerful tool, with many features and customization options, and in over three years after its purchase I can't really say that I've managed to learn how to make the most out of it — can't find the time to dig into the docs and play around with it. I mostly use it at a basic level, although I did attempt to create an ALAN syntax highlighter for it (poor results, the syntax format is not very nice, seems buggy and has an horrible integration interface). In the future I should really invest more energy on BC4, especially on customizing automated diffing reports on a per-project basis, which is one of the cool features that attracted me to BC4 (beside the possibility to integrate with Git and many Git GUIs). But then, I loath having to spend more time learning the tools of the trade instead of focusing on the trade itself (i.e. programming instead of tooling). |
Because of this I think you are right. Although I haven’t consideted the merge of #40. |
@thoni56, the good news is that I've finished enforcing code styles consistency across the repository (still in So, even after merging into Right now, in I was wondering if we should squash them into a single commit or just keep them separate. On the one hand, having split commits per file type might be more manageable in terms of revisiting the repo history (blaming, etc.); but on the other hand it makes a longer commit history (where we could squash 4 commits into a single one). What do you suggest, based on your experience with long-running Git repos? Separate commits per file-type fixes, or all fixes squashed into a single commit? |
@tajmone Nice! And I like separate commits for the formatting fixes. In my experience, there is seldom a problem with many commits, This is a problem that shows up when the development organization grows. Up to a couple of teams (~10) I recommend single-branch development and committing directly to master (or your main branch) because of the immediate feedback you get (and it forces you to run tests and what not, locally). Again, in my experience, the value of a main branch with squashed commit so that you only get a single commit per "feature" only shows itself if you have a QA-department and process that inspects, tests and documents the new features in the release. And that's, luckily enough, no us ;-) So the only reason to use branching in the Of course, we could potentially find problems that we want to fix in the "released" documentation, but that is not a big deal. "bugs" in documentation can always wait for the next release. At least if you ask me. (In some lean/agile philosophical perspective, branching pushes feedback, and work, to a later time, which is always something to watch out for. And avoid, or minimize, if you can.) This became kind of a rant about branching, sorry for that, but I guess it's a background for my feeling that it doesn't matter much if we squash or not. We don't have the same "requirements" as large development organisations. |
@thoni56, thanks for sharing your thoughts on branches strategy (I'll comment on them later, since they are very helpful). Rebase NightmareRight now, I'm really struggling hard to reabse the The problem is that there are too many commits in the divergent history, and it's hard to track what you're trying to fix at each rebase stage (with the hash references being hard to memorize, and the awkward use by Git of the terms "ours" and "theirs"not helping either). Probably the best approach would be to rebase on specific commits, one at the time, all the way up to the current I think that the main problem here is due to a couple of AsciiDoc sources of the manual, the rest of the files needing only to be rebased on "ours" (which, apparently, according to Git it means the other branch, i.e. the rebase from, in the rebase context, where "ours" and "theirs" are swapped compared to merge operations — such a human friendly approach! linguistics are definitely not the strength of Git, which is permeated by dubious semantic choices all over its interface and documentation; sorry for the rant). What worries me most are the HTML and PDF builds of the various commits — if we amend the ADoc sources of the Manual (i.e. integrating changes from both "their" and "ours") they won't be mirroring the actual document status any longer. But rebuilding them on a per-commit-basis is going to require much fiddling in detached head commits (not to mention potential issues with updated dependencies in the toolchain). I'll do my best, but it's hard to be 100% sure that no edits are lost in the process — especially since the HTML previews can no longer be relied on as a way to compare results. |
Yes, I have seen that too. I'll have a look at the changes again. Perhaps one apporach would be to just look for changes in the PDF:s and the hand-edit the changes into master. (I'm starting to feel that since there is a lot of (valuable) cruft around the "text", having documentation in text/mergeable form is only half-valuable... One would wish for a separation of "text" and "administrative data", like indexing and stuff. But perhaps this is mainly because or documentation is in this infant state, when, through your tremendous work, that "administrative data" is changing a lot.) A PDF diff between And there are actually very few essential changes in the text. Most are, as alluded to above, index, crossreferences, page headings, ... a lot of things that are "generated" or "administrative". I think it would be easier to just re-do the "real" changes by hand. But having said that I'm not sure in which order we should do them. Probably it would be better (=easier) to merge the beta7-prep-* into beta-7-prep and then merge that. And finally re-do the ellision edits. |
Should be Fixed Now@thoni56, I think I've unraveled all the knots. I took a better approach:
As it turned out, many commits would turn out as empty after solving conflicts, because they were already handled in This approach was much cleaner, and it gave me the chance to focus on every commit's significant changes, leaving out noise from the conflicts. I'm confident that nothing went lost. So, now we basically have a clean version of Now I only to rebase the branches of the pending PRs on the new Therefore ... I'll be soon force-pushing the dev branches and replacing them with their new versions, and push also their old backups, so we can keep them until everything is merged and fine. What Went Wrong?I now realize that my mistake was that I kept thinking that we'd be soon squashing On the contrary, I often added global features in Lessons LearnedFrom now on, I'll make sure that the base dev branch will always be rebasable on |
That sounds really good! I'm not sure I'll ever learn to handle merges, rebases and their conflicts in a fluent manner ;-) Your lessons learned ring true with the feeling I had, but you put it nicely with "documentation contents changes". When I did the PDF diff I was thinking that it might be handy to have a tool that extract only the text from the Asciidoc, or PDF for that matter, and we can diff that. The will show the "documentation contents changes" that we want to focus on when looking at dev branches. Looking forward to some light in this tunnel! Good work! |
I've found a similar tool for pandoc markdown (written in Haskell) which parses both docs, builds an AST and then diffs the nodes; if I remember correctly it also allows some options on what to show and hide (e.g. styles, heading levels, etc.). Unfortunately I haven't found a similar tools for AsciiDoc, and I believe that it would require an AST parser to do that. |
Clean up the dev branches for the upcoming Beta7 release of the ALAN Manual (the first official release):
beta7-prep
onmaster
, solving conflicts as required.beta7-*
dev branches on the fixedbeta7-prep
branch:AppG-i18n-squash
beta7-prep-PDF-gaps
(was already merged)handle_elisions
beta7-*
dev branches — rebase and fix them as needed and then merge them, or delete them if rejected:After all PRs are merged, we should consider deleting left over branches:
AppG-i18n
(the unsquashed version ofAppG-i18n-squash
)AppG-i18n-squash
beta7-prep-PDF-gaps
handle_elisions
@thoni56, we need to unravel the conflicts with the dev branches and
master
, so we'll be able to merge/squash without problems when Manual Beta7 is ready for release.I'll try to reabse
beta7-prep
onmaster
, and then all otherbeta7-*
branches onbeta7-prep
. Then we really need to merge thebeta7-*
branches back intobeta7-prep
, so if you could start reviewing them we'll be able to save some time (not sure why those PRs have been hanging ther for so long, but after such a long time is going to be harder to review them and catch up).As I start to get a clearer picture of the required steps, I'll be updating this entry post and the task list above.
The text was updated successfully, but these errors were encountered: