Provide a GitHub PR title from `.git/info/title` file

[russellyeo]

Solves https://github.com/VirtusLab/git-machete/issues/1351 (not sure if having a linked issue is preferred or not, created one just in case)

Similar to the functionality for adding a PR description from .git/info/description, it would be useful to be able to set the PR title from a .git/info/title file.

This is a suggestion for an alternative method to the --title CLI parameter, which should take precedence over this method.

Expected behavior

Given that

• .git/info/title contains a title, e.g. "Add New Feature"
• .git/info/description contains a description, e.g. "# Summary\n..."

When we invoke

git machete github create-pr

Then a pull request is created with the title and description set.

[russellyeo]

This was tested by creating and merging a PR in my fork of the repository here https://github.com/russellyeo/git-machete/pull/2, with a local .git/info/title file providing the title

[PawelLipski]

Nice! complete with tests and docs 🥰 I'll take a closer look tmrw/Monday

[PawelLipski]

Hmmm one general consideration... I'd say that's it's rather rare for people to have a constant PR title that they'd like to reuse across pull requests (and .git/info/... or other such files like in .github/... are best suited for such repetitive contents). This is unlike with PR description, which is very likely to be reused across PRs. What is your use case/what is the PR title that you're reusing? 🤔

[russellyeo]

Hey @PawelLipski, thanks for taking a look at this. I also want to thank you for the excellent tool - I now can't imagine working without it.

Hmmm one general consideration... I'd say that's it's rather rare for people to have a constant PR title that they'd like to reuse across pull requests (and .git/info/... or other such files like in .github/... are best suited for such repetitive contents). This is unlike with PR description, which is very likely to be reused across PRs. What is your use case/what is the PR title that you're reusing? 🤔

Good point. Perhaps my workflow is a little unusual - I use a git alias which opens these files one-by-one to gather my input and then create the PR:

[alias]
    create-pr = !code --wait .git/info/description && code --wait .git/info/reviewers && git machete github create-pr

(Invoked with git create-pr)

This change would fit nicely into this workflow. It could likely be achieved with some scripting and the --title PR, but I thought it would be a nice opportunity to follow the existing pattern. Writing to a file also lends itself well to scripting. For example, I might set up a script to automate converting the branch name into a nicely formatted title.

[PawelLipski]

I also want to thank you for the excellent tool - I now can't imagine working without it. Thank you!

Good point. Perhaps my workflow is a little unusual - I use a git alias which opens these files one-by-one to gather my input and then create the PR

Okay, I see... this still looks like a quite unusual approach 😅 As you can imagine, I'm pretty concerned about bloating the interface of git-machete too much, given that there's a minor release (i.e. new features) pretty much every month and docs are already huuuge 🫠

May I suggest one of the following:

1. Keep the feature as-is, but skip it from docs. This way it'll cater for your specific workflow, without the extra perceived complexity to create-{pr,mr} (esp. important for fresh users). There're already some undocumented features that only I am likely to ever use, like GIT_MACHETE_MEASURE_COMMAND_TIME env var.
2. Alternatively, instead of using .git/info/title which suggests a static title to be used for all PRs (which is rather impractical and hence potentially confusing for the other users), allow for passing @-prefixed file name as title: [email protected]. This is a pattern not found in git-machete yet, but otherwise pretty well-known from tools like curl. This will be less confusing as it suggests that title isn't static but rather dynamically generated.

WDYT?

[russellyeo]

@PawelLipski

Thanks for the suggestions, both options seem like a good compromise. I'm happy with either! I've reverted the changes to the docs as the simplest route (option 1). I'm also open to discarding all changes altogether, just let me know what your preference is

[PawelLipski]

Merging as is. Thanks!