[U-Boot] Custodian branch base commits
The instructions at:
http://www.denx.de/wiki/U-Boot/CustodianGitTrees
... indicate that downstream branches should be rebased onto ${upstream}/master immediately prior to sending a pull request. I'm not sure this is correct any more, given that upstream master branches now pull in downstream branches via "git merge" rather than "git rebase". Should that page be changed?
The question then becomes: What commit should downstream branches use as their baseline. I assert that they should be free to choose any commit in their upstream master branch (or merge in any upstream commit), or any further upstream branch all the way up to u-boot/master.
As background, I want to send a commit to the Tegra tree that enables use of CONFIG_CMD_FS_GENERIC, and additionally, re-write bootcmd in Tegra's default environment to use the new shell commands that config option enables.
However, the commits that implement CONFIG_CMD_FS_GENERIC are in u-boot/master but not yet in u-boot-arm/master. So, Tegra's master branch can't simply be based on current u-boot-arm/master, since if it was, applying my patch would break functionality until it was merged with u-boot/master and so picked up the actual implementation.
Hopefully, u-boot-arm/master will merge in (or get reset to) u-boot/master fairly shortly. However, should Tegra's repo have to wait for this?
Instead, I propose that 2nd-level custodians should be able to do something like:
# (in u-boot-tegra.git, assuming everything is merged already) git checkout master git reset --hard u-boot/master git am patch_that_depends_on_uboot_master # send pull request to u-boot-arm/master
# (in u-boot-tegra.git, assuming some patches already applied locally) git checkout master git merge u-boot/master git am patch_that_depends_on_uboot_master # send pull request to u-boot-arm/master
This should work fine provided that u-boot/master and u-boot-arm/master guarantee never to rebase. If they don't make that guarantee, then I don't think we can be using merges at all anyway, so that shouldn't be an issue.
What do people think?
Dear Stephen Warren,
In message 50900FED.6040508@wwwdotorg.org you wrote:
# (in u-boot-tegra.git, assuming everything is merged already) git checkout master git reset --hard u-boot/master
What would this specific command sequence be good for? [And what exactly is "u-boot/master" supposed to be?]
Best regards,
Wolfgang Denk
On 10/30/2012 12:50 PM, Wolfgang Denk wrote:
Dear Stephen Warren,
In message 50900FED.6040508@wwwdotorg.org you wrote:
# (in u-boot-tegra.git, assuming everything is merged already) git checkout master git reset --hard u-boot/master
What would this specific command sequence be good for? [And what exactly is "u-boot/master" supposed to be?]
Starting a new branch of development from something in the upstream repository. Here's we're re-using existing branch name "master" for the new branch, hence "git reset" rather than "git checkout -b". Resetting the branch and essentially starting from scratch means creating much less of a rats-nest of merges in downstream repos.
u-boot/master is the standard git nomenclature for remote u-boot (assumed to point at git://git.denx.de/u-boot.git) branch master.
Dear Stephen Warren,
In message 5090228A.7090606@wwwdotorg.org you wrote:
# (in u-boot-tegra.git, assuming everything is merged already) git checkout master git reset --hard u-boot/master
What would this specific command sequence be good for? [And what exactly is "u-boot/master" supposed to be?]
Starting a new branch of development from something in the upstream repository. Here's we're re-using existing branch name "master" for the new branch, hence "git reset" rather than "git checkout -b". Resetting the branch and essentially starting from scratch means creating much
Why don't you do just
git branch -D master git checkout -b master u-boot/master
instead?
BTW - why are you doing this on the "master" branch? Any other branch name appears more appropriate to me for such work?
u-boot/master is the standard git nomenclature for remote u-boot (assumed to point at git://git.denx.de/u-boot.git) branch master.
standard git nomenclature? Do you happen to have a pointer for me?
Best regards,
Wolfgang Denk
On 10/30/2012 02:47 PM, Wolfgang Denk wrote:
Dear Stephen Warren,
In message 5090228A.7090606@wwwdotorg.org you wrote:
# (in u-boot-tegra.git, assuming everything is merged already) git checkout master git reset --hard u-boot/master
What would this specific command sequence be good for? [And what exactly is "u-boot/master" supposed to be?]
Starting a new branch of development from something in the upstream repository. Here's we're re-using existing branch name "master" for the new branch, hence "git reset" rather than "git checkout -b". Resetting the branch and essentially starting from scratch means creating much
Why don't you do just
git branch -D master git checkout -b master u-boot/master
instead?
That would work identically. The exact git commands to do this really aren't the point of this conversation.
BTW - why are you doing this on the "master" branch? Any other branch name appears more appropriate to me for such work?
Well, the U-Boot wiki tells all custodians to use a branch named master, and all the custodian repos I've needed to look at follow this convention.
u-boot/master is the standard git nomenclature for remote u-boot (assumed to point at git://git.denx.de/u-boot.git) branch master.
standard git nomenclature? Do you happen to have a pointer for me?
http://git-scm.com/book/ch3-5.html
First sentence of the second paragraph in the body text.
Dear Stephen Warren,
In message 5090423C.5070605@wwwdotorg.org you wrote:
git checkout master git reset --hard u-boot/master
...
Why don't you do just git branch -D master git checkout -b master u-boot/master instead?
That would work identically. The exact git commands to do this really aren't the point of this conversation.
Maybe not for you. But I was trying to understand what you are doing, and I find your approach difficult to read. A "git reset --hard" is nothign I ever do in the normal course of actions.
BTW - why are you doing this on the "master" branch? Any other branch name appears more appropriate to me for such work?
Well, the U-Boot wiki tells all custodians to use a branch named master, and all the custodian repos I've needed to look at follow this convention.
You are supposed to _never_ reset or rebase the master branch.
u-boot/master is the standard git nomenclature for remote u-boot (assumed to point at git://git.denx.de/u-boot.git) branch master.
standard git nomenclature? Do you happen to have a pointer for me?
http://git-scm.com/book/ch3-5.html
First sentence of the second paragraph in the body text.
Ummm... this does not exactly mention that it is considered standard that "u-boot" refers to git://git.denx.de/u-boot.git . Please keep in mind that others might use different names - your original posting did not explain your assumptions.
Best regards,
Wolfgang Denk
On 10/30/2012 04:06 PM, Wolfgang Denk wrote:
Dear Stephen Warren,
In message 5090423C.5070605@wwwdotorg.org you wrote:
git checkout master git reset --hard u-boot/master
...
Why don't you do just git branch -D master git checkout -b master u-boot/master instead?
That would work identically. The exact git commands to do this really aren't the point of this conversation.
Maybe not for you. But I was trying to understand what you are doing, and I find your approach difficult to read. A "git reset --hard" is nothign I ever do in the normal course of actions.
BTW - why are you doing this on the "master" branch? Any other branch name appears more appropriate to me for such work?
Well, the U-Boot wiki tells all custodians to use a branch named master, and all the custodian repos I've needed to look at follow this convention.
You are supposed to _never_ reset or rebase the master branch.
I assume that statement is conditionalized by "within the U-Boot process" and "in the main u-boot.git repository"; it's not necessarily required to be true just due to use of git.
Well, even in recent history, that hasn't been actual practice. The wiki even explicitly tells you to rebase:
http://www.denx.de/wiki/U-Boot/CustodianGitTrees
Who owns updating that? I could take a stab, but since I'm pretty new to U-Boot development, not a custodian, and pushing for changes, I'm probably not the best person to re-write it, and least not without a code-review/patch-based process.
u-boot/master is the standard git nomenclature for remote u-boot (assumed to point at git://git.denx.de/u-boot.git) branch master.
standard git nomenclature? Do you happen to have a pointer for me?
http://git-scm.com/book/ch3-5.html
First sentence of the second paragraph in the body text.
Ummm... this does not exactly mention that it is considered standard that "u-boot" refers to git://git.denx.de/u-boot.git . Please keep in mind that others might use different names - your original posting did not explain your assumptions.
Oh, I thought you were talking about the syntax, not the exact names of remotes and branches.
On 10/30/2012 06:20 PM, Stephen Warren wrote:
On 10/30/2012 04:06 PM, Wolfgang Denk wrote:
Dear Stephen Warren,
In message 5090423C.5070605@wwwdotorg.org you wrote:
> git checkout master > git reset --hard u-boot/master
...
Why don't you do just git branch -D master git checkout -b master u-boot/master instead?
That would work identically. The exact git commands to do this really aren't the point of this conversation.
Maybe not for you. But I was trying to understand what you are doing, and I find your approach difficult to read. A "git reset --hard" is nothign I ever do in the normal course of actions.
BTW - why are you doing this on the "master" branch? Any other branch name appears more appropriate to me for such work?
Well, the U-Boot wiki tells all custodians to use a branch named master, and all the custodian repos I've needed to look at follow this convention.
You are supposed to _never_ reset or rebase the master branch.
I assume that statement is conditionalized by "within the U-Boot process" and "in the main u-boot.git repository"; it's not necessarily required to be true just due to use of git.
Well, even in recent history, that hasn't been actual practice. The wiki even explicitly tells you to rebase:
http://www.denx.de/wiki/U-Boot/CustodianGitTrees
Who owns updating that?
It's a wiki, *nobody* owns it. :-O
I could take a stab, but since I'm pretty new to U-Boot development, not a custodian, and pushing for changes, I'm probably not the best person to re-write it, and least not without a code-review/patch-based process.
I wrote the advice in 2007, relatively early days in our (u-boot's and my) git usage. http://www.denx.de/wiki/view/U-Boot/CustodianGitTrees?rev=1.19 It is definitely worth updating to recommend better techniques.
Best regards, gvb
[snip]
On Tue, Oct 30, 2012 at 11:35:41AM -0600, Stephen Warren wrote:
The instructions at:
http://www.denx.de/wiki/U-Boot/CustodianGitTrees
... indicate that downstream branches should be rebased onto ${upstream}/master immediately prior to sending a pull request. I'm not sure this is correct any more, given that upstream master branches now pull in downstream branches via "git merge" rather than "git rebase". Should that page be changed?
Yes.
The question then becomes: What commit should downstream branches use as their baseline. I assert that they should be free to choose any commit in their upstream master branch (or merge in any upstream commit), or any further upstream branch all the way up to u-boot/master.
I disagree. It should be limited to your direct upstream only because..
As background, I want to send a commit to the Tegra tree that enables use of CONFIG_CMD_FS_GENERIC, and additionally, re-write bootcmd in Tegra's default environment to use the new shell commands that config option enables.
However, the commits that implement CONFIG_CMD_FS_GENERIC are in u-boot/master but not yet in u-boot-arm/master. So, Tegra's master branch can't simply be based on current u-boot-arm/master, since if it was, applying my patch would break functionality until it was merged with u-boot/master and so picked up the actual implementation.
Yay for making use of new functionality, but..
Hopefully, u-boot-arm/master will merge in (or get reset to) u-boot/master fairly shortly. However, should Tegra's repo have to wait for this?
Yes, tegra has to wait otherwise you've just forced u-boot-arm into a re-sync with master and now u-boot-arm can't where problems came from, be it your tree or master. Patience is required, and I expect that Albert will update to current master before starting his pull requests. I also think it's fine to state that your pull request depends on $rev being merged in prior to your pull. But this is roughly how the kernel trees work I believe. You do a series of patches, state your pre-request and deal with merging the changes up the different trees as they are ready for it.
On 10/30/2012 03:19 PM, Tom Rini wrote:
On Tue, Oct 30, 2012 at 11:35:41AM -0600, Stephen Warren wrote:
The instructions at:
http://www.denx.de/wiki/U-Boot/CustodianGitTrees
... indicate that downstream branches should be rebased onto ${upstream}/master immediately prior to sending a pull request. I'm not sure this is correct any more, given that upstream master branches now pull in downstream branches via "git merge" rather than "git rebase". Should that page be changed?
Yes.
The question then becomes: What commit should downstream branches use as their baseline. I assert that they should be free to choose any commit in their upstream master branch (or merge in any upstream commit), or any further upstream branch all the way up to u-boot/master.
I disagree. It should be limited to your direct upstream only because..
As background, I want to send a commit to the Tegra tree that enables use of CONFIG_CMD_FS_GENERIC, and additionally, re-write bootcmd in Tegra's default environment to use the new shell commands that config option enables.
However, the commits that implement CONFIG_CMD_FS_GENERIC are in u-boot/master but not yet in u-boot-arm/master. So, Tegra's master branch can't simply be based on current u-boot-arm/master, since if it was, applying my patch would break functionality until it was merged with u-boot/master and so picked up the actual implementation.
Yay for making use of new functionality, but..
Hopefully, u-boot-arm/master will merge in (or get reset to) u-boot/master fairly shortly. However, should Tegra's repo have to wait for this?
Yes, tegra has to wait otherwise you've just forced u-boot-arm into a re-sync with master and now u-boot-arm can't where problems came from, be it your tree or master.
That is only true if the pull request sent to u-boot-arm from u-boot-tegra is sent or processed before u-boot-arm pulls in the u-boot commit that u-boot-tegra was based upon.
In other words, I don't think this issue requires that leaf repos be based on a commit that's already in their immediate upstream repo, but rather that leaf repos don't send a pull request to their upstream repo until the leaf repo's baseline commit is included in their upstream repo.
The difference here is that it would allow pipelining; leaf repos like u-boot-tegra could grab the latest u-boot/master as a base, debug and fix a bunch of bugs there, and be ready to send the pull request, all in parallel with u-boot-arm actually pulling in u-boot/master.
Without this process, the Tegra maintainer has to synchronously wait for the problematic commits to show up in u-boot-arm before he can even apply fixes for them, even if the fixes are well known and fully developed. Or, we try and apply patches to u-boot-tegra/master (based only on u-boot-arm/master) that fix issues not yet in the branch, in a way that when eventually merged into u-boot/master, the problems there will be fixed. That's quite a lot harder in general!
Patience is required, and I expect that Albert will update to current master before starting his pull requests. I also think it's fine to state that your pull request depends on $rev being merged in prior to your pull.
But that would imply that the git history in the pull request doesn't actually build or run correctly on its own. The only way for it to build or run correctly is for it to be actually based on the commit it depends on. Simply stating patch dependencies works when sending patches as a hint to say when to apply them, but as soon as something is in git, it should work given the actual git history in that branch.
But this is roughly how the kernel trees work I believe. You do a series of patches, state your pre-request and deal with merging the changes up the different trees as they are ready for it.
For patches by email, yes.
For git merges/pulls, a variety of solutions exist:
* All the patches are applied to a single branch. This would require the maintainer that would usually take a dependant patch to ack it so that it can be taken through a different branch where the dependencies are already present.
In this case, the change to use CONFIG_CMD_FS_GENERIC for Tegra could be taken through u-boot/master rather than u-boot-tegra/master, with the appropriate Ack from Tom Warren, since that's where the implementation of CONFIG_CMD_FS_GENERIC was applied.
* The dependencies are placed into a topic branch, which itself is based on an rc or release of the kernel, and this topic branch is merged into all places that wish to apply patches that depend on the topic branch. The topic branch gets pulled up into Linus' tree via paths, which git handles just fine (at least for merges; duplicate direct patch application would be more problematic and is generally avoided).
* Or, development just gets synchronized every ~3 months via the release process. However, that drastically slows the amount of forward progress that can be made.
Hi Stephen,
On Wed, 31 Oct 2012 10:56:08 -0600, Stephen Warren swarren@wwwdotorg.org wrote:
Hopefully, u-boot-arm/master will merge in (or get reset to) u-boot/master fairly shortly. However, should Tegra's repo have to wait for this?
Yes, tegra has to wait otherwise you've just forced u-boot-arm into a re-sync with master and now u-boot-arm can't where problems came from, be it your tree or master.
That is only true if the pull request sent to u-boot-arm from u-boot-tegra is sent or processed before u-boot-arm pulls in the u-boot commit that u-boot-tegra was based upon.
In other words, I don't think this issue requires that leaf repos be based on a commit that's already in their immediate upstream repo, but rather that leaf repos don't send a pull request to their upstream repo until the leaf repo's baseline commit is included in their upstream repo.
Stop me if I'm wrong, but if e.g. u-boot-tegra/master dependsn on some commits from u-boot/master that are not already in u-boot/arm, then when I fetch u-boot-tegra/master, these commits will automatically get fetched along, and when I fetch u-boot/arm, these commits will just be already there.
So what am I missing?
Amicalement,
On 11/03/2012 05:49 AM, Albert ARIBAUD wrote:
Hi Stephen,
On Wed, 31 Oct 2012 10:56:08 -0600, Stephen Warren swarren@wwwdotorg.org wrote:
Hopefully, u-boot-arm/master will merge in (or get reset to) u-boot/master fairly shortly. However, should Tegra's repo have to wait for this?
Yes, tegra has to wait otherwise you've just forced u-boot-arm into a re-sync with master and now u-boot-arm can't where problems came from, be it your tree or master.
That is only true if the pull request sent to u-boot-arm from u-boot-tegra is sent or processed before u-boot-arm pulls in the u-boot commit that u-boot-tegra was based upon.
In other words, I don't think this issue requires that leaf repos be based on a commit that's already in their immediate upstream repo, but rather that leaf repos don't send a pull request to their upstream repo until the leaf repo's baseline commit is included in their upstream repo.
Stop me if I'm wrong, but if e.g. u-boot-tegra/master dependsn on some commits from u-boot/master that are not already in u-boot/arm, then when I fetch u-boot-tegra/master, these commits will automatically get fetched along,
That's correct. The issue is whether this is acceptable, since it means pulling non-Tegra commits into u-boot-arm/master along with the Tegra commits.
and when I fetch u-boot/arm, these commits will just be already there.
I'm not sure what "fetch u-boot/arm" means in that context. I believe we're talking about merging u-boot-tegra/master into u-boot-arm/master, and that merge would happen in your local branch, so I'm not sure why you'd need to fetch anything after the merge?
Are you talking about when you later merge (not fetch) u-boot/master (not u-boot/arm)? If so, then yes, that merge would simply pull in fewer new commits because some would already be there.
Hi Stephen,
On Mon, 05 Nov 2012 10:17:23 -0700, Stephen Warren swarren@wwwdotorg.org wrote:
On 11/03/2012 05:49 AM, Albert ARIBAUD wrote:
Hi Stephen,
On Wed, 31 Oct 2012 10:56:08 -0600, Stephen Warren swarren@wwwdotorg.org wrote:
Hopefully, u-boot-arm/master will merge in (or get reset to) u-boot/master fairly shortly. However, should Tegra's repo have to wait for this?
Yes, tegra has to wait otherwise you've just forced u-boot-arm into a re-sync with master and now u-boot-arm can't where problems came from, be it your tree or master.
That is only true if the pull request sent to u-boot-arm from u-boot-tegra is sent or processed before u-boot-arm pulls in the u-boot commit that u-boot-tegra was based upon.
In other words, I don't think this issue requires that leaf repos be based on a commit that's already in their immediate upstream repo, but rather that leaf repos don't send a pull request to their upstream repo until the leaf repo's baseline commit is included in their upstream repo.
Stop me if I'm wrong, but if e.g. u-boot-tegra/master dependsn on some commits from u-boot/master that are not already in u-boot/arm, then when I fetch u-boot-tegra/master, these commits will automatically get fetched along,
That's correct. The issue is whether this is acceptable, since it means pulling non-Tegra commits into u-boot-arm/master along with the Tegra commits.
To me it is, as long as these non-tegra commits come from a U-Boot repo whose custodian has accepted them. It is the responsibility of the pull requester to indicate if the commits in his request require any commit not already in an upstream repo..
and when I fetch u-boot/arm, these commits will just be already there.
I'm not sure what "fetch u-boot/arm" means in that context. I believe we're talking about merging u-boot-tegra/master into u-boot-arm/master, and that merge would happen in your local branch, so I'm not sure why you'd need to fetch anything after the merge?
Are you talking about when you later merge (not fetch) u-boot/master (not u-boot/arm)? If so, then yes, that merge would simply pull in fewer new commits because some would already be there.
This is what I meant.
Amicalement,
participants (5)
-
Albert ARIBAUD -
Jerry Van Baren -
Stephen Warren -
Tom Rini -
Wolfgang Denk