On 07/18/2013 02:01 PM, Alexander Bokovoy wrote: > On Thu, 18 Jul 2013, Petr Viktorin wrote: >> On 07/18/2013 10:10 AM, Alexander Bokovoy wrote: >>> On Thu, 18 Jul 2013, Alexander Bokovoy wrote: >>>> On Mon, 15 Jul 2013, Ana Krivokapic wrote: >>>>> Hello, >>>>> >>>>> This patch addresses ticket >>>>> https://fedorahosted.org/freeipa/ticket/3652. >>>> Could you please rebase it on top of git master? >>> BTW, I was thinking on it and given that majority of rebases like this >>> one come due to spec changes, may be we could establishe a practice to >>> send spec-related changes as a separate patch in a patchset? >>> >>> This would allow easily testing the actual code changes since you don't >>> really need spec changes at that point or could handle it clearer with >>> pre-installed build dependencies. >>> >>> >> >> Or you could just set the union merge strategy on the spec file. >> This is potentially dangerous so only do it if for pushing to master you >> apply patches in a separate "clean" repository without this setting. >> >> Add the following line to .git/info/gitattributes: >> freeipa.spec.in merge=union >> >> Docs & caveats: >> https://www.kernel.org/pub/software/scm/git/docs/gitattributes.html#_built_in_merge_drivers >> > I would still prefer to have the changes in separate patches in a > patchset simply because it makes clearer and easier to handle in active > development.
Hmm, I am personally not convinced - when I just update one Requires, splitting it to 2 patches seems as an overkill to me... > > When we push commits to the main git tree, we anyway push whole patchset > as one push operation. As result, anyone who pulls that tree, will get > consistent patchset -- be it another developer or continuous integration > machinery. For developers who touch spec files reduced context of the > changes in a pulled tree will also be helpful. > > Besides that, you anyway will need to do manual adoption after > merge=union in order to get changelog entries in proper chronological > order and release numbering. I am still not sure about the gain of this - unless people provide special patch with comment for all affected branches, I will have to merge the doc change manually (+ give higher maintenance effort by splitting the patches again). To sum it up, I would not personally make this a strict rule unless we find that current patches with spec comment included are unbearable (so far, they were not unbearable for me...). Martin _______________________________________________ Freeipa-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-devel
