Fix an issue where github.preserve-pull-request-description=true was adding \n to commit message.#880
Fix an issue where github.preserve-pull-request-description=true was adding \n to commit message.#880bolinfest wants to merge 1 commit intofacebook:mainfrom
Conversation
|
@facebook-github-bot has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
|
@bolinfest , seems like this breaks a couple of tests: also: |
|
@bolinfest has updated the pull request. You must reimport the pull request before landing. |
|
@facebook-github-bot has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
|
@sggutier I updated the two tests that you mentioned. Unfortunately, when I run: I admit I see a number of failures, but the messages I'm seeing give me the impression that not all of these tests are written to work in OSS Sapling? |
…adding \n to commit message. Summary: While facebook#863 fixed some important issues with respect to recognizing `\r\n`, it also introduced a new issue where running `sl pr s` with `github.preserve-pull-request-description=true` would inadvertently add an extra `\n` before the horizontal rule delimiting the Sapling stack information. This fixes `create_pull_request_title_and_body()` to preserve whatever whitespace was originally present before the horizontal rule, only adding a new `\n` to the end of the commit message if it did not already have one. Test Plan: ``` ./tests/run-tests.py ./tests/test-doctest.py ```
|
@bolinfest has updated the pull request. You must reimport the pull request before landing. |
|
@facebook-github-bot has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
@bolinfest yeah, we should really try to make our tests more external-friendly, especially if those tests are testing OSS featurues |
sggutier
left a comment
There was a problem hiding this comment.
Also, it seems like tests are now passing, so I'll try to get this merged soon
|
@bolinfest I think this introduced an issue where the last line of a commit is rendered as a header since it now looks like a "second level header" here: https://daringfireball.net/projects/markdown/basics. What issue did the extra newline cause? |
|
I agree and I have hit this, as well. Before, I believe it was adding an extra new line every time I ran Agree I should fix it so there is exactly one before the horizontal separator. I think the problem mainly happens when the PR at the bottom of the stack goes from "lone" to "stacked" because it had no trailing newline before the stack is appended. |
Summary: # Motivation And if there is one is one design mistake Rust ecosystem made, it is making [`group_by` weird](rust-itertools/itertools#374) and possible for users to, quote: > I spent several hours debugging my code written using the group_by function. Luckily for internal users, the build tooling responds accordingly and fails build for all usages of deprecated API. Thus, there is a need to adjust all of them manually. # [Release notes](https://github.com/rust-itertools/itertools/blob/master/CHANGELOG.md#0130) ### Breaking - Removed implementation of `DoubleEndedIterator` for `ConsTuples` (#853) - Made `MultiProduct` fused and fixed on an empty iterator (#835, #834) - Changed `iproduct!` to return tuples for maxi one iterator too (#870) - Changed `PutBack::put_back` to return the old value (#880) - Removed deprecated `repeat_call, Itertools::{foreach, step, map_results, fold_results}` (#878) - Removed `TakeWhileInclusive::new` (#912) NOTE: Quick search didn't tell me anything related to breaking changes above, CI will tell. And, of course, scream to me if it breaks your personal build. Reviewed By: anps77 Differential Revision: D64306014 fbshipit-source-id: 881ac716e1dc23968d4a28000fdaccdbf9097ec2
Fix an issue where github.preserve-pull-request-description=true was adding \n to commit message.
Summary:
While #863 fixed some important
issues with respect to recognizing
\r\n, it also introduced a newissue where running
sl pr swithgithub.preserve-pull-request-description=truewould inadvertently add an extra
\nbefore the horizontal ruledelimiting the Sapling stack information.
This fixes
create_pull_request_title_and_body()to preserve whateverwhitespace was originally present before the horizontal rule,
only adding a new
\nto the end of the commit message if it did notalready have one.
Test Plan: