Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow multiple commit prefixes #4253

Closed

Conversation

ChrisMcD1
Copy link
Contributor

@ChrisMcD1 ChrisMcD1 commented Feb 11, 2025

The only interesting implementation detail was choosing to implement a backwards compatible yaml decoding, instead of choosing to do a migration on the user's configuration file. I have a half-finished version of that branch, if we would prefer.

  • Please check if the PR fulfills these requirements
  • Cheatsheets are up-to-date (run go generate ./...)
  • Code has been formatted (see here)
  • Tests have been added/updated (see here for the integration test guide)
  • Text is internationalised (see here)
  • If a new UserConfig entry was added, make sure it can be hot-reloaded (see here)
  • Docs have been updated if necessary
  • You've read through your own file changes for silly mistakes etc

Comment on lines +215 to +229
func (a *CommitPrefixConfigs) UnmarshalYAML(value *yaml.Node) error {
var multi []CommitPrefixConfig
err := value.Decode(&multi)
if err != nil {
var single CommitPrefixConfig
err := value.Decode(&single)
if err != nil {
return err
}
*a = []CommitPrefixConfig{single}
} else {
*a = multi
}
return nil
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems that go-yaml has no way to express this behavior, so I created a newtype and put the behavior on it. Taken from the comments of go-yaml/yaml#100

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like this test doesn't cover much more than the existing integration tests, since the actual logic here is 5 LOC. I'm happy to remove if we don't want the duplication. Technically, it does test that we do the fallthrough to the 3rd commit prefix correctly.

Comment on lines -344 to -351
# See https://github.com/jesseduffield/lazygit/blob/master/docs/Config.md#predefined-commit-message-prefix
commitPrefix:
# pattern to match on. E.g. for 'feature/AB-123' to match on the AB-123 use "^\\w+\\/(\\w+-\\w+).*"
pattern: ""

# Replace directive. E.g. for 'feature/AB-123' to start the commit message with 'AB-123 ' use "[$1] "
replace: ""

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was automatically removed by go generate. I guess since the element is now a sequence instead of a mapping. Is there some way we can tag the field in the config struct definition so that these details continue to show here?

@@ -271,6 +271,8 @@ type GitConfig struct {
TruncateCopiedCommitHashesTo int `yaml:"truncateCopiedCommitHashesTo"`
}

type CommitPrefixConfigs []CommitPrefixConfig
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Newtype just for yaml deserialization purposes to maintain backwards compatibility.

@ChrisMcD1 ChrisMcD1 force-pushed the multiple-commit-prefixes branch from 5168bb9 to 88fa09d Compare February 11, 2025 06:14
@ChrisMcD1 ChrisMcD1 marked this pull request as ready for review February 11, 2025 06:14
ChrisMcD1 added a commit to ChrisMcD1/lazygit that referenced this pull request Feb 13, 2025
This implementation, unlike that proposed in jesseduffield#4253
keeps the yaml schema easy, and does a migration from the single
elements to a sequence of elements.
ChrisMcD1 added a commit to ChrisMcD1/lazygit that referenced this pull request Feb 14, 2025
This implementation, unlike that proposed in jesseduffield#4253
keeps the yaml schema easy, and does a migration from the single
elements to a sequence of elements.
ChrisMcD1 added a commit to ChrisMcD1/lazygit that referenced this pull request Feb 14, 2025
This implementation, unlike that proposed in jesseduffield#4253
keeps the yaml schema easy, and does a migration from the single
elements to a sequence of elements.
@ChrisMcD1
Copy link
Contributor Author

Closed in favor of #4261

@ChrisMcD1 ChrisMcD1 closed this Feb 14, 2025
ChrisMcD1 added a commit to ChrisMcD1/lazygit that referenced this pull request Feb 16, 2025
This implementation, unlike that proposed in jesseduffield#4253
keeps the yaml schema easy, and does a migration from the single
elements to a sequence of elements.
ChrisMcD1 added a commit to ChrisMcD1/lazygit that referenced this pull request Feb 16, 2025
This implementation, unlike that proposed in jesseduffield#4253
keeps the yaml schema easy, and does a migration from the single
elements to a sequence of elements.
stefanhaller pushed a commit to ChrisMcD1/lazygit that referenced this pull request Feb 17, 2025
This implementation, unlike that proposed in jesseduffield#4253
keeps the yaml schema easy, and does a migration from the single
elements to a sequence of elements.
stefanhaller pushed a commit to ChrisMcD1/lazygit that referenced this pull request Feb 17, 2025
This implementation, unlike that proposed in jesseduffield#4253
keeps the yaml schema easy, and does a migration from the single
elements to a sequence of elements.
stefanhaller added a commit that referenced this pull request Feb 17, 2025
- **PR Description**
This implementation, unlike that proposed in
#4253 keeps the yaml schema
easy, and does a migration from the single elements to a sequence of
elements.

Addresses #4194
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant