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:
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.
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.
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?