1:13 a.m.
Hi,
Yesterday, I've been looking into HHH-5750 and I found it very convenient that I could
look back in Git and find that the original code was introduced for issue HHH-3871 and
later modified for issue HHH-4791.
This gave me a bit of background and actually made me doubt if the proposed fix for
HHH-5750 might not actually reintroduce the original issue (I haven't figured that out
yet, if anyone could help out there, that would be great!)
And after this happy experience, I'm now getting a bit worried that this connection
between Jira and Git might be lost by the Git pull workflow. Let me explain this:
For example this morning I noticed that
https://github.com/hibernate/hibernate-core/pull/22 has been merged into branch 3.6 which
fixes HHH-5756. This merge has introduced the following commits into the 3.6 branch
(again, it's not about the changes itself, but about the workflow):
Merge branch '3.6' of https://github.com/rsvato/hibernate-core into 3.6
commit 0168ffa83cc8eac88453
Moved hbm.xml -> annotations.
commit 350801542c20cfc0fd0a
Tests are slightly changed to do more work
commit e1f8b5e5f2cb107e3277
[#HHH-5756] Ignore collection changes if no revision on collection change is set
commit 3091bbda15b24a0bdf33
Test for creating revision on collection change
commit 387faed8556ca86d8ad4
Maybe I'm missing something, but I don't think I would ever link a commit such as
'Moved hbm.xml -> annotations' to jira issue HHH-5756. And I find it hard to
believe that Jira or fisheye would link it the other way around. From a maintenance point
of view, this looks like nightmare to me.
Now, I'm not sure what the right way would be to fix this. The easiest would probably
be to squash the pull request into a single commit, but I'm open to all suggestions.
Regards,
Erik-Berndt Scheper
Disclaimer:
This message contains information that may be privileged or confidential and is the
property of Sogeti Nederland B.V. or its Group members. It is intended only for the person
to whom it is addressed. If you are not the intended recipient, you are not authorized to
read, print, retain, copy, disseminate, distribute, or use this message or any part
thereof. If you receive this message in error, please notify the sender immediately and
delete all copies of this message.
2:53 a.m.
I don't think it's related to the pull workflow per se.
The recommendation is to almost always add a JIRA issue number to a given commit unless
you fix a minor type or such. That way every commit has an associated JIRA and hopefully
the git/jira link holds.
On top of that, for Hibernate Search. Validator we try to keep the history linear which (I
find) helps read history.
If you compare
https://github.com/hibernate/hibernate-search/network
and https://github.com/hibernate/hibernate-core/network
the railroad system of search is much easier to read.
As a consequence, we never have messages like "Merge branch '3.6' of
https://github.com/rsvato/hibernate-core into 3.6".
This is not related directly to the issue you are describing though I think it helps in
the whole readability scheme.
Emmanuel
On 9 déc. 2010, at 08:13, Scheper, Erik-Berndt wrote:
Hi,
Yesterday, I've been looking into HHH-5750 and I found it very convenient that I
could look back in Git and find that the original code was introduced for issue HHH-3871
and later modified for issue HHH-4791.
This gave me a bit of background and actually made me doubt if the proposed fix for
HHH-5750 might not actually reintroduce the original issue (I haven't figured that out
yet, if anyone could help out there, that would be great!)
And after this happy experience, I'm now getting a bit worried that this connection
between Jira and Git might be lost by the Git pull workflow. Let me explain this:
For example this morning I noticed that
https://github.com/hibernate/hibernate-core/pull/22 has been merged into branch 3.6 which
fixes HHH-5756. This merge has introduced the following commits into the 3.6 branch
(again, it's not about the changes itself, but about the workflow):
Merge branch '3.6' of https://github.com/rsvato/hibernate-core into 3.6
commit 0168ffa83cc8eac88453
Moved hbm.xml -> annotations.
commit 350801542c20cfc0fd0a
Tests are slightly changed to do more work
commit e1f8b5e5f2cb107e3277
[#HHH-5756] Ignore collection changes if no revision on collection change is set
commit 3091bbda15b24a0bdf33
Test for creating revision on collection change
commit 387faed8556ca86d8ad4
Maybe I'm missing something, but I don't think I would ever link a commit such as
'Moved hbm.xml -> annotations' to jira issue HHH-5756. And I find it hard to
believe that Jira or fisheye would link it the other way around. From a maintenance point
of view, this looks like nightmare to me.
Now, I'm not sure what the right way would be to fix this. The easiest would probably
be to squash the pull request into a single commit, but I'm open to all suggestions.
Regards,
Erik-Berndt Scheper
Disclaimer:
This message contains information that may be privileged or confidential and is the
property of Sogeti Nederland B.V. or its Group members. It is intended only for the person
to whom it is addressed. If you are not the intended recipient, you are not authorized to
read, print, retain, copy, disseminate, distribute, or use this message or any part
thereof. If you receive this message in error, please notify the sender immediately and
delete all copies of this message.
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
5148
days inactive
5148
days old
1 comments
2 participants
participants (2)
-
Emmanuel Bernard -
Scheper, Erik-Berndt