Fixing Branches Conflicts
tajmone opened this issue · comments
@thoni56, I've started looking into branch conflicts you mentioned to me via email, and indeed we have a problem of branch diversions, including master.
Since I hadn't fetched origin for a while, my local clone wasn't affected, therefore I've created branch copies of both my current master and dev-man and pushed them on origin:
[old-dev-man-tajmone]old-dev-man-tajmone[old-master-tajmone]old-master-tajmone
These can now serve as a back-up as well as to understand where things went wrong and how to fix them.
If I've understood correctly, you now would like to rebase dev-man on master, right?
What about the new [origin/upload_from_travis]origin/upload_from_travis branch? Is that supposed to be en pat with master?
The problem seems to revolve around commit e9265b6 ("Update Group and Cookbook links", possibly a PR by Christian). That commit is fine, should be in master branch as it is, but after that there are many ALAN Manual fixes that should have been committed on dev-man, but were committed to master instead ... up to f677872, where ALAN Manual changes start to be committed on dev-man again.
Probably, the best thing would be to recreate these branches in some working copy, moving all Man changes to the dev branch. Since we'll have to cherry pick some commits, the old commit hashes will be replaced so it looks like we'll need to force push master branch too to fix this entanglement.
@thoni56, what do you suggest as the fixing strategy? And can you tell me what sort of conflicts you're getting when trying to rebase (i.e. is it affecting ALAN Manual contents and files only, or some shared project files appear to diverge too?)
Sorry to wake your concerns with my email. It was ment as a heads up for some upcoming force-pushes. The conflicts were only concerning the generated PDF of the manual, which was frustrating and tedious. We are already discussing this. Nothing else have been a problem.
(My problem was that when I rebased dev-man onto master (with some commits cherry-picked from dev-man) git kept the changes separate instead of moving the branch point. So I had to rebase both dev-man and master to get the commits in an order that allowed git to fast-forward and only keep the intended commits on dev-master. )
So, no. There is nothing that needs fixing. I therefore suggest that we close this issue.
The branches are all in order now (w.r.t to the manual):
update_to_travisis an experimental branch where I try to get Travis to upload a single file to Github Releases, it will go away once I understand how to do that (could have done that in a private fork, yes...)dev-manonly contains changes that corresponds to functional changes that are not yet in the official release (preview, development snapshots, whatever...)mastercontains changes that are compatible with the current release of the Alan SDK, such as fixing errors in option lists, improving wording or explanations
Again, I think we are not seeing this the same way, but this is the way I want it to be. I'm gonna move #87 to discussion and we can see if I can't explain myself better there.
This is what the dev-man and master looks in my local repo, and again this is what I was aiming for:
| * 319be91 (origin/dev-man, dev-man) [manual] Update the debugging section w.r.t log file options
| * 7767f4d [manual] Update interpreter switches for transcript and input
| * 55861f8 [manual] Document block comments
| * f677872 [manual] Rename Appendices Source Files
|/
* be56be4 (origin/master, origin/HEAD, master) [manual] Remove a few trailing spaces
* 54c86ac Clarify that the width option is always overridden by actual value if possible
* e44d9fb Clarified the difference between two variants of Schedule
* df69128 [manual] Restore and re-write some trashed sentences about verbs
* 605aef4 [manual] Add a "usually" to verbs associated to classes
* 001b3c7 [manual] Clear up final sentences about inheritance
* 142263c [manual] Simplified an entangled sentence
* 78c9aa9 [manual] Update debugging transcript
* 08ce130 [manual] Update Abug help information
* 97504a5 [manual] Improved the text about tracing levels
* 0aa608c [manual] Clarified formulation about scenery in suggested file structure
* 5a11b3a [manual] Change non-intuitive "invent" to usual "inventory"
* 08afc2c [manual] Fix erroneous warning about debugging switches
* b605c72 Updated text about the Development Kit
(My problem was that when I rebased
dev-manontomaster(with some commits cherry-picked fromdev-man) git kept the changes separate instead of moving the branch point
Yes, the downside of cherry picking is that it alters commits hashes, which then messes up the whole history and requires force pushing. It sucks, but there doesn't seem to be alternative routes to fix these type of problems.
mastercontains changes that are compatible with the current release of the Alan SDKAgain, I think we are not seeing this the same way, but this is the way I want it to be.
I have no disagreement with this, I just thought that currently it wasn't possible (or practical) to update the Manual just on master, due to the gap between the two.
But we really need to create a Wiki page on the strategies on the ALAN Manual Beta vs Alpha versions (how they are maintained, updated, released, etc.) which we can always easily find and consult when in doubt (instead of having to sift through scattered Issues and past conversations).
I'm more than happy to create the Wiki page, we might begin by starting a Discussions thread, retrieving links to the various Issues on the topic, discuss if we need to add anything to the strategy, and then I'll write a well polished Wiki page (which of course, can always be edited in the future, if the need be).
I have no disagreement with this, I just thought that currently it wasn't possible (or practical) to update the Manual just on master, due to the gap between the two.
That's good ;-) but what do you mean by "to update the Manual just on master"? I, as the primary contributor to it will have to update both master and on dev-man but with completely different changes. When there is a change in the functionality of the Alan system that change will only go in dev-man (until a new official release of the Alan SDK is made). Any other type of change should go into master. I even think that changes that you want to do, like suggestions for improvement, spelling correction, format changes, should go in master.
By continuously rebasing dev-man on master we will keep them organised and easy to merge at release of a new Alan SDK.
But we really need to create a Wiki page on the strategies on the ALAN Manual Beta vs Alpha versions (how they are maintained, updated, released, etc.) which we can always easily find and consult when in doubt (instead of having to sift through scattered Issues and past conversations).
We surely should do a wiki page, of course ;-) and I've started an answer in the discussion about PDF's, which can carry the discussion for now. But I'm afraid that answer will possibly take some thought and a while to create.