From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerry Van Baren Date: Tue, 22 Jan 2008 08:32:49 -0500 Subject: [U-Boot-Users] Revised custodian git writeup In-Reply-To: <20080122085533.696E924781@gemini.denx.de> References: <20080122085533.696E924781@gemini.denx.de> Message-ID: <4795F081.5050204@ge.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Wolfgang Denk wrote: > Hello, > > in message <47954A7D.4070507@gmail.com> you wrote: >> I've rewritten the "Tips for maintaining custodian trees" section to >> reflect Wolfgang's request that the "master" branch be used for patches >> for him to pull. >> >> Conceptually, this is very different from my previous recommendation / >> methodology writeup. In practice, however, it is a trivial change. The >> fundamental difference is to create a separate branch ("uboot") to track >> the master repo and rebase the "master" branch against that, instead of >> vice versa. > > Rebasing the master branch, i. e. the one I'll be pullung from? > > Are you sure that is a good idea? Note that I (and probably others) > will be pulling from that branch, and not only once! > > Quote from the git-rebase man page: > > ... > NOTES > When you rebase a branch, you are changing its history in a > way that will cause problems for anyone who already has a copy > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > of the branch in their repository and tries to pull updates > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > from you. You should understand the implications of using git > ^^^^^^^^^ > rebase on a repository that you share. > ... > > Best regards, > Wolfgang Denk Well, that is what I understood you to be asking for, and it worked this past merge window. That could have been luck, but I suspect not. The conflicting requirements are: 1) Wolfgang wishes to pull from the subrepo "master" branch 2) Subrepository custodians must rebase to pull the latest changes and fix any merge conflicts so that Wolfgang's pulls don't have merge conflicts. I don't believe the rebasing will cause problems because the rebasing is pulling from the u-boot.git master repository (or possibly u-boot-testing.git) which is rebuilding the subrepo "uboot" branch to match the u-boot.git master, and then rebasing the subrepo "master" based on the u-boot.git master. This will make the subrepo "master" *match* the u-boot.git master *plus* append the new patches to be pulled. I think the difference with our use vs. the general case that the warning applies to is that the custodians are making their "master" branch conform exactly to the u-boot.git master branch and then adding on the patches to be pulled. Disclaimer: The following is my reasoning, *not* experience, and could be full of "stuff." In the general (problematic) case, I think the problem is that someone snapshots a branch (clones / pulls), that branch gets rewritten in a way that doesn't match the snapshot, and then a follow-on pull will fail. The easiest solution in that case is to use the -f force flag, which will rewrite the local branch to match the rebased master. The two differences, as I see it, are: 1) Wolfgang's u-boot.git is The Master, the custodian repos conform to that. (If things get messed up, with a -f force, but that shouldn't happen I don't think.) 2) We are interested in feeding patches to u-boot.git, not with preserving the history of our custodian repos. Illustration: |<--- tracks u-boot.git, changes -->|<--- subrepo patches --->| ---o----o----o----o---o---o----o----o----o---o----o---o---o---o Since Wolfgang pulls the new patches into u-boot.git and the subrepo "merge" branch tracks u-boot.git, he will get (should get | has gotten) the new patches with no problems. The eye opening thing about git for me has been its changeset methodology (suh-weet, as jdl would say ;-) and its hash identification of the changesets so it can track what it has already applied and Do The Right Thing[tm]. Best regards, gvb