[Development] the need to add a Task-Number in the release branch ...
Oswald Buddenhagen
oswald.buddenhagen at digia.com
Thu Nov 14 13:50:23 CET 2013
On Thu, Nov 14, 2013 at 07:52:27AM +0000, Knoll Lars wrote:
> On 13.11.13 13:38, "Oswald Buddenhagen" <oswald.buddenhagen at digia.com> wrote:
> >or to put is a bit concisely, the proposal is to simply pay attention to
> >the existing rules consistently instead of creating an entirely
> >unnecessary "paper trail".
>
> I agree with the proposal.
> But if thereĀ¹s no associated JIRA task, the commit message has to be
> clear and state why this change belongs into the release branch.
> Comments in gerrit are not good enough, as they are hard to trace.
>
this is exactly what this was supposed to preempt:
> >creating jira tasks just for the sake of being able to reference them in
> >the commit messages does not improve the quality of the git history.
> > [...]
the point is that once the change is in, the historical context is
irrelevant (the additional information doesn't answer why the change was
done, it doesn't show how the code evolved, it doesn't show whom to ask
about it, etc. - it's just noise). if the context needs to be determined
for some weird reason, that is certainly process-oriented, and can be
done much better with the tool we use for that: gerrit (just take the
change-id from the commit and enter it into gerrit's search field. i
regularly do that; it's a much faster and more reliable way to find out
when and into which branch a commit originally went, than trying to
reverse-engineer the git commit tree).
More information about the Development
mailing list