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. > 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. > > 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. > > (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). > > * 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. Interesting. As this is more work on the custodians end, what does everyone else say? -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
