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

[Ryan Sleevi]

On Mon, May 4, 2020 at 12:26 PM Dimitris Zacharopoulos (HARICA) <
dzacharo at harica.gr> wrote:

>
>
> 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> 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?
>

Right! That's the tricky part - downstream forks should always 'merge
commit' from upstream, but ideally, upstream will 'squash and merge' from
downstream.


> 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.
>

Yup. Note that if you're comfortable in the command-line, "git apply-patch"
will preserve all of your commit history. But we can see what comments come
up then.


>
> Does this seem like a good plan?
>
>
> Dimitris.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/infrastructure/attachments/20200504/b710475b/attachment-0001.html>