In message 891383.24029.qm@web313.biz.mail.mud.yahoo.com you wrote:

...

I think you should use branches on your local repository, but not on the custodian repo. There, I want to see no branches.

Hmmm. I thought branches would provide an excellent way of putting experimental code 'out there' (i.e. code that's not intended for short-term upstream merging). Is this bad?

I don't know. We will have to learn all together how this works out best.

So far my impression is that git is stil very new to most of the users (and even some of the custodians) so I would like to keep things as simple as possible.

Please feel free to try out how others accept such branches. I can deal with them - just let me know exactly whre to pull from.

But please keep in mind that we just added one level of complexity to the end users by switchign from one central "official" repository to so many separate custodian trees. Adding branches to these trees adds another level of complexity, and my feeling is that this will confuse most users. But I may be wrong.

Best regards,

Wolfgang Denk

Peter Pearse wrote:

...

-----Original Message----- From: u-boot-users-bounces@lists.sourceforge.net [mailto:u-boot-users-bounces@lists.sourceforge.net] On Behalf Of Wolfgang Denk Sent: 05 April 2007 01:25 To: Ben Warren Cc: u-boot-users@lists.sourceforge.net; Jerry Van Baren Subject: Re: [U-Boot-Users] Added a custodian status page to denx.de/UBoot

In message 891383.24029.qm@web313.biz.mail.mud.yahoo.com you wrote:

...

...

I think you should use branches on your local repository,

but not

...

...

on the custodian repo. There, I want to see no branches.

Hmmm. I thought branches would provide an excellent way of putting experimental code 'out there' (i.e. code that's not intended for short-term upstream merging). Is this bad?

Wolfgang Now I believe I can push branches to the u-boot-arm repo

(I was reading gu-arm as git-arm - I should use bigger fonts.....)

I was hoping to push each patch that I approved up to the u-boot-arm as a branch, for others to test.

Then I would ask you to merge from it when testing was complete.

Then I would delete that branch when merged.....

Peter

I would like to give branches a chance. They have been supported since RCS (or before) so most people are familiar with the concept, if perhaps not the actual use. I find branches in git are very usable and extremely useful.

I've added a section describing the use and status of (the) branch(es) in my custodian repository: http://www.denx.de/wiki/UBoot/UBootFdtInfo Now I can simply reply "RTFM" (as if /that/ ever worked ;-).

gvb

In message 000201c7776d$fde43300$821ba8c0@Emea.Arm.com you wrote:

Now I believe I can push branches to the u-boot-arm repo

Yes, you can do that.

(I was reading gu-arm as git-arm - I should use bigger fonts.....)

The "gu" prefix is just our internal market that the user ID is for a "[g]it [U]-Boot" repository.

I was hoping to push each patch that I approved up to the u-boot-arm as a branch, for others to test.

I'm not sure if this is actually a good idea. It may quickly create a mess of branches.

Then I would ask you to merge from it when testing was complete.

Please don;t. I want *you* to perform the merging, and when this was successful, to send me a pull request. This way, I can always pull from your master branch and don;t have to care if there are hundrets of branches in your tree and what is for what.

Then I would delete that branch when merged.....

You cannot delete anything in a git repository. Onc created, i remains there forever.

Best regards,

Wolfgang Denk

Jerry Van Baren wrote:

Wolfgang Denk wrote:

...

In message 000201c7776d$fde43300$821ba8c0@Emea.Arm.com you wrote:

...

Now I believe I can push branches to the u-boot-arm repo

Yes, you can do that.

...

(I was reading gu-arm as git-arm - I should use bigger fonts.....)

The "gu" prefix is just our internal market that the user ID is for a "[g]it [U]-Boot" repository.

...

I was hoping to push each patch that I approved up to the u-boot-arm as a branch, for others to test.

I'm not sure if this is actually a good idea. It may quickly create a mess of branches.

...

Then I would ask you to merge from it when testing was complete.

Please don;t. I want *you* to perform the merging, and when this was successful, to send me a pull request. This way, I can always pull from your master branch and don;t have to care if there are hundrets of branches in your tree and what is for what.

...

Then I would delete that branch when merged.....

You cannot delete anything in a git repository. Onc created, i remains there forever.

Best regards,

Wolfgang Denk

I have not looked in the repository to see what it actually does, but "git branch -d" deletes merged branches (it refuses to delete unmerged branches) and "git branch -D" deletes unmerged branches. I presume this does not leave much detritus.

If we use branches:

1. Primarily used in the custodian trees: a) Useful for keeping track of work in progress b) Specifies what Wolfgang needs to pull into the mainline
2. Must be kept clean - delete ones no longer useful
3. VERIFY/merge with the mainline BEFORE requesting a pull. If Wolfgang finds a pull requires a merge, YOU HAVE FAILED as a custodian (or u-boot's world has shifted under your feet - probably the latter;-)

I see 1b) as being very important. Wolfgang has been VERY responsive for pull requests (THANKS!) compared to the pre-custodian days. If it takes more than a few days to pull a set of changes into the mainline, branches are the only practical way to keep track of what is pending. Trying to say "pull from 7cd5da0fe877e7171a4cdd44880bce783132871a to aea03c4e8c3a21ce43d3faf48a6e6d474c8bdf73" is NASTY (OK, that was a bit of a paper tiger).

