Hi Tom, On Tue, 9 Oct 2012 14:32:08 -0700, Tom Rini <tr...@ti.com> 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. > > > 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? IIUC the current rule for U-Boot is that master branches do not rebase while next branches can (as Tom said). Apart from this, I'm not sure why forbidding fast-forward is a good thing, but if there are benefits, why not. Re merging from upstream back into downstream branches, I tend to think that must be allowed considering custodian trees are supposed to be useable, and as such may need to merge back from mainline. And I am pretty sure we don't need to create branches "for such version" "based on such version" all the time; keeping each custodian master current enough should suffice IMO. Amicalement, -- Albert. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
