8:29 a.m.
Please squash commits. The ideal is one commit and one PR per JIRA issue.
If you want to break a JIRA issue into smaller tasks then please create
sub-tasks in JIRA, then do one commit/PR for one sub-task.
Always include JIRA key in the commit message. A good commit message look
example is:
----
KEYCLOAK-1267 add a separate sso_max_lifespan parameter for remember me
----
We have automated linking of PRs in JIRA as long as the JIRA key is
included in the commit message. It doesn't hurt to manually link as this is
generally quicker.
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. It's also
important that this history goes both ways. For example if you don't
include JIRA key in commit it's very difficult to find the associated JIRA
issue. If you didn't even link the PR then it's pretty much impossible.
All commits to main repository should be done through PRs, no direct
pushing to repository please.
7:03 p.m.
Is there a way to automatically squash everything to your latest
commit? FYI, I just screed up the rebase so I have included like 30
commits in my PR.
On 3/10/2016 2:29 AM, Stian Thorgersen wrote:
Please squash commits. The ideal is one commit and one PR per JIRA
issue. If you want to break a JIRA issue into smaller tasks then
please create sub-tasks in JIRA, then do one commit/PR for one sub-task.
Always include JIRA key in the commit message. A good commit message
look example is:
----
KEYCLOAK-1267 add a separate sso_max_lifespan parameter for remember me
----
We have automated linking of PRs in JIRA as long as the JIRA key is
included in the commit message. It doesn't hurt to manually link as
this is generally quicker.
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.
It's also important that this history goes both ways. For example if
you don't include JIRA key in commit it's very difficult to find the
associated JIRA issue. If you didn't even link the PR then it's pretty
much impossible.
All commits to main repository should be done through PRs, no direct
pushing to repository please.
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
7:12 p.m.
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,
--
John
10:17 p.m.
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,
6:53 a.m.
On 10 March 2016 at 22:17, Peter Palaga <ppalaga(a)redhat.com> wrote:
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?
One isn't better than the other. They serve different purposes. Git commit
messages will tell you what code was changed, while JIRA descriptions will
tell you why it was changed. Both are equally important. Making sure you
can go from a JIRA issue to Git commits and the other way around are both
important. Imagine two examples:
* A user searches for a bug in JIRA to see if the problem he's having has
been resolved. He finds the issue and wants to take a look at what changes
was made to understand it better.
* A developer finds some code he wrote 12 months ago was changed, looks at
Git history to see who did it, but has no idea why. He then sees the JIRA
key in the commit message and opens it in JIRA. There he finds a lengthy
description of the bug, including several comments.
(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.
You've certainly cloned more repositories than I have.. I'm not sure what
you mean. 1.9.x tags has to come from 1.9.x branch as master is now 2.x.
Can you elaborate?
(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.
I disagree, I want a complete record of what's been done in JIRA. Upgrading
of dependencies should not just be done randomly. It has a reasoning behind
it (for example a security fix, or to re-allign with WF dependencies, or
whatever) without a JIRA you don't have that. Same goes for refactoring,
they either should be done as part of an existing JIRA or there should be a
JIRA describing why it was done. The work has to be scheduled the same as
all other work.
For minor documentation updates (grammar, spelling fixes, etc.) or minor
pure formatting sure they don't need a JIRA.
All rules come with exceptions, that's just the way of life. However, by
defacto all commits should have an associated JIRA. That's even more
important for external contributions.
(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,
>
>
2:45 p.m.
Hi Stian, inline...
On 2016-03-11 06:53, Stian Thorgersen wrote:
On 10 March 2016 at 22:17, Peter Palaga <ppalaga(a)redhat.com
<mailto:ppalaga@redhat.com>> wrote:
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?
One isn't better than the other. They serve different purposes. Git
commit messages will tell you what code was changed, while JIRA
descriptions will tell you why it was changed. Both are equally
important. Making sure you can go from a JIRA issue to Git commits and
the other way around are both important. Imagine two examples:
* A user searches for a bug in JIRA to see if the problem he's having
has been resolved. He finds the issue and wants to take a look at what
changes was made to understand it better.
Yes, I fully agree that the linking from
Jira to GitHub makes sense.
* A developer finds some code he wrote 12 months ago was changed,
looks at Git history to see who did it, but has no idea why. He then
sees the JIRA key in the commit message and opens it in JIRA. There he
finds a lengthy description of the bug, including several comments.
No, the
explanation why the given commit was necessary may well be
placed in the commit message itself. In many projects, this is the
default place for that kind of info. Now, given that the motivation for
the change can be described in the commit message, the overhead of
creating a Jira needs to be justified. Writing the "why" to the commit
message is much faster and more developer friendly than forcing
contributors to create a Jira for every trivial improvement. I can say
for myself that having to create a JIra before fixing some stupid bug
substantially lowers my readiness to fix it at all.
The work has to be scheduled the same as all other work.
Yes,
planning is fully legitimate within your team paid for the work but
again, it sounds rather discouraging to me, an external contributor,
when I just want to fix a malfunction in KC that blocks my primary task.
(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.
You've certainly cloned more repositories than I have.. I'm not sure
what you mean. 1.9.x tags has to come from 1.9.x branch as master is
now 2.x. Can you elaborate?
Sure. This is the "normal" way, where tags
0.17.Final and 0.16.Final are
*inside* a branch (master branch in this case):
To get the tags from upstream, I do not need to use --tags with git
fetch, because the in-branch tags are fetched also without --tags.
Furthermore I can clearly see what happened between the yellow labels
0.17.Final and 0.16.Final.
OTOH in KC, when I forget to fetch with --tags, switching to 1.9.x
branch I get only this:
No tags there. Only some hints like "Next is 1.9.2" where the tags are
perhaps around. Nevermind, I know I have to fetch with --tags:
Still no tags there, because they are out of the 1.9.x branch that I
have checked out. To see them, I have to "Show all branches and tags" in
egit. Sadly, that brings also master and other branches, that I do not
want to see, but let's try to ignore them, and have a look at what
happened between 1.9.0.Final and 1.9.1.Final:
While it is relatively easy to find out how 1.9.1.Final tag relates to
1.9.x branch, I am completely lost on the other end: 1.9.0.Final is a
long fork of 1.9.x that I cannot track down visually at all. If
1.9.0.Final and 1.9.1.Final tags were a part of 1.9.x history, my eyes
would be much happier. That's it.
Thanks,
-- Peter
>
>
> (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.
>
>
> I disagree, I want a complete record of what's been done in JIRA.
> Upgrading of dependencies should not just be done randomly. It has a
> reasoning behind it (for example a security fix, or to re-allign with
> WF dependencies, or whatever) without a JIRA you don't have that. Same
> goes for refactoring, they either should be done as part of an
> existing JIRA or there should be a JIRA describing why it was done.
The work has to be scheduled the same as all other work.
>
> For minor documentation updates (grammar, spelling fixes, etc.) or
> minor pure formatting sure they don't need a JIRA.
>
> All rules come with exceptions, that's just the way of life. However,
> by defacto all commits should have an associated JIRA. That's even
> more important for external contributions.
>
>
> (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,
>
>
>
2:55 p.m.
unsubscribe. This is about as interesting as code formatting rules.
On 3/11/2016 8:45 AM, Peter Palaga wrote:
Hi Stian, inline...
On 2016-03-11 06:53, Stian Thorgersen wrote:
>
>
> On 10 March 2016 at 22:17, Peter Palaga <ppalaga(a)redhat.com
> <mailto:ppalaga@redhat.com>> wrote:
>
> 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?
>
>
> One isn't better than the other. They serve different purposes. Git
> commit messages will tell you what code was changed, while JIRA
> descriptions will tell you why it was changed. Both are equally
> important. Making sure you can go from a JIRA issue to Git commits
> and the other way around are both important. Imagine two examples:
>
> * A user searches for a bug in JIRA to see if the problem he's having
> has been resolved. He finds the issue and wants to take a look at
> what changes was made to understand it better.
Yes, I fully agree that the linking from Jira to GitHub makes sense.
> * A developer finds some code he wrote 12 months ago was changed,
> looks at Git history to see who did it, but has no idea why. He then
> sees the JIRA key in the commit message and opens it in JIRA. There
> he finds a lengthy description of the bug, including several comments.
No, the explanation why the given commit was necessary may well be
placed in the commit message itself. In many projects, this is the
default place for that kind of info. Now, given that the motivation
for the change can be described in the commit message, the overhead of
creating a Jira needs to be justified. Writing the "why" to the commit
message is much faster and more developer friendly than forcing
contributors to create a Jira for every trivial improvement. I can say
for myself that having to create a JIra before fixing some stupid bug
substantially lowers my readiness to fix it at all.
> The work has to be scheduled the same as all other work.
Yes, planning is fully legitimate within your team paid for the work
but again, it sounds rather discouraging to me, an external
contributor, when I just want to fix a malfunction in KC that blocks
my primary task.
>
> (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.
>
>
> You've certainly cloned more repositories than I have.. I'm not sure
> what you mean. 1.9.x tags has to come from 1.9.x branch as master is
> now 2.x. Can you elaborate?
Sure. This is the "normal" way, where tags 0.17.Final and 0.16.Final
are *inside* a branch (master branch in this case):
To get the tags from upstream, I do not need to use --tags with git
fetch, because the in-branch tags are fetched also without --tags.
Furthermore I can clearly see what happened between the yellow labels
0.17.Final and 0.16.Final.
OTOH in KC, when I forget to fetch with --tags, switching to 1.9.x
branch I get only this:
No tags there. Only some hints like "Next is 1.9.2" where the tags are
perhaps around. Nevermind, I know I have to fetch with --tags:
Still no tags there, because they are out of the 1.9.x branch that I
have checked out. To see them, I have to "Show all branches and tags"
in egit. Sadly, that brings also master and other branches, that I do
not want to see, but let's try to ignore them, and have a look at what
happened between 1.9.0.Final and 1.9.1.Final:
While it is relatively easy to find out how 1.9.1.Final tag relates to
1.9.x branch, I am completely lost on the other end: 1.9.0.Final is a
long fork of 1.9.x that I cannot track down visually at all. If
1.9.0.Final and 1.9.1.Final tags were a part of 1.9.x history, my eyes
would be much happier. That's it.
Thanks,
-- Peter
>
>
> (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.
>
>
> I disagree, I want a complete record of what's been done in JIRA.
> Upgrading of dependencies should not just be done randomly. It has a
> reasoning behind it (for example a security fix, or to re-allign with
> WF dependencies, or whatever) without a JIRA you don't have that.
> Same goes for refactoring, they either should be done as part of an
> existing JIRA or there should be a JIRA describing why it was done.
> The work has to be scheduled the same as all other work.
>
> For minor documentation updates (grammar, spelling fixes, etc.) or
> minor pure formatting sure they don't need a JIRA.
>
> All rules come with exceptions, that's just the way of life. However,
> by defacto all commits should have an associated JIRA. That's even
> more important for external contributions.
>
>
> (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,
>
>
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
3:12 p.m.
That's a very unhelpful and unnecessary comment. If you don't care, don't
comment. If you object, then comment. To me this is important so there's no
reason to be condescending.
The process I described will be helpful for a number of reasons, including:
* It will make it simpler to maintain 1.9.x branch for product while we
move on to 2.x branch
* Users can search for JIRA issues to see if an issue they are having has
been fixed
* Users can view changes for a particular release, including descriptions
of why it was changed (maybe the change causes problems for them)
* Developers can figure out why something was done (2 years after it was
done)
* We can plan when to fix a bug. Not all bugs need fixing, some can be
postponed others are blocking for a release
* ....
In summary all I ask is squash commits and include KEYCLOAK-XXXX in the
commit message.
On 11 March 2016 at 14:55, Bill Burke <bburke(a)redhat.com> wrote:
unsubscribe. This is about as interesting as code formatting rules.
On 3/11/2016 8:45 AM, Peter Palaga wrote:
Hi Stian, inline...
On 2016-03-11 06:53, Stian Thorgersen wrote:
On 10 March 2016 at 22:17, Peter Palaga <ppalaga(a)redhat.com> wrote:
> 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?
>
One isn't better than the other. They serve different purposes. Git commit
messages will tell you what code was changed, while JIRA descriptions will
tell you why it was changed. Both are equally important. Making sure you
can go from a JIRA issue to Git commits and the other way around are both
important. Imagine two examples:
* A user searches for a bug in JIRA to see if the problem he's having has
been resolved. He finds the issue and wants to take a look at what changes
was made to understand it better.
Yes, I fully agree that the linking from Jira to GitHub makes sense.
* A developer finds some code he wrote 12 months ago was changed, looks at
Git history to see who did it, but has no idea why. He then sees the JIRA
key in the commit message and opens it in JIRA. There he finds a lengthy
description of the bug, including several comments.
No, the explanation why the given commit was necessary may well be placed
in the commit message itself. In many projects, this is the default place
for that kind of info. Now, given that the motivation for the change can be
described in the commit message, the overhead of creating a Jira needs to
be justified. Writing the "why" to the commit message is much faster and
more developer friendly than forcing contributors to create a Jira for
every trivial improvement. I can say for myself that having to create a
JIra before fixing some stupid bug substantially lowers my readiness to fix
it at all.
The work has to be scheduled the same as all other work.
Yes, planning is fully legitimate within your team paid for the work but
again, it sounds rather discouraging to me, an external contributor, when I
just want to fix a malfunction in KC that blocks my primary task.
> (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.
>
You've certainly cloned more repositories than I have.. I'm not sure what
you mean. 1.9.x tags has to come from 1.9.x branch as master is now 2.x.
Can you elaborate?
Sure. This is the "normal" way, where tags 0.17.Final and 0.16.Final are
*inside* a branch (master branch in this case):
To get the tags from upstream, I do not need to use --tags with git fetch,
because the in-branch tags are fetched also without --tags. Furthermore I
can clearly see what happened between the yellow labels 0.17.Final and
0.16.Final.
OTOH in KC, when I forget to fetch with --tags, switching to 1.9.x branch
I get only this:
No tags there. Only some hints like "Next is 1.9.2" where the tags are
perhaps around. Nevermind, I know I have to fetch with --tags:
Still no tags there, because they are out of the 1.9.x branch that I have
checked out. To see them, I have to "Show all branches and tags" in egit.
Sadly, that brings also master and other branches, that I do not want to
see, but let's try to ignore them, and have a look at what happened between
1.9.0.Final and 1.9.1.Final:
While it is relatively easy to find out how 1.9.1.Final tag relates to
1.9.x branch, I am completely lost on the other end: 1.9.0.Final is a long
fork of 1.9.x that I cannot track down visually at all. If 1.9.0.Final and
1.9.1.Final tags were a part of 1.9.x history, my eyes would be much
happier. That's it.
Thanks,
-- Peter
>
> (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.
>
I disagree, I want a complete record of what's been done in JIRA.
Upgrading of dependencies should not just be done randomly. It has a
reasoning behind it (for example a security fix, or to re-allign with WF
dependencies, or whatever) without a JIRA you don't have that. Same goes
for refactoring, they either should be done as part of an existing JIRA or
there should be a JIRA describing why it was done. The work has to be
scheduled the same as all other work.
For minor documentation updates (grammar, spelling fixes, etc.) or minor
pure formatting sure they don't need a JIRA.
All rules come with exceptions, that's just the way of life. However, by
defacto all commits should have an associated JIRA. That's even more
important for external contributions.
>
> (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>
> 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,
>>
>>
>
_______________________________________________
keycloak-dev mailing
listkeycloak-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Bill Burke
JBoss, a division of Red Hathttp://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
3:29 p.m.
On 3/11/2016 9:12 AM, Stian Thorgersen wrote:
In summary all I ask is squash commits and include KEYCLOAK-XXXX in
the commit message.
That's all I needed to hear, not some long drawn out discussion on the
way GIT history should look and the GIT command tribal dance to get it
to look that particular way. I don't understand people's fascination
with something that is rarely looked at by a very small subset of people
that we can probably count on one hand. I've seen the same mind
numbing, anal retentive, discussions on Wildfly, hibernate, and core
lists too.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
3:38 p.m.
On 11 March 2016 at 15:29, Bill Burke <bburke(a)redhat.com> wrote:
On 3/11/2016 9:12 AM, Stian Thorgersen wrote:
>
> In summary all I ask is squash commits and include KEYCLOAK-XXXX in the
> commit message.
>
>
That's all I needed to hear, not some long drawn out discussion on the way
GIT history should look and the GIT command tribal dance to get it to look
that particular way. I don't understand people's fascination with
something that is rarely looked at by a very small subset of people that we
can probably count on one hand. I've seen the same mind numbing, anal
retentive, discussions on Wildfly, hibernate, and core lists too.
I blame the day of the week - I tend to get more caught up in discussions
on a Friday ;)
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
2:57 p.m.
On 11 March 2016 at 14:45, Peter Palaga <ppalaga(a)redhat.com> wrote:
Hi Stian, inline...
On 2016-03-11 06:53, Stian Thorgersen wrote:
On 10 March 2016 at 22:17, Peter Palaga <ppalaga(a)redhat.com> wrote:
> 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?
>
One isn't better than the other. They serve different purposes. Git commit
messages will tell you what code was changed, while JIRA descriptions will
tell you why it was changed. Both are equally important. Making sure you
can go from a JIRA issue to Git commits and the other way around are both
important. Imagine two examples:
* A user searches for a bug in JIRA to see if the problem he's having has
been resolved. He finds the issue and wants to take a look at what changes
was made to understand it better.
Yes, I fully agree that the linking from Jira to GitHub makes sense.
* A developer finds some code he wrote 12 months ago was changed, looks at
Git history to see who did it, but has no idea why. He then sees the JIRA
key in the commit message and opens it in JIRA. There he finds a lengthy
description of the bug, including several comments.
No, the explanation why the given commit was necessary may well be placed
in the commit message itself. In many projects, this is the default place
for that kind of info. Now, given that the motivation for the change can be
described in the commit message, the overhead of creating a Jira needs to
be justified. Writing the "why" to the commit message is much faster and
more developer friendly than forcing contributors to create a Jira for
every trivial improvement. I can say for myself that having to create a
JIra before fixing some stupid bug substantially lowers my readiness to fix
it at all.
There's always going to be JIRA issues for bug reports. They will describe
what the problem the user had as well as how to reproduce the bug. This
will be the most common scenario for a bug fix.
It's better to have the information in one place, and since there's no
getting away from JIRA, that's the one place this information belongs.
Commit messages should be short and refer to a JIRA.
The work has to be scheduled the same as all other work.
Yes, planning is fully legitimate within your team paid for the work but
again, it sounds rather discouraging to me, an external contributor, when I
just want to fix a malfunction in KC that blocks my primary task.
We can't just accept any random contribution. Any fix can bring
regressions, etc.. So it's not as simple as just fire off a quick fix to
something.
> (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.
>
You've certainly cloned more repositories than I have.. I'm not sure what
you mean. 1.9.x tags has to come from 1.9.x branch as master is now 2.x.
Can you elaborate?
Sure. This is the "normal" way, where tags 0.17.Final and 0.16.Final are
*inside* a branch (master branch in this case):
To get the tags from upstream, I do not need to use --tags with git fetch,
because the in-branch tags are fetched also without --tags. Furthermore I
can clearly see what happened between the yellow labels 0.17.Final and
0.16.Final.
OTOH in KC, when I forget to fetch with --tags, switching to 1.9.x branch
I get only this:
No tags there. Only some hints like "Next is 1.9.2" where the tags are
perhaps around. Nevermind, I know I have to fetch with --tags:
Still no tags there, because they are out of the 1.9.x branch that I have
checked out. To see them, I have to "Show all branches and tags" in egit.
Sadly, that brings also master and other branches, that I do not want to
see, but let's try to ignore them, and have a look at what happened between
1.9.0.Final and 1.9.1.Final:
While it is relatively easy to find out how 1.9.1.Final tag relates to
1.9.x branch, I am completely lost on the other end: 1.9.0.Final is a long
fork of 1.9.x that I cannot track down visually at all. If 1.9.0.Final and
1.9.1.Final tags were a part of 1.9.x history, my eyes would be much
happier. That's it.
I'm lost, can you describe that shorter please?
Thanks,
-- Peter
>
> (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.
>
I disagree, I want a complete record of what's been done in JIRA.
Upgrading of dependencies should not just be done randomly. It has a
reasoning behind it (for example a security fix, or to re-allign with WF
dependencies, or whatever) without a JIRA you don't have that. Same goes
for refactoring, they either should be done as part of an existing JIRA or
there should be a JIRA describing why it was done. The work has to be
scheduled the same as all other work.
For minor documentation updates (grammar, spelling fixes, etc.) or minor
pure formatting sure they don't need a JIRA.
All rules come with exceptions, that's just the way of life. However, by
defacto all commits should have an associated JIRA. That's even more
important for external contributions.
>
> (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>
> 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,
>>
>>
>
2967
days inactive
2968
days old
10 comments
4 participants
participants (4)
-
Bill Burke -
John Dennis -
Peter Palaga -
Stian Thorgersen