On the Custodian page http://www.denx.de/wiki/view/UBoot/CustodianGitTrees#Pulling_changes_from_the_master I took a crack at the process to do (3) - I don't believe my recipe is correct yet. Maybe I'll get the right recipe on my next change or maybe a git wizard will update it. (I think the best approach is to create a temporary merge branch in your local repo, pull the latest "master" into it, pull your "to-be-pulled" branch into it, resolve any problems, and then delete the temp merge branch.)

gvb

OK, I thought about it for 30 seconds and I think this is a good recipe (still to be proofed out): http://www.denx.de/wiki/view/UBoot/CustodianGitTrees#Tips_for_maintaining_custodian_t especially the section "BEFORE Requesting a Pull"

Best regards, gvb

On 4/5/07, Ben Warren bwarren@qstreams.com wrote:

Jerry,

On Thu, 2007-04-05 at 10:31 -0400, Jerry Van Baren wrote:

...

If we use branches:

1. Primarily used in the custodian trees: a) Useful for keeping track of work in progress b) Specifies what Wolfgang needs to pull into the mainline
2. Must be kept clean - delete ones no longer useful
3. VERIFY/merge with the mainline BEFORE requesting a pull. If Wolfgang finds a pull requires a merge, YOU HAVE FAILED as a custodian (or u-boot's world has shifted under your feet - probably the latter;-)

I see 1b) as being very important. Wolfgang has been VERY responsive for pull requests (THANKS!) compared to the pre-custodian days. If it takes more than a few days to pull a set of changes into the mainline, branches are the only practical way to keep track of what is pending. Trying to say "pull from 7cd5da0fe877e7171a4cdd44880bce783132871a to aea03c4e8c3a21ce43d3faf48a6e6d474c8bdf73" is NASTY (OK, that was a bit of a paper tiger).

I think I'm more in agreement with Wolfgang on this. The master branch should be what he pulls from, and code there should be expected to be ready for inclusing in the main tree.

I was thinking of using branches for less trivial changes. For example, if somebody submits a new driver, the custodian would put in on a 'testing' branch after it passes coding style and peer-review of logic. He/she would then send out an invitation for testers. After the custodian and others are satisfied, the branch is merged with master, and a pull request is made to Wolfgang.

Branches could also be used for more radical re-factoring efforts. For example, I'm not very happy with the mess that is 'eth.c', with all its #ifdef-wrapped initialize() functions. When time permits, I'd like to do this in a cleaner way and invite others to help out with design/coding/testing. Another example is the work Grant's doing on the memory commands. It seems to me that branches are the way to go here.

Maybe I'm over-complicating things. Maybe we're all really in complete agreement and I just didn't parse your ideas properly. Stranger things have happened...

I have some patches in hand, and they are not common enough to be committed into mainline, but they are really useful for the user. So, I'm thinking, keep two branches in the git repository, one is for upstream, I put everything needed to this branch request Wolfgang to review and merge; the other is master, I apply all unacceptable patches on this branch, so that user can clone it and simply build to get a more feature u-boot. The point that put all unacceptable patches to the master branch is making git-clone like as cvs/svn checkout, user don't need to do anything but only "make" the package and get the binary. Just my thoughts.

Does this make sense?

