[keycloak-dev] Commits/PRs

[Peter Palaga]

Hi Stian,

just a few minor points. Please note that I am speaking primarily from 
the standpoint of somebody who often looks into the history of KC 
branches, because Hawkular (where I am primarily active) uses KC. I am 
not a regular contributor to KC.

(1)
 > With JIRA key in commit and PRs linked in JIRA we get a good history
 > that is useful in the future to identify what was changed and why.

To see *what* was changed, I do not need to go to Jira. Git history is 
the ultimate source of that info.

As for the *why*, the project has to coin some convention. From what you 
say it seems that it should be Jira, right? Yes, that is one of the 
legitimate choices, but not the only possible one. Git commit messages 
may serve the purpose too and I personally find them much more practical 
because they are much closer to where I usually start looking. Jira is 
usually one slooowly loading link further. Therefore, could you please 
explain why you find Jira better?

(2) I want tags in branches.
Your tags are outside branches (such as 1.9.x) and that makes it harder 
to clearly and quickly see what happened between e.g. 1.9.0 and 1.9.1. 
You are the second project doing it like this out of ~150 Java projects 
I have ever cloned.

Please consider tagging the usual way.

(3) While I agree that the linking between git history and Jira is 
useful, saying that every commit needs a Jira does not sound reasonable. 
There certainly are commits that do not deserve a Jira, such as:
* upgrades of dependencies
* refactorings
* various formatting and license header fixes
I hope most of you will agree here.

(4) Pro tip for Chrome users:
I created a content script that makes Jiras and BZs on GitHub clickable 
links. This is what it looks like: http://snag.gy/rq6Ja.jpg How to 
install: https://goo.gl/bYUbHS

Thanks,

Peter

On 2016-03-10 19:12, John Dennis wrote:
> On 03/10/2016 01:03 PM, Bill Burke wrote:
>> Is there a way to automatically squash everything to your latest
>> commit?
>
> Maybe not automatically, but the conventional way to squash commits is
> with interactive rebase, e.g.
>
> % git rebase -i commit
>
> where commit is the commit id of the *prior* commit you want to start
> the squashing from. Git will fire up your defined editor and you just
> replace the pick keyword with the squash keyword for each commit to be
> squashed. Many examples on the web. It's not automatic but usually less
> than a minute from start to finish.
>
> HTH,
>