From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Tue, 9 Oct 2012 18:00:32 -0500 Subject: [U-Boot] U-Boot git usage model In-Reply-To: <5074A1BF.8020602@wwwdotorg.org> (from swarren@wwwdotorg.org on Tue Oct 9 17:14:23 2012) Message-ID: <1349823632.26044.15@snotra> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 10/09/2012 05:14:23 PM, Stephen Warren wrote: > On 10/09/2012 03:32 PM, Tom Rini wrote: > > On Tue, Oct 09, 2012 at 03:03:28PM -0600, Stephen Warren wrote: > >> On 10/09/2012 08:23 AM, Tom Rini wrote: > >>> On Sun, Oct 07, 2012 at 08:49:00PM +0200, Marek Vasut wrote: > >>> > >>>> NOTE: I get a few more size issues with ELDK 4.2 on IXP > >>>> (that big-endian ARM) after this patchset is applied. I > >>>> wonder if we shouldn't just throw these away, since they're > >>>> dead code mostly. > >>>> > >>>> The following changes since commit > >>>> c7ee66a8222660b565e9240775efa4c82cb348c2: > >>>> > >>>> Merge branch 'next' of git://www.denx.de/git/u-boot-ppc4xx > >>>> into next (2012-10-02 10:16:40 -0700) > >>>> > >>>> are available in the git repository at: > >>>> > >>>> > >>>> git://git.denx.de/u-boot-usb.git next > >>>> > >>>> for you to fetch changes up to > >>>> f0ede0e8305bc3c959862446bce40cb028b36293: > >>>> > >>>> usb.h: Add udc_disconnect prototype to usb.h (2012-10-07 > >>>> 02:08:48 +0200) > >>> > >>> I had to rebase this locally to merge (such is next), and now > >>> it's applied to u-boot/next, thanks! > >> > >> Hmm. Can't "git merge" solve merge conflicts just as well as "git > >> rebase"? > >> > >> The problem with rebasing when pulling is that git commit IDs > >> change, so it's much more difficult to determine when a commit is > >> merged into a parent tree; one has to search by commit subject > >> rather than just executing e.g. git branch -a --contains XXX. I > >> thought Albert just agreed to use merges rather than rebases for > >> u-boot-arm for this and perhaps other reasons. > > > > The short answer is that right now, u-boot/next follows the > > linux-next model and we rebase as needed. > > I don't quite follow that; linux-next is also purely merge-based. Are > you referring to the fact that it's re-created every day, and the > source branches that go into the merge can be rebased if needed? What's the difference between "re-created every day" and "rebased every day"? > Instead, I think u-boot/next is just a place where patches get > applied, or branches get merged, before u-boot/master is open to > accept new patches for the next release. Unless I'm misunderstanding > it purpose of course... That was my impression as well. > Now, having a linux-next style daily merge of u-boot-*/next would be > pretty awesome. Not really needed if the main next tree can permanently merge those branches. > >> It would be awesome if U-Boot could adopt something more similar > >> to the Linux kernel's git usage model, namely: > >> > >> * All downstream branches are based off some known stable point > >> in the master branch (e.g. 2012.10-rc1). Before these branches > >> are merged into any other branch, they can be rebased if > >> absolutely needed, but preferably not. > >> > >> * Once a downstream branch is merged upwards, the downstream > >> branch doesn't merge upstream back down into the downstream > >> branch, but either: > >> > >> a) Keeps adding to the existing branch so that incremental pull > >> requests can be sent. How does merging back down prevent incremental pull requests? > >> Or often when u-boot/master has made a complete new release > >> does: > >> > >> b) Creates a new branch based on the latest rc or release from > >> u-boot/master. That's a rebase. How is that better than a (likely fast-forward) merge? > >> (in practice, downstream branches typically end up with something > >> like for-3.5 based on v3.4-rcN, for-3.6 based on v3.5-rcN, > >> for-3.7 based on v3.6-rcN, some running in parallel containing > >> either important bugfixes for the release or new development as > >> determined by the current state of the various releases in the > >> mainline tree). I thought you said your way was less work? :-) > >> * When a branch is merged from a repo to a parent repo, it's > >> always a git merge --no-ff; never a rebase or fast-forward. > >> > >> * In order to resolve merge conflicts/dependencies between > >> different downstream branches, one of the following happens: > >> > >> 1) > >> > >> a) The first downstream branch gets merged into u-boot/master. b) > >> The second downstream branch creates a new branch starting at an > >> an rc or release in u-boot-master that contains it the required > >> patches. c) The dependent patches are applied to the second > >> downstream branch. d) The second downstream branch gets merged > >> into u-boot/master. > >> > >> 2) > >> > >> All the patches that would usually be merged through downstream > >> branch 2 actually get ack'd by the maintainer of downstream > >> branch 2 and applied to downstream branch 1 after the patches > >> they depend on. This is simplest, but may cause complications if > >> both branches need to take patches that build on the merged > >> patches they're merged into an rc or release in u-boot/master. > >> > >> 3) > >> > >> A topic branch is created by one of the downstream maintainers, > >> branched from a u-boot/master rc or release, and containing just > >> the patches that other patches depend on, and this topic branch > >> gets merged into both the two downstream branches for further > >> work. > >> > >> Yes, this does all take a little bit more thought, planning, and > >> co-ordination, but I think having a simpler and more stable git > >> history is worth it. What is the specific improvement in git history as a result of this? > > Interesting. As this is more work on the custodians end, what > > does everyone else say? > > This actually turns out to be less work for custodians if there aren't > any dependencies between patch series, since whenever you send a pull > request right now, you do: > > a) Fetch latest upstream. > b) Rebase onto it. > c) Send pull request. That's what I used to do, but recently Wolfgang said no rebases, so I merge instead. > but with the Linux model, you simply: > > a) Send pull request. > > Admittedly the recipient then might need to resolve some merge > conflicts. However, hopefully people have been planning for these and > have avoided them. How do you plan for them and avoid them, and how is that less work that what we do now? It's one thing if a merge conflict comes from multiple pull requests being processed at once, but someone submitting a pull request should at least make sure that it doesn't conflict with top-of-tree by itself (some actual testing of the merge would be good too...). And to do that, you've got to either merge or rebase, not just blindly request a pull. I especially do not want to have to work with some artificially chosen old tree as my base. I also do not want to create a bunch of named branches for each -Scott