-
-
Notifications
You must be signed in to change notification settings - Fork 34
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
feature: git integration #87
Comments
Hi @ennioVisco, thanks for the feature request.
If you mean to add a pre-commit YAML file to this repository, I am against it for various reasons.
I'm not sure to follow. git-changelog builds changelog entries by looking at Git tags in your history, not the other way around 🤔 Could you elaborate?
I believe it's already possible to setup a post-commit hook (or whatever the hook name is) that runs git-changelog to update the changelog in-place, without auto-bumping the latest tag, so that you get an auto-updated "Unreleased" entry in your changelog 🙂
Same as above, I'll need you to elaborate on your use-case to make sure I understand what you mean 🙂 |
Could you elaborate a bit more? I'm not sure what you don't like, I'll try to clarify my view: #!/bin/sh
# Example pre-commit hook script
echo "Running pre-commit hook..."
# Add commands you want to run before commit here
# For example, running via poetry:
poetry run git-changelog This of course makes sense if the configuration is loaded from a file in the usual documented ways.
Does it? I was using it without having any tags in the repo and it was able to compute the next version (in my case 0.1.0), based on the conventional commit standard and the bump settings... AFAIK it did not create a new git tag for the new version, nor I found any setting to do that. |
Thanks for the clarifications. I was indeed speaking of the pre-commit Python tool (they should really have used another name, it requires clarification most of the time). If it's just about Git hooks, I don't have anything against them, but I also don't think it's worth having (and maintaining) dedicated code in git-changelog just to setup empty hooks. This is easily done with other tools, maintenance tasks, or project templates.
You're right, git-changelog is able to infer the next tag based on previous ones and commit messages. I was confused because you mentioned "new entries" (plural). The issue with auto-tagging is that it creates kind of a chicken and egg problem, at least with my own workflow. My workflow is:
If we were to auto-tag right after modifying the changelog, the changelog entry would actually not be contained in the newly tagged version. For this we would also have to stage the changelog's modifications and commit them. For the staging part, we would just stage the changelog (I suppose this would be OK in 95% cases). For the commit part, we could have an additional option to specify the commit message when committing the changelog. But... what if other files are already staged when we commit? Well, we're between consenting adults, so I suppose it's OK to provide options to also tag when updating the changelog, and tell users to be careful with their workflow. Therefore I'm willing to consider PRs for this, if you'd like to contribute 🙂 In short, we would:
WDYT? |
Thanks a lot, your comments make a lot of sense.
Your workflow is quite typical and actually the concerns you have with auto-tagging are legitimate. |
Thanks.
That's unclear to me. A pre-commit hook verifies things before a commit is made, right?
Even more unclear to me 😅 You commit the changelog and then the changelog is updated (again)?
If you want to use Git hooks, use Git hooks I think we mostly agree. If you tell me you agree with my previous, last paragraph ("in short..."), we can proceed 🙂 |
Here is the thing, this is one of the two options, but I feel this would be a bit brittle:
I believe this option would allow for more flexibility and less intrusive DX:
The git hook can be something very minimal, like the following: #!/bin/sh
# Execute auto-changelog (not sure how to pick the correct runtime here, so I write mine with poetry)
poetry run auto-changelog
# Add the generated file to the staging area
git add Changelog.md # The name should come from the config
# Add the missing tag (this could actually happen in the auto-changelog script directly)
git tag -a vx.y.z -m "vx.y.z"
# Exit with 0 to indicate success
exit 0 Concerning your question:
That's the thing, the pre-commit happens while the user generated the commit, the flow is more or less the following:
I hope this clarifies my view. |
Thank you for your patience
Hmm, I'm having trouble understanding this suggestion. A boolean option sounds like something persistent (in config) or ephemeral (CLI flag). But:
I'm sorry but I don't see how this could work. Either git-changelog runs Git commands while its process is running, either it doesn't. And I don't think providing a command to setup a Git hook is a good idea, if this is what you're suggesting: these hooks are terribly subjective and there's no way we can provide a generic hook that satisfies everyone. A few examples that come to mind:
By the way, there's an issue with the hook above (unless I'm missing something): you stage the changelog, but then tag before committing. That means your tag will be attached to the previous commit, which does not contain the changelog modifications. (also not sure what
Yes, this makes sense to me. But as mentioned above, this means we have to also stage and commit before tagging, which you said is brittle and intrusive 🤔 (which I agree with) |
It would be very cool to have a deeper integration with git to automatize the two following actions:
pre-commit
hook that refreshes the changelogThe benefit for the developers would be the following:
The text was updated successfully, but these errors were encountered: