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,