Open milescrabill opened 3 weeks ago
Hey, thanks for the comprehensive proposal! I'm good to go with that, in fact I'm sometimes catching often doing exactly that — changing the PR title manually after amend-commits that change the PR title.
Probably the more difficult part would be to provide test coverage for the new functionality as it might require changes to the somewhat non-trivial mock GitHub/GitLab clients used in the tests — but ofc I can help with that part.
For the flag name, --update-title
LGTM. I'm unsure about machete.github.prTitleMatchCommitSubject
wording — maybe for more consistency with forceDescriptionFromCommitMessage
it should be sth like updateTitleToCommitSubject
.
As a side note, at this point, I'm feeling awkward about retarget-pr
used less and less for actual retargeting of PRs, and more for updating PR descriptions 😅 probably a new subcommand like git machete github update-pr-description
would make sense (ofc beyond the scope of this proposal).
git-machete
enables a lot of workflows, but for mine in particular I often have single-commit GitHub PRs stacked on top of each other. It would be very convenient ifgit-machete {restack,retarget}
could keep the titles of the PRs in sync with the corresponding commit subject if it changes.I would like to be able to configure
git-machete
to manage PR/MR titles for me when restacking or retargeting PR/MRs. When creating a PR/MR using{create-pr,create-mr}
, by default the commit message subject of the first commit after the fork point is used as the PR/MR title.1325 covers updating PR/MR descriptions with a flag like
--update-all-descriptions
to{create,restack,retarget}-{mr,pr}
. In the same vein, I propose the flags--update-title
and--update-all-titles
. There could be an option to make this the default behavior for GitHub / GitLab respectively as well. I would wait to see how--update-all-descriptions
is implemented before attempting--update-all-titles
.I'm happy to take this on, but I'd like to get some pre-feedback to understand if this proposal is in line with the goals of the project. Here are some ideas for implementation. I'm sure there are better approaches that I haven't thought of, so please feel free to correct me.
CodeHostingClient
already hasset_description_of_pull_request
, and the scenarios in which a PR/MR title is being updated are the same as when the description would be updated.title
string alongside the description string in the{PATCH,PUT}
request that updates the PR/MR.set_title_of_pull_request
could be added, but this would mean an additional API call when restacking/retargeting.retarget_pull_request
andrestack_pull_request
methods ofMacheteClient
could each take anupdate_title
boolean which when set would pass the commit message subject of the first commit after the fork point as the title to update.machete.github.prTitleMatchCommitSubject
andmachete.gitlab.mrTitleMatchCommitSubject
that controls default behavior.