Using non rebased master instead

[urwrstkn8mare]

@ABaumher @UncleGoogle with your permission I'd like to replace master with @ABaumher's original. I've been looking at at the git graph and I cannot see a future where we can merge better_proto_deps into the rebased master. Does anyone know how this would be done? Thanks for your work in cleaning up the commit history @ABaumher but we should've realised this would be a major issue. I don't think losing the ability to find problematic commits is a major issue. This will require me changing the permissions temporarily but I think it is pretty important for future merges from @ABaumher.

Look at this example of a part of the git graph

This should be preserved for future contributors to marvel at

Please give me your opinions or approval

[ABaumher]

If we rebase better proto deps to the clean one it shouldn't be that bad for future PR imo. The history is still preserved on my repo (i could swap that to master and have the nebula rebase as a branch instead). The current rebase preserves all original authors (each author gets at least one commit per merge)

Alternate option: keep a dev branch here that has all the commits and history but keep master clean. If we did that we probably could just squash merge into master (and clean up the previous pr as one giant commit).

[urwrstkn8mare]

rebase better proto deps to the clean one

yeah this is what i assumed but how would we do this? I just tried but it seemed impossible. for example the branch diverged from master at one point but then master was remerged back later after a bunch of changes already made to the repo (assuming there was merge conflicts that had to be resolved). plus rebasing itself can introduce weird issues if done incorrectly.

if you find you're able to do it that would be awesome. otherwise the value of a clean history is not that important for this repo imo as most likely when we find bugs we'll just find where in the offending code and find all code it interacts with rather than looking for the offending commit.

[UncleGoogle]

Yes, that's a problem.

Initially I thought that @ABaumher will rebase his master and then rebase his better proto branch onto a new master. There is no interest to keep 2 parallel versions of the reality.

rebase better proto deps to the clean one

yeah this is what i assumed but how would we do this?

The simplest would be to sacrifice history on better_proto_deps squashing it to one big commit (writing from memory, may be something different):

• git reset nebula_master # this should leave all the changes in working directory
• git commit -a -m "Switch to BetterProto and other refactors"

or:

• git reset to latest common ancestor (should be no conflicts)
• stash all
• checkout to new master
• stash pop, resolve many conflicts but once

If you need more than 1 commit on better proto or resolving all the conflicts at once seems too hard, then try this:

• find common ancestor
• squash as much as possible on till the common ancestor on better_proto_deps to reduce number of commits touching the same files.
• git rebase --onto nebula_master common_ancestor_sha # resove conflicts multiple times; reject temptation to leave the newest variants of the code you know, only compare 2 conflicting commits

Solution 2 is as you propose @urwrstkn8mare.

Another variant of solution 2 is to setup pure auto-sync fork:

• hard reset to FoG state, setup sync action and proceed with automatically generated PRs
• additonally: setup policy to only use merge with merge commit strategy for those PRs, so that this repo will only have additional commits (for potential releases) so that it won't have conflicts with upcoming stuff.
• there may be a problem with conflicting current_version.json so sync action have to be updated to always add commit that resets current_version.json file (automation for this kind of PR fix/current version #2) or we would move with those current_version.json to separate repo in Nebula so that we could leave the originals as is.

[urwrstkn8mare]

if @ABaumher likes the auto-sync fork approach we could go for that.

The simplest would be to sacrifice history on better_proto_deps squashing it to one big commit

this should probably be out of the question cause you would lose all the history and other collaborators.

• find common ancestor
• squash as much as possible on till the common ancestor on better_proto_deps to reduce number of commits touching the same files.
• git rebase --onto nebula_master common_ancestor_sha # resove conflicts multiple times; reject temptation to leave the newest variants of the code you know, only compare 2 conflicting commits

@UncleGoogle this is what i had trouble with. the common ancestor is @FriendsOfGalaxy's last commit as nebula_master has been rebased and all commits are completely new. and the original master had been merged back into better_proto_deps multiple times. do u know about to deal with that?

@ABaumher if you like the idea of auto-sync fork let us know and we will do that. otherwise let us know which approach u like the best

[UncleGoogle]

@urwrstkn8mare I mean "common ancestor" logically, not technically. E.i. the commit on a new master branch that correspond to the moment (commit) on a old master where better_proto_deps where branched off.

UPDATE

there is

3ab4d1c - Bugfix so mobile code works correctly on master_nebula (and this is also the last commit) which correponds to e511960 on better_proto_deps so assuming it was really "the last" commit and you didn't swap commits order around this e511960 during last rebase, go with:

git rebase --onto 3ab4d1c e511960 better_protobuf_deps

I started, but don't have enough history knowledge about change to do it myself. And there is 85 commits to rebase, so I can't say if this is 1 hour work or 10h hours work :D It may be easier to do iteratively with reducing that number on better_proto_deps_commits_reduced first, especially if there were some reverts and hotfixes along the way

[urwrstkn8mare]

oh thanks! ill have a go with this. btw i think the order may have gotten changed as you can see here:

master_nebula

master_not_nebula

where did LauraRozier's commits go?

as a sidenote i kinda like seeing the original commits and their times. gives me an idea of how it was developed originally but ABaumher is keeping the original history so that isn't much of a problem.

[UncleGoogle]

It is important that there is nothing missed pn new master ehat is before commit e511960 on better proto.

Im also ok with reseting to original master, so kind of reverting my previous rebasing proposal which bring more troubles 🙊 . I was used to rebase feature branches but I forgot it is interrepository MR and rewriting history should happen only on private branches nobody else is using

[urwrstkn8mare]

rewriting history should happen only on private branches nobody else is using

yeah honestly i think this a very good point. interactive rebase should probably be restricted to just small branches/PRs

@UncleGoogle is alr with it. so @ABaumher if you'd like this say the word and i'll replace master with the original history. this should make your life alot easier

[ABaumher]

@urwrstkn8mare That commit is FriendsOfGalaxy@ab9aade
Despite being written back in march it was merged in way later so it was placed there during the rebase. That's how git works, apparently. I could have rewritten the history and moved it to the beginning, which i guess i should have done.

Ideally, if we were doing this properly to clean up the commits as we go, i should have rebased off that branch instead of merging it into mine which would make all of this a lot easier. But we'd have needed to make every contributer do rebase instead of merge, and evidently that did not happen.

NGL rebasing when two devs are working simultaneously is not ideal, but i'm actually in agreement that rebasing to clean up the code is a good idea. We don't need 15 "update README.md" commits. If there was a nicer way to keep all the branch history and still squash a few trivial commits, i'm open for it.

That said, i've been trying to get better_protobuf_deps into the dev branch here so it can get reviewed, and trying to rebase that has been... unpleasant.

I guess i'm ok for it to be reverted for now, we can revisit the rebase version when 2.0 drops and the code is mostly stabilized. Realistically 1.0.7 (and the previous 3 patches) have just been the bare minimum to get the new flow working and minor bugs fixed, despite the insane commit total, lol.

[urwrstkn8mare]

Yep just because the history currently is messy doesn't mean future work has to be messy. We can just commit to making cleaner commits in the future (probably once v2/conversion is in dev branch) and what has already been done is done.

[urwrstkn8mare]

alright i've done it. i disabled linear history requirement as it is too much of a mess to keep the history linear. although we definately can and should after v2 releases. the merge commit to merge the conversion into master should be the last of its kind.

[UncleGoogle]

To resync we can (one-time-only) reset --hard to ABaumer master. Then there is a problem with diffs in current_version.json, we will have to each time resolve conflicts with eaither rebase or merge strategy.

I've checked how FriendsOfGalaxy dealt with syncing with original repo, and found this command (which merges original master with strong preference of the fork content and THEN override some files like readme and current_version.json) : https://github.com/FriendsOfGalaxy/galaxy-integrations-synchronizer/blob/master/scripts.py#L353

Until we do manually there should be no problem though