[Freeipa-devel] [PATCH] 0330 - Add comment about last change to VERSION

[Simo Sorce]

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 at 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 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.

-- 
Simo Sorce * Red Hat, Inc * New York