Rultor should help create a better git log and release text

[alxn]

Just look over this release example, it's nice to see something like:

• #<issue1> <Description of Issue1>
• #<issue2> <Description of Issue2>
• ...

And for the git log, something like this:

• Merge pull request #<issue> from <branch-name>
• Fixes #<issue>: <Description of issue>
• ...

Currently with rultor I see things like this in some releases:

• <hash> by rultor: Merge branch '__rultor'
• <hash> by @alxn: Some in-person review comments...
• <hash> by @alxn: Update the UML started by...
• <hash> by rultor: Merge remote-tracking branch '...
• <hash> by rultor: Merge remote-tracking branch '...
• <hash> by rultor: Merge branch '__rultor'
• <hash> by <@user>: `: CR fixes more....
• <hash> by <@user>: `: CR fixes....
• <hash> by <@user>: `: cobertura....
• <hash> by <@user>: `: checkstyle....
• <hash> by <@user>: `: Fix for....
• And the same in history.

I know squashing goes a long way to help this, but I think what we really want to see on master, and in the release notes is something more like:

• <hash> by <@user1>: <issue1>: <Description of issue1>
• <hash> by <@user2>: <issue2>: <Description of issue2>
• <hash> by <@user3>: <issue3>: <Description of issue3>

[yegor256]

@alxn yeah, I see your point... I think that the best we can do is to go through the list of issues and find those that were closed between the latest release and current one, and list them. What do you think?

[alxn]

@yegor256 for the release notes, that would be good enough I guess.

It's a shame that git log --oneline will still look bad though, but if it was fixed, it could drive the release notes. Fixing up git log is more for blame analysis later on to work out why something changed, or what else changed with it.

[alex-palevsky]

@alxn this task will get someone's attention soon

[alex-palevsky]

@alxn since there is no milestone yet I set it to "2.0"

[original-brownbear]

@alex-palevsky this is postponed

[alex-palevsky]

@alex-palevsky this is postponed

@original-brownbear right, I added "postponed" label

[alex-palevsky]

@alex-palevsky this is postponed

@original-brownbear no problem, I will try to find somebody else

[alxn]

@original-brownbear what did you think about this one?

[original-brownbear]

@alxn I don't think it would be too hard to have Rultor enforce a nice log in the future.

I mean we're working from the rule of small and single-issue PRs anyways, so we could simply
enforce the log style you want the following way:

• Forbid merging any branches that have merge commits in them, that aren't also in master
• Limit PRs to a certain number of commits (~3 I'd suggest), make people squash to eliminate noise
• Match commit messages against some regex, to enforce your above suggestion
  • At least we should always have the issue number in the beginning of the message imo
  • Also we should not allow multiple issue numbers in one PR, the should all start with the same '#HASH'
  • Maybe also enforce like 4 words minimum
• Forbid duplicate commit messages

=> this we could def implement and offer as an option in the .rultor.yml. Could also allow for some customization of rules. This should in fact be fairly easy to implement.
We could simply script this into the actual merge/rebase logic and fail builds right in the beginning with proper output if they don't adhere to the rules.

Would that be what you're looking for here ?

[alxn]

@original-brownbear yes, something like that. We've been using [#id] One-line-Message, since git seems to discard #comment lines....

Unless we end up with

git config --global alias.yolo '!git add -A && git commit -m "$(curl -s whatthecommit.com/index.txt)"'

[original-brownbear]

@alxn

How about we simply add this functionality to the .rultor.yml:

git-log:
  format: "some regex forced on commit messages"
  allow_mcs: "true/false" # merge commits allowed?
  max_commits: "number of max commits per PR"
  forbid_duplicates: "true/false" # whether to block duplicate messages  in direct succession

PS: "#comment" does not work, " #comment" does though ;)
PS2: nice link :D

[alxn]

@original-brownbear That sounds like a good idea, though I wonder whether it's nice to get it user-side as well, i.e. from git-scm

The downside to this approach is the whining that will inevitably result when your users’ commit pushes are rejected.

[original-brownbear]

@alxn well the whining ..., that's a very different issue, outside of Rultor's scope imo.
This would, as described in the git docs, really require setting up some hook in your .git folder.
Also ... at least for Teamed projects the "whining" shouldn't really be an issue ;)

[original-brownbear]

@alxn @yegor256

I think @mkordas made a very good point on this :) How about implementing this ? :

Quote him:

100% agreed, and yes, it should be a Rultor feature where person merging assigns commit message matching some preconfigured pattern

Why not simply add functionality the merge command for architects, so the ARC can do this:

"{at}rultor merge commit message is '#1234 did some reasonable thing' "

Then we have a reasonable line of merge commits guaranteed and can build a release log from those ?