From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id EBA69FA3C for ; Fri, 25 Nov 2016 20:56:04 +0100 (CET) Received: from cpe-2606-a000-111b-40ed-215-ff-fecc-4872.dyn6.twc.com ([2606:a000:111b:40ed:215:ff:fecc:4872] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1cAMbH-0007dC-J1; Fri, 25 Nov 2016 14:56:01 -0500 Date: Fri, 25 Nov 2016 14:55:50 -0500 From: Neil Horman To: Thomas Monjalon Cc: Ferruh Yigit , dev@dpdk.org, "Mcnamara, John" Message-ID: <20161125195550.GA14342@neilslaptop.think-freely.org> References: <20161123201330.GD6961@hmsreliant.think-freely.org> <1598958.4NzbtDc3LW@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1598958.4NzbtDc3LW@xps13> User-Agent: Mutt/1.7.1 (2016-10-04) X-Spam-Score: -2.9 (--) X-Spam-Status: No Subject: Re: [dpdk-dev] Proposal for a new Committer model X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 19:56:05 -0000 On Thu, Nov 24, 2016 at 10:17:09AM +0100, Thomas Monjalon wrote: > 2016-11-23 15:13, Neil Horman: > > Can either you or thomas provide some detail as to how you are doing patch > > management between trees (details of the commands you use are what I would be > > interested in). It sounds to me like there may be some optimization to be made > > here before we even make changes to the subtrees. > > Until now, we preferred avoiding merge commits. > That's why I rebase sub-trees to integrate them in the mainline. > As Ferruh explained, it does not require more work because sub-trees are > regularly rebased anyway. > And I use a script to keep original committer name and date. > > Hope it's clear now > It is clear, but I would make the assertion that performing that rebase yourselves (and arguably having the subtree maintainers do that too), you are undoing all the speedup that you would otherwise have gained. To illustrate, from what it sounds like to me, this is your workflow, from the moment that a merge window starts: 1) Each subtree maintainer syncrhonizes with your tree (either via a rebase, or a simple pull and creation of a new next version branch), the specific method can really be left up to the preference of the subtree maintainer 2) Developent procedes in parallel on multiple subtrees, and to your tree (for those patches that have no other designated subtree) 3) At some point, you opt to merge subtrees to your trees. For each tree you ostensibly then need to: 3a) Inform the subtree maintainer (or otherwise record the point up to which you decided to integrate) 3b) Grab a copy of that tree from the start to the end point (either via a remote branch clone or some other method) 3c) Rebase the branch in 3(b) to the HEAD of your tree, correcting any errors along the way 3d) preform a merge to your master branch, which, after 3(c), will by definition be a fast forward branch While thats a workable solution, it suffers from many drawbacks: a) It looses your commit history. That is to say, with a true merge, you record several other relevant pieces of information, including: * The branch/tree that the series came from * The changes that needed to be made to make the series fit (conflict tracking) * The sha1 sums of the commits (immutable changeset tracking). By rebasing you loose all of that, especially that last piece because the rebase you preform changes your shasums. With a non-merge, you keep all that information properly. b) You increase your error risk. With a true merge, all the changes you need to make to get a merge to resolve properly are contained in a single commit (the merge commit), providing easy review of your updates (not that they should happen frequently). By rebasing, you are left with potentially changed commits that aren't trackable or easily comparable to the origional submission. c) Perhaps most importantly, you serialize the entire process. To follow the above, you need to merge one branch at a time, rebasing each until it works properly, then merging it. With a true merge, you are afforded the opportunity to merge any number of branches in parallel (see git-octopus-merge). Apologies if this was discussed on list previously, but what was the percieved advantage to avoiding merge commits? It seems like alot of lost opportunity to avoid something that is actually fairly informative in the toolchain. Regards Neil