From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerry Van Baren Date: Thu, 05 Apr 2007 10:56:03 -0400 Subject: [U-Boot-Users] Added a custodian status page to denx.de/UBoot In-Reply-To: <4615085F.40108@smiths-aerospace.com> References: <20070405140917.62EF2352604@atlas.denx.de> <4615085F.40108@smiths-aerospace.com> Message-ID: <46150E03.5050408@smiths-aerospace.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 > > 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): especially the section "BEFORE Requesting a Pull" Best regards, gvb