-Aubrey

On 4/6/07, Wolfgang Denk wd@denx.de wrote:

In message 27d85ee10704050821j19a6bbd8j19e820b8ee47727d@mail.gmail.com you wrote:

...

I have some patches in hand, and they are not common enough to be committed into mainline, but they are really useful for the user.

Sounds like an oxymoron to me. If they are usefulk to many people, then why are they "not common enough to be committed into mainline"?

-- The patch like Mike posted here, clobber the u-boot style, but make u-boot more portable. -------------------------------------------------

we've moved TEXT_BASE out of the build system for Blackfin and into the config header so that when porting to a new board, users dont need to set both the CFG_MONITOR_BASE and TEXT_BASE to the same value in two remotely different files

for u-boot general though, i'd like to apply the attached patch that simply says only utilize TEXT_BASE in global common files if it is set ... that way everyone else can continue to use TEXT_BASE in their board specific .mk files while in Blackfin, we can simply unset it

------------------------------------------------

-- The patch like the SPI patch I posted here, need time to be processed, but because it's a bug, u-boot can't work properly without it.

-- The patch like ATA patch in my hand, we enabled the TRUE IDE feature for CF flash card access, but the configuration of the hardware we are using need to clobber the common file ./include/ata.h, because the ata register map is not in a common way.

-- etc.

...

So, I'm thinking, keep two branches in the git repository, one is for upstream, I put everything needed to this branch request Wolfgang to review and merge; the other is master, I apply all unacceptable patches on this branch, so that user can clone it and simply build to get a more feature u-boot.

OK, just do it exactly the other way round: master is for upstream, and you can have a "testing" or "cutsom" or whatever branch for your local stuff.

That means users have to learn more than one git command. if master for the users, they just have to git-clone and build; if another branch for the users, they have to clone and create branch. But yes, it's not a big deal, just my thoughts.

Best Regards, -Aubrey

Ben Warren wrote:

Jerry,

On Thu, 2007-04-05 at 10:31 -0400, Jerry Van Baren wrote:

...

If we use branches:

1. Primarily used in the custodian trees: a) Useful for keeping track of work in progress b) Specifies what Wolfgang needs to pull into the mainline
2. Must be kept clean - delete ones no longer useful
3. VERIFY/merge with the mainline BEFORE requesting a pull. If Wolfgang finds a pull requires a merge, YOU HAVE FAILED as a custodian (or u-boot's world has shifted under your feet - probably the latter;-)

I see 1b) as being very important. Wolfgang has been VERY responsive for pull requests (THANKS!) compared to the pre-custodian days. If it takes more than a few days to pull a set of changes into the mainline, branches are the only practical way to keep track of what is pending. Trying to say "pull from 7cd5da0fe877e7171a4cdd44880bce783132871a to aea03c4e8c3a21ce43d3faf48a6e6d474c8bdf73" is NASTY (OK, that was a bit of a paper tiger).

I think I'm more in agreement with Wolfgang on this. The master branch should be what he pulls from, and code there should be expected to be ready for inclusing in the main tree.

I was thinking of using branches for less trivial changes. For example, if somebody submits a new driver, the custodian would put in on a 'testing' branch after it passes coding style and peer-review of logic. He/she would then send out an invitation for testers. After the custodian and others are satisfied, the branch is merged with master, and a pull request is made to Wolfgang.

Branches could also be used for more radical re-factoring efforts. For example, I'm not very happy with the mess that is 'eth.c', with all its #ifdef-wrapped initialize() functions. When time permits, I'd like to do this in a cleaner way and invite others to help out with design/coding/testing. Another example is the work Grant's doing on the memory commands. It seems to me that branches are the way to go here.

Maybe I'm over-complicating things. Maybe we're all really in complete agreement and I just didn't parse your ideas properly. Stranger things have happened...

Thoughts?

Ben

I think we are fundamentally in agreement, but my point of view is that a custodian repository is, by definition, (fairly) radical changes. My concern is that, if we restrict ourselves to only the mainline of the custodian repository, it is very difficult to have more than one change "in flight" and it makes it nearly impossible to publish "work in progress" that isn't ready to be pulled yet. Wolfgang has been very responsive (have I said THANKS! yet?) so time of flight for pull requests has not been a problem... yet.

Best regards, gvb