Page MenuHomeFreeBSD

porters-handbook: Fix the Git process in Chapter 11.1
ClosedPublic

Authored by ygy on May 24 2021, 6:16 PM.
Tags
None
Referenced Files
F86816150: D30422.id89884.diff
Wed, Jun 26, 12:36 AM
Unknown Object (File)
Mon, Jun 24, 10:07 AM
Unknown Object (File)
Fri, Jun 21, 7:17 PM
Unknown Object (File)
Fri, Jun 21, 10:25 AM
Unknown Object (File)
Fri, Jun 21, 9:33 AM
Unknown Object (File)
Fri, Jun 21, 7:43 AM
Unknown Object (File)
May 21 2024, 5:09 PM
Unknown Object (File)
May 17 2024, 1:46 AM

Details

Summary

In Chapter 11.1 Using Git to Make Patches, there are multiple issues with the process:

  • git pull --rebase will refuse to work if there are any staged or unstaged changes, so the users are unable to update the repo to the latest.
  • git diff does not work for staged changes, need to add --staged.

This commit attempts to address the above.

PR: 256122
Reported by: Neal Nelson <ports@nicandneal.net>

Diff Detail

Repository
R9 FreeBSD doc repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

ygy requested review of this revision.May 24 2021, 6:16 PM
ygy created this revision.

A textual suggestion, the rest looks fine.

documentation/content/en/books/porters-handbook/upgrading/_index.adoc
112

How about splitting the "Watch and follow the output carefully" part into a separate sentence to give it more emphasis and reducing the length of the following sentence a bit?

pauamma_gundo.com added inline comments.
documentation/content/en/books/porters-handbook/upgrading/_index.adoc
112

Second that. It also gets rid of a comma splice.</pedant>

ygy marked 2 inline comments as done.May 25 2021, 12:28 AM
documentation/content/en/books/porters-handbook/upgrading/_index.adoc
39

s/you/your/ (or use "the" instead, since IIRC the doc style guide discourages 2nd-person pronouns).

Address pauamma's comment

This revision was not accepted when it landed; it landed in state Needs Review.May 26 2021, 4:12 AM
This revision was automatically updated to reflect the committed changes.

Personally, I've used this workflow in the past, and it's dangerous.
I think we should instead be strongly encouraging people to commit the changes before updating.
git rebase -i will let them curate them to committable form
If anything at all goes wrong in the above, there's no 'reset and do it again' like there is with a git rebase -i gone wrong: you can simply start over with git rebase --abort. With the above, if you screw anything up in the rebase, you can lose cahnges.