[Infrastructure] Trouble creating a "clean redline" for Forum-12 [Was: Trouble preparing pull request for SC25]

[Dimitris Zacharopoulos (HARICA)]

On 2020-05-04 6:41 μ.μ., Ryan Sleevi wrote:
>
>
> On Mon, May 4, 2020 at 3:13 AM Dimitris Zacharopoulos (HARICA) 
> <dzacharo at harica.gr <mailto:dzacharo at harica.gr>> wrote:
>
>
>     Once again, I am either not following our documented procedure
>     correctly or there is something wrong with the steps.
>
>     Following instructions listed in
>     https://wiki.cabforum.org/github_redline_guide, I started my
>     process by syncing master of https://github.com/dzacharo/documents
>     (my own fork) with the official repo master
>     (https://github.com/cabforum/documents).
>
>     I did this by following the instructions of "Prerequisites"
>     section 2. The result of this was
>     https://github.com/dzacharo/documents/pull/1 which was merged to
>     my local master.
>
>
> It looks like you didn't click "Merge Pull Request" but did "Squash 
> and Merge"
>
> "Merge Pull Request" is supposed to be the default, based on 
> https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/merging-a-pull-request , 
> but Step 2 on the wiki didn't call that out. I've updated as such.
>
> This is why it still says you're "50 commits behind master" - because 
> you're not actually in sync with master, you diverged 50 commits ago 
> by squashing those 50 commits into a single commit. I've also updated 
> the Wiki to reflect that it's a Bad Thing if you don't see that.
>
>     Then I created a branch
>     https://github.com/dzacharo/documents/tree/update-bylaws-to-v2.3
>
>     Then I made several commits updating the Bylaws on this branch and
>     created a new pull request against my own repo
>     (https://github.com/dzacharo/documents/pull/2).
>
>     Now it's time to create an immutable redline so I followed the
>     compare instructions, using the last commit of the official repo
>     (https://github.com/cabforum/documents/commit/fc63be73323195abc4e462708ca0385e37b7043d)
>     and the last commit from my local branch with the bylaws changes
>     (https://github.com/dzacharo/documents/commit/a94d136c6ddbd0024e9bdc70785aa71f1e2f6753)
>
>
> Because of the above, you effectively "forked" from the official repo 
> at the point you did your merge - to the official Repo, it's a series 
> of several distinct commits, while in your Repo, it's only a single 
> commit.
>
> Now, while the effective state of the repos (the last commit of 
> official, the last commit *before* your changes) should be identical 
> in content, they're not identical in hashes, hence the issue you see. 
> However, if they really are identical (and I've not confirmed), then 
> the answer is make your immutable diff from (the last commit from the 
> official repo in *your* branch) to (the last commit of your changes).
>
> This is 
> https://github.com/cabforum/documents/compare/740e4b1be75a2c3468c8448cb7cdf9dff10bc69f..a94d136c6ddbd0024e9bdc70785aa71f1e2f6753#diff-c2f0349076f544cc0e9f059f30f21a85 (that 
> is, starting with your 
> https://github.com/dzacharo/documents/commit/740e4b1be75a2c3468c8448cb7cdf9dff10bc69f )
>
> That's still immutable, and in theory can be cleanly applied against 
> upstream.
>
> This is super-easy to fix on the command-line, similar to Doug's 
> change (as was before), because the patch file 
> <https://github.com/cabforum/documents/compare/740e4b1be75a2c3468c8448cb7cdf9dff10bc69f..a94d136c6ddbd0024e9bdc70785aa71f1e2f6753.patch> can 
> be easily downloaded and applied to a 'clean' repository to create the 
> pull request.
>
> It's unclear what you'd like to do here, so I'm holding off on 
> offering solutions. I could easily create a PR with "just" your 
> commits in my branch, I could help you get your 'master' repository 
> back to a clean slate and rebase your branch on-top of it (a bit more 
> involved, but preserves exact commits), or you could just create a 
> second fork from a clean slate and apply the delta of changes. Lots of 
> options here, but in all scenarios, all of your data is preserved, 
> nothing is lost or messed up, and we've got an unambiguous recoverable 
> trail of your edits :)

Thank you so much for the explanation. Makes a lot more sense now. I 
will update the instructions to highlight that we should not "squash and 
merge" when we sync between repos. However, but we should "squash and 
merge" when merging the final pull request to master, right?

Since we have an immutable version and the ballot is now in the 
discussion period, I think I will leave it as is, and if there is 
feedback that will result in making further edits (which will inevitably 
produce a different GitHub redline URL, I will create a second fork from 
the official repo, apply the patch file, add the extra commits related 
to the discussion period and create a new immutable redline.

Does this seem like a good plan?


Dimitris.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/infrastructure/attachments/20200504/296f4d4b/attachment.html>