| Message ID | 7E91C59574E9954FA075F8D8CCDF78DB392DCD5D59@HQMAIL04.nvidia.com |
|---|---|
| State | Superseded |
| Headers | show |
Hi Tom, Le 08/12/2011 00:35, Tom Warren a écrit : > Albert, > > This is my first pull request for u-boot-tegra. Let me know if I’ve > screwed it up in any way! Actually: > The following changes since commit 3865b6eba83707e1ad134bd42da426fd032948f5: > > MX35: flea3: changes due to hardware revision B (2011-12-05 18:31:20 +0100) ... This is not the current u-boot-arm/master branch tip, and rebasing on it fails. Please rebase your master branch on top of u-boot-arm/master ("davinci: Remove unwanted memsize.c from hawkboard's nand spl build", commit id 15422043c4a213dc5d7d59a337be1ab34c9b2e7f) then post a new pull request. Amicalement,
On 12/08/2011 12:22 AM, Albert ARIBAUD wrote: > Hi Tom, > > Le 08/12/2011 00:35, Tom Warren a écrit : > >> Albert, >> >> This is my first pull request for u-boot-tegra. Let me know if I’ve >> screwed it up in any way! > > Actually: > >> The following changes since commit 3865b6eba83707e1ad134bd42da426fd032948f5: >> >> MX35: flea3: changes due to hardware revision B (2011-12-05 18:31:20 +0100) > > ... This is not the current u-boot-arm/master branch tip, and rebasing > on it fails. Please rebase your master branch on top of > u-boot-arm/master ("davinci: Remove unwanted memsize.c from hawkboard's > nand spl build", commit id 15422043c4a213dc5d7d59a337be1ab34c9b2e7f) > then post a new pull request. Albert, Given that u-boot-arm/master is continually rebased, how would Tom avoid the following, which I think is what happened: 1) pull u-boot-arm/master 2) apply patches to it 3) test 4) send pull request ... while between (1) and (4), you've rebased u-boot-arm/master? I think in the Linux kernel world, this is avoided by having downstream branches based on stable branches in Linus' tree rather than directly on their upstream. This will still allow pull/merge to work fine, but means that there's never a time window that can invalidate the baseline the pull requests are based on. Would something like this work for U-Boot too? Or perhaps, u-boot-arm could publish a stable branch for downstream to base on, yet allow the rest of master to be rebased as needed?
Hi Stephen, Le 08/12/2011 17:45, Stephen Warren a écrit : > On 12/08/2011 12:22 AM, Albert ARIBAUD wrote: >> Hi Tom, >> >> Le 08/12/2011 00:35, Tom Warren a écrit : >> >>> Albert, >>> >>> This is my first pull request for u-boot-tegra. Let me know if I’ve >>> screwed it up in any way! >> >> Actually: >> >>> The following changes since commit 3865b6eba83707e1ad134bd42da426fd032948f5: >>> >>> MX35: flea3: changes due to hardware revision B (2011-12-05 18:31:20 +0100) >> >> ... This is not the current u-boot-arm/master branch tip, and rebasing >> on it fails. Please rebase your master branch on top of >> u-boot-arm/master ("davinci: Remove unwanted memsize.c from hawkboard's >> nand spl build", commit id 15422043c4a213dc5d7d59a337be1ab34c9b2e7f) >> then post a new pull request. > > Albert, > > Given that u-boot-arm/master is continually rebased, how would Tom avoid > the following, which I think is what happened: > > 1) pull u-boot-arm/master > 2) apply patches to it > 3) test > 4) send pull request > > ... while between (1) and (4), you've rebased u-boot-arm/master? > > I think in the Linux kernel world, this is avoided by having downstream > branches based on stable branches in Linus' tree rather than directly > on their upstream. This will still allow pull/merge to work fine, but > means that there's never a time window that can invalidate the baseline > the pull requests are based on. > > Would something like this work for U-Boot too? > > Or perhaps, u-boot-arm could publish a stable branch for downstream to > base on, yet allow the rest of master to be rebased as needed? Note: the rules I follow for pulling requests to u-boot-arm/master are actually those applying to u-boot/master, so I guess the issue you are raising with u-boot-arm could occur with u-boot/master as well -- it moves just like u-boot-arm does, after all. That being said, I do not reject pull requests solely because they are not based on current u-boot-arm/master, precisely because I know it is a moving target at times. So if the request is not based on top of u-boot-arm/master, I try a rebase myself and if it succeeds trivially and I feel confident that there will be no interaction with the commits I've added in between, then I just accept the (now rebased) pull request -- this I have just done again a few days ago. If the pull request does not rebase trivially, then I ask the submitter to rebase because he's the best person to understand and solve the rebase conflict. I believe this matches the intent of what you are proposing, but anyway, Wolfgang has the last word -- as usual. :) Amicalement,
On 12/09/2011 08:36 AM, Albert ARIBAUD wrote: > Hi Stephen, > > Le 08/12/2011 17:45, Stephen Warren a écrit : >> On 12/08/2011 12:22 AM, Albert ARIBAUD wrote: >>> Hi Tom, >>> >>> Le 08/12/2011 00:35, Tom Warren a écrit : >>> >>>> Albert, >>>> >>>> This is my first pull request for u-boot-tegra. Let me know if I’ve >>>> screwed it up in any way! >>> >>> Actually: >>> >>>> The following changes since commit 3865b6eba83707e1ad134bd42da426fd032948f5: >>>> >>>> MX35: flea3: changes due to hardware revision B (2011-12-05 18:31:20 +0100) >>> >>> ... This is not the current u-boot-arm/master branch tip, and rebasing >>> on it fails. Please rebase your master branch on top of >>> u-boot-arm/master ("davinci: Remove unwanted memsize.c from hawkboard's >>> nand spl build", commit id 15422043c4a213dc5d7d59a337be1ab34c9b2e7f) >>> then post a new pull request. >> >> Albert, >> >> Given that u-boot-arm/master is continually rebased, how would Tom avoid >> the following, which I think is what happened: >> >> 1) pull u-boot-arm/master >> 2) apply patches to it >> 3) test >> 4) send pull request >> >> ... while between (1) and (4), you've rebased u-boot-arm/master? >> >> I think in the Linux kernel world, this is avoided by having downstream >> branches based on stable branches in Linus' tree rather than directly >> on their upstream. This will still allow pull/merge to work fine, but >> means that there's never a time window that can invalidate the baseline >> the pull requests are based on. >> >> Would something like this work for U-Boot too? >> >> Or perhaps, u-boot-arm could publish a stable branch for downstream to >> base on, yet allow the rest of master to be rebased as needed? > > Note: the rules I follow for pulling requests to u-boot-arm/master are > actually those applying to u-boot/master, so I guess the issue you are > raising with u-boot-arm could occur with u-boot/master as well -- it > moves just like u-boot-arm does, after all. Doesn't u-boot/master only move forward by merges, whereas u-boot-arm/master move forward by rebases? When the base branch moves forward with merges, there's no issue, since the point the child branch was branched from always exists in the history of the parent branch, so "git merge" always knows what to use as the base of the 3-way merge. With rebases, the history the child branch is based upon no longer exists in the parent. > That being said, I do not reject pull requests solely because they are > not based on current u-boot-arm/master, precisely because I know it is a > moving target at times. So if the request is not based on top of > u-boot-arm/master, I try a rebase myself and if it succeeds trivially > and I feel confident that there will be no interaction with the commits > I've added in between, then I just accept the (now rebased) pull request > -- this I have just done again a few days ago. If the pull request does > not rebase trivially, then I ask the submitter to rebase because he's > the best person to understand and solve the rebase conflict. > > I believe this matches the intent of what you are proposing, but anyway, > Wolfgang has the last word -- as usual. :) OK, there would most likely be the same merge conflicts with merging rather than rebasing (although I think the 3-way merge process might be easier to resolve than the rebase process), and so I suppose you'd end up rejecting the merge request too. That's seems somewhat different to the kernel process, hence my quest for understanding!
Le 09/12/2011 18:10, Stephen Warren a écrit : > On 12/09/2011 08:36 AM, Albert ARIBAUD wrote: >> Hi Stephen, >> >> Le 08/12/2011 17:45, Stephen Warren a écrit : >>> On 12/08/2011 12:22 AM, Albert ARIBAUD wrote: >>>> Hi Tom, >>>> >>>> Le 08/12/2011 00:35, Tom Warren a écrit : >>>> >>>>> Albert, >>>>> >>>>> This is my first pull request for u-boot-tegra. Let me know if I’ve >>>>> screwed it up in any way! >>>> >>>> Actually: >>>> >>>>> The following changes since commit 3865b6eba83707e1ad134bd42da426fd032948f5: >>>>> >>>>> MX35: flea3: changes due to hardware revision B (2011-12-05 18:31:20 +0100) >>>> >>>> ... This is not the current u-boot-arm/master branch tip, and rebasing >>>> on it fails. Please rebase your master branch on top of >>>> u-boot-arm/master ("davinci: Remove unwanted memsize.c from hawkboard's >>>> nand spl build", commit id 15422043c4a213dc5d7d59a337be1ab34c9b2e7f) >>>> then post a new pull request. >>> >>> Albert, >>> >>> Given that u-boot-arm/master is continually rebased, how would Tom avoid >>> the following, which I think is what happened: >>> >>> 1) pull u-boot-arm/master >>> 2) apply patches to it >>> 3) test >>> 4) send pull request >>> >>> ... while between (1) and (4), you've rebased u-boot-arm/master? >>> >>> I think in the Linux kernel world, this is avoided by having downstream >>> branches based on stable branches in Linus' tree rather than directly >>> on their upstream. This will still allow pull/merge to work fine, but >>> means that there's never a time window that can invalidate the baseline >>> the pull requests are based on. >>> >>> Would something like this work for U-Boot too? >>> >>> Or perhaps, u-boot-arm could publish a stable branch for downstream to >>> base on, yet allow the rest of master to be rebased as needed? >> >> Note: the rules I follow for pulling requests to u-boot-arm/master are >> actually those applying to u-boot/master, so I guess the issue you are >> raising with u-boot-arm could occur with u-boot/master as well -- it >> moves just like u-boot-arm does, after all. > > Doesn't u-boot/master only move forward by merges, whereas > u-boot-arm/master move forward by rebases? Well, as per the wiki, u-boot/master should move by rebases, or more exactly, by fast-forwards, as pull requests to it should always be (re)based on it. > When the base branch moves forward with merges, there's no issue, since > the point the child branch was branched from always exists in the > history of the parent branch, so "git merge" always knows what to use as > the base of the 3-way merge. > > With rebases, the history the child branch is based upon no longer > exists in the parent. If you mean the history of which repo the commit entered initially and which one it went through with each merge, that's true. But do we need this history? Note that if the process should change to merges rather than rebases, I'm ok with that but I believe it might make bisecting more difficult. >> That being said, I do not reject pull requests solely because they are >> not based on current u-boot-arm/master, precisely because I know it is a >> moving target at times. So if the request is not based on top of >> u-boot-arm/master, I try a rebase myself and if it succeeds trivially >> and I feel confident that there will be no interaction with the commits >> I've added in between, then I just accept the (now rebased) pull request >> -- this I have just done again a few days ago. If the pull request does >> not rebase trivially, then I ask the submitter to rebase because he's >> the best person to understand and solve the rebase conflict. >> >> I believe this matches the intent of what you are proposing, but anyway, >> Wolfgang has the last word -- as usual. :) > > OK, there would most likely be the same merge conflicts with merging > rather than rebasing (although I think the 3-way merge process might be > easier to resolve than the rebase process), and so I suppose you'd end > up rejecting the merge request too. That's seems somewhat different to > the kernel process, hence my quest for understanding! Er... Rebase *does* 3-way merges when necessary and possible. I just saw it done while pulling tegra, samsung and imx requests. Amicalement,
On 12/09/2011 10:22 AM, Albert ARIBAUD wrote: > Le 09/12/2011 18:10, Stephen Warren a écrit : ... >> Doesn't u-boot/master only move forward by merges, whereas >> u-boot-arm/master move forward by rebases? > > Well, as per the wiki, u-boot/master should move by rebases, or more > exactly, by fast-forwards, as pull requests to it should always be > (re)based on it. OK, then the process is just different from what I expected. In that case, consider my comments irrelevant. Although, I'm having a hard time reconciling that statement with u-boot/master's history; there are a lot of non-fast-forward merges there. (and fast-forward is a merge, just the simplest case) ... > Er... Rebase *does* 3-way merges when necessary and possible. I just saw > it done while pulling tegra, samsung and imx requests. I don't think that's possible; with rebase, there is no common ancestor, so you can't do a 3-way merge. The rebase conflicts end up being marked up in the conflicting files in a similar fashion to a 3-way merge though, but I think it's somewhat fake and just showing the differences between the base that was in the patch being applied and current code, which isn't quite the same thing.
Le 09/12/2011 18:37, Stephen Warren a écrit : >> Er... Rebase *does* 3-way merges when necessary and possible. I just saw >> it done while pulling tegra, samsung and imx requests. > > I don't think that's possible; with rebase, there is no common ancestor, > so you can't do a 3-way merge. The rebase conflicts end up being marked > up in the conflicting files in a similar fashion to a 3-way merge > though, but I think it's somewhat fake and just showing the differences > between the base that was in the patch being applied and current code, > which isn't quite the same thing. Actually there is a common ancestor in a rebase just as in a merge -- the common ancestor is an attribute of (or more exactly a computation based on) a set of commits, not of an operation. You'll find common ancestors in a rebase operation mentioned in <http://learn.github.com/p/rebasing.html>, for instance. Amicalement,
Albert, This is my first pull request for u-boot-tegra. Let me know if I've screwed it up in any way! The following changes since commit 3865b6eba83707e1ad134bd42da426fd032948f5: MX35: flea3: changes due to hardware revision B (2011-12-05 18:31:20 +0100) are available in the git repository at: git://git.denx.de/u-boot-tegra.git master Simon Glass (9): tegra2: Add arch_cpu_init() to fire up Cortex-A9 tegra2: Simplify tegra_start() boot path arm: Move CP15 init out of cpu_init_crit() tegra2: Enable instruction cache tegra2: Remove unneeded boot code tegra2: Remove unneeded config option tegra2: Remove unused low-level Tegra2 UART code tegra2: Remove unneeded 'dynamic ram size' message tegra2: Don't use board pointer before it is set up Stephen Warren (4): tegra2: Move board_mmc_init into board files tegra2: Modify MMC driver to handle power and cd GPIOs tegra2: Add support for Ventana tegra2: Use new GPIO APIs in gpio_config_uart() MAINTAINERS | 5 + arch/arm/cpu/armv7/start.S | 36 +++--- arch/arm/cpu/armv7/tegra2/Makefile | 5 + arch/arm/cpu/armv7/tegra2/ap20.c | 54 +++++---- arch/arm/cpu/armv7/tegra2/ap20.h | 10 +- arch/arm/cpu/armv7/tegra2/board.c | 35 +++--- arch/arm/cpu/armv7/tegra2/config.mk | 7 +- arch/arm/cpu/armv7/tegra2/lowlevel_init.S | 118 -------------------- arch/arm/include/asm/u-boot-arm.h | 3 + board/nvidia/common/board.c | 58 +--------- board/nvidia/common/board.h | 4 +- board/nvidia/harmony/harmony.c | 57 ++++++++-- board/nvidia/seaboard/seaboard.c | 81 ++++++++------ board/nvidia/ventana/Makefile | 49 ++++++++ boards.cfg | 1 + drivers/gpio/tegra2_gpio.c | 6 +- drivers/mmc/tegra2_mmc.c | 42 ++++++- drivers/mmc/tegra2_mmc.h | 4 +- drivers/serial/Makefile | 1 - drivers/serial/serial_tegra2.c | 77 ------------- include/configs/tegra2-common.h | 3 +- .../serial_tegra2.h => include/configs/ventana.h | 34 +++++- 22 files changed, 308 insertions(+), 382 deletions(-) create mode 100644 board/nvidia/ventana/Makefile delete mode 100644 drivers/serial/serial_tegra2.c rename drivers/serial/serial_tegra2.h => include/configs/ventana.h (51%) ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -----------------------------------------------------------------------------------