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,
--
Albert.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
