On 12/09/2013 02:50 PM, Martin Kosek wrote:
On 12/09/2013 02:35 PM, Simo Sorce wrote:
On Mon, 2013-12-09 at 12:39 +0100, Martin Kosek wrote:
On 12/09/2013 12:08 PM, Tomas Babej wrote:
On 12/05/2013 01:37 PM, Petr Viktorin wrote:
Consider this scenario:
- Nathaniel submits RADIUS patches that update the API version (from 2.69 to
2.70)
- I have ACI patches that also bump the version (from 2.69 to 2.70)
- Nathaniel's patches gets accepted
- I rebase my ACI patches onto master. Git thinks that the 2.69->2.70 change
is already done, so it leaves VERSION unchanged.
I can solve this locally by telling Git to not merge VERSION automatically,
but I think it would be helpful to add a unique comment to each change so
that everyone gets a conflict cases like this.
Do you agree?
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Makes sense to me.
I'd just add a comment so that the purpose of the last change comment is also
obvious for the new developer perusing the VERSION file.
Maybe something along the lines of:
########################################################
IPA_API_VERSION_MAJOR=2
IPA_API_VERSION_MINOR=70
+# Update the last change entry to enforce conflict on merging two independent
branches into master.
+# Last change: npmccallum - RADIUS support
I don't think this is necessary, IMO "Last change:" is enough as
instructions.
I spoke with Petr offline, to me it would make bigger sense if we just forbid
automatic merging of this line on the git server side (if possible) instead of
adding other arbitrary work to our development process.
IIRC, Petr3 said it should be possible to do.
Except it may not fix the issue, if someone does a rebase on his machine
and resubmit a patch to the list w/o noticing the change was effectively
dropped.
Simo.
I thought that the point of the anti-merge protection is to prevent git merging
tools to prevent automatic rebase of this particular line and force manual
merging, i.e. force increasing the number.
When the file is equal on both sides of the merge, Git just uses the
common file, and doesn't consider it for merging.
So unfortunately, git attributes won't work here; there needs to be
another change in the file.
I did say otherwise, sorry for that.
--
Petr³
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
