Hi Tom,
On Wed, Oct 10, 2012 at 9:59 AM, Tom Rini trini@ti.com wrote:
On Tue, Oct 09, 2012 at 04:14:23PM -0600, 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?
I'm referring to that it's always rebased on top of Linus' tree. That's what caused the issue here, u-boot-usb was based on top of u-boot/next (which is may not have strictly needed to be) so I did the job of rebasing for Marek since it was an easy one.
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...
Now, having a linux-next style daily merge of u-boot-*/next would be pretty awesome.
Well, it's a merge of what people want to get into the next merge window, as often as they're willing to submit if they are a custodian or as often as I can otherwise. In fact, right now some pull requests need to be on top of next rather than a "stable" point because we're making some pretty big cleanups and changes in a few areas right now.
I'm no git guru, so this may not be sane, but here goes:
u-boot-master and $(repo)-master are parallel branches - $(repo) maintainer merges u-boot-master regularly and applies $(repo) specific patches to $(repo)-master during the merge window (and critical fixes during the -rc cycle). Tom merges the various $(repo)-master's into u-boot-master regularly.
u-boot-next and $(repo)-next are also parallel branches. $(repo) maintainer merges u-boot-master and $(repo)-master regularly and applies $(repo) specific patches to $(repo)-master during the -rc cycle. Tom merges the various $(repo)-next's into u-boot-next regularly.
Immediately following a release, Tom merges u-boot-next into u-boot-master
Yes, we get lots of merge commits, but the strategy is very straightforward...
One thing I don't know how to resolve is what happens when a $(repo)-{master, next} does not merge cleanly into u-boot-{master, next}...
Regards,
Graeme