<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 11 March 2016 at 14:45, Peter Palaga <span dir="ltr"><<a href="mailto:ppalaga@redhat.com" target="_blank">ppalaga@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>Hi Stian, inline...<span class=""><br>
<br>
On 2016-03-11 06:53, Stian Thorgersen wrote:<br>
</span></div><span class="">
<blockquote type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 10 March 2016 at 22:17, Peter
Palaga <span dir="ltr"><<a href="mailto:ppalaga@redhat.com" target="_blank">ppalaga@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi
Stian,<br>
<br>
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.<br>
<br>
(1)<span><br>
> With JIRA key in commit and PRs linked in JIRA we
get a good history<br>
> that is useful in the future to identify what was
changed and why.<br>
<br>
</span>
To see *what* was changed, I do not need to go to Jira.
Git history is the ultimate source of that info.<br>
<br>
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?<br>
</blockquote>
<div><br>
</div>
<div>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:</div>
<div><br>
</div>
<div>* 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.</div>
</div>
</div>
</div>
</blockquote></span>
Yes, I fully agree that the linking from Jira to GitHub makes sense.<span class=""><br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>* 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.</div>
</div>
</div>
</div>
</blockquote></span>
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.</div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><span class=""><br>
<br>
<blockquote type="cite">The work has to be scheduled the same as all
other work.</blockquote></span>
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.</div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><span class=""><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
(2) I want tags in branches.<br>
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.<br>
<br>
Please consider tagging the usual way.<br>
</blockquote>
<div><br>
</div>
<div>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? <br>
</div>
</div>
</div>
</div>
</blockquote></span>
Sure. This is the "normal" way, where tags 0.17.Final and 0.16.Final
are *inside* a branch (master branch in this case):<br>
<img src="cid:part2.07070501.02030608@redhat.com" alt=""><br>
<br>
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.<br>
<br>
OTOH in KC, when I forget to fetch with --tags, switching to 1.9.x
branch I get only this:<br>
<img src="cid:part3.01070701.05060108@redhat.com" alt=""><br>
<br>
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:<br>
<img src="cid:part4.00000308.01020105@redhat.com" alt=""><br>
<br>
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:<br>
<img src="cid:part5.09080009.07070200@redhat.com" alt=""><br>
<br>
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.<br></div></blockquote><div><br></div><div><br></div><div>I'm lost, can you describe that shorter please?</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
<br>
Thanks,<br>
<br>
-- Peter<div><div class="h5"><br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
(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:<br>
* upgrades of dependencies<br>
* refactorings<br>
* various formatting and license header fixes<br>
I hope most of you will agree here.<br>
</blockquote>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>For minor documentation updates (grammar, spelling
fixes, etc.) or minor pure formatting sure they don't need
a JIRA.</div>
<div><br>
</div>
<div>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.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
(4) Pro tip for Chrome users:<br>
I created a content script that makes Jiras and BZs on
GitHub clickable links. This is what it looks like: <a href="http://snag.gy/rq6Ja.jpg" rel="noreferrer" target="_blank"></a><a href="http://snag.gy/rq6Ja.jpg" target="_blank">http://snag.gy/rq6Ja.jpg</a>
How to install: <a href="https://goo.gl/bYUbHS" rel="noreferrer" target="_blank">https://goo.gl/bYUbHS</a><br>
<br>
Thanks,<br>
<br>
Peter
<div>
<div><br>
<br>
On 2016-03-10 19:12, John Dennis wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 03/10/2016 01:03 PM, Bill Burke wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Is there a way to automatically squash everything
to your latest<br>
commit?<br>
</blockquote>
<br>
Maybe not automatically, but the conventional way to
squash commits is<br>
with interactive rebase, e.g.<br>
<br>
% git rebase -i commit<br>
<br>
where commit is the commit id of the *prior* commit
you want to start<br>
the squashing from. Git will fire up your defined
editor and you just<br>
replace the pick keyword with the squash keyword for
each commit to be<br>
squashed. Many examples on the web. It's not
automatic but usually less<br>
than a minute from start to finish.<br>
<br>
HTH,<br>
<br>
</blockquote>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br></div></div>