[U-Boot-Users] Revised custodian git writeup
http://www.denx.de/wiki/view/UBoot/CustodianGitTrees#Tips_for_maintaining_custodian_t
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.
Best regards, gvb
Hi Jerry,
"gvb.uboot" gvb.uboot@gmail.com writes:
http://www.denx.de/wiki/view/UBoot/CustodianGitTrees#Tips_for_maintaining_custodian_t
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.
This is helpful, thanks for sharing!
Best regards
Markus Klotzbuecher
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
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
On Tue, 22 Jan 2008 09:55:33 +0100 Wolfgang Denk wd@denx.de wrote:
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!
That depends on whether or not you want your commit history filled with "merge with upstream/master" crap or not.
You should only pull when explicitly requested to do so. In that case, if the branch was newly rebased, there will be a clean, linear history from the tip of your master branch to the tip of the one being pulled.
If there are conflicting changes and the merge needs manual intervention, you abort the merge and tell the one sending the pull request that it didn't merge cleanly, please rebase.
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.
And that is, IMO, exactly why you shouldn't be pulling from the master branch in the first place. People who pull regularly to test stuff that is in progress will run into this problem, and they are most likely to pull the master branch because that's the default.
There are two different kinds of users involved here: You (and other maintainers that are "upstream" from someone), and regular users who want to test stuff. Upstream maintainers should receive a clean history, i.e. from a branch that is frequently rebased. At the same time, we should avoid exposing testers to the problems of dealing with a branch that is rebased all the time.
So we need (at least) two different branches that are maintained in different ways, and I think it's easier to tell you, Wolfgang and other upstream maintainers, to pull from a non-master branch than to tell everyone else in the world.
Just my two cents.
Haavard
In message 20080122105016.313d8f88@dhcp-252-066.norway.atmel.com you wrote:
Are you sure that is a good idea? Note that I (and probably others) will be pulling from that branch, and not only once!
That depends on whether or not you want your commit history filled with "merge with upstream/master" crap or not.
...which in turn depends on whether or not you consider a merge commit as crap or not. IMHO it's sometimes valuable information about the history of a project, but YMMV.
My point is a different one, and it seems I never explicitly stated it before:
My idea of a custodian repository is that it is more than just a working tool for collecting patches and preparing these for merge into mainline. My idea is instea that these are pretty much independent incarnations of U-Boot source trees which users (note: users, not only developers) with specific needs or interests can refer to.
For example, in my set of mind somebody interested in the latest 85xx code would clone the 85xx custodian repository, expecting that he finds there the most current code for this family of processors. Probably he will never sync himself against mainline, but instead continue update (pull) from the 85xx custodian repository.
That means, that my idea is that it is the custodian's responsibility to provide a permanently accessable, consistent view of his repository to users. When he collects patches, he will - after sufficient review and testing - decide that these are good enough to go into his repository. And at certain points we will pull all the stuff that has been collected there into mainline.
You should only pull when explicitly requested to do so. In that case,
Actually I fetch from all custodian repos quite frequently. But I do only pull (merge into mainline) when I'm explicitely told.
But note that my idea is that other users may have cloned the custodian repository, and continue to pull from it. For their convenience (and my own) I want to have the current code collected in the master branch, and I think we agree that the master branch must not be rebased.
If there are conflicting changes and the merge needs manual intervention, you abort the merge and tell the one sending the pull request that it didn't merge cleanly, please rebase.
Right - but this does not depend on how the custodian repos are set up or which branch I'm pulling from.
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.And that is, IMO, exactly why you shouldn't be pulling from the master branch in the first place. People who pull regularly to test stuff that is in progress will run into this problem, and they are most likely to pull the master branch because that's the default.
People pulling the master branch have (IMHO) the right to expect a consisten history. It is the custodians responsibility not to merge stuff into the master branch that causes conflicts.
There are two different kinds of users involved here: You (and other maintainers that are "upstream" from someone), and regular users who want to test stuff. Upstream maintainers should receive a clean
I don't think that we are different types of users - maybe from the kind of work we do, but I don't see why we should access the custodian's repository differently. Actually I think it's a pretty good idea if others test the very same code I will be pulling later.
history, i.e. from a branch that is frequently rebased. At the same
I think only "small" topic branches should be rebased - this is the part of the custodian's work that is needed to clean up the stuff and to make it ready for mainline merge. The he prepares a branch for me and ofr other users to pull from.
time, we should avoid exposing testers to the problems of dealing with a branch that is rebased all the time.
ACK.
So we need (at least) two different branches that are maintained in different ways, and I think it's easier to tell you, Wolfgang and other upstream maintainers, to pull from a non-master branch than to tell everyone else in the world.
I still fail to see why separate branches would be needed. I think using the same one makes more sense, as it allows me to pull from tested code.
Best regards,
Wolfgang Denk
On Tue, 22 Jan 2008 14:45:48 +0100 Wolfgang Denk wd@denx.de wrote:
In message 20080122105016.313d8f88@dhcp-252-066.norway.atmel.com you wrote:
Are you sure that is a good idea? Note that I (and probably others) will be pulling from that branch, and not only once!
That depends on whether or not you want your commit history filled with "merge with upstream/master" crap or not.
...which in turn depends on whether or not you consider a merge commit as crap or not. IMHO it's sometimes valuable information about the history of a project, but YMMV.
So you _do_ want that crap in the commit history ;-)
Other people (Linus, for example) do not. I guess I'll just have to use different workflows for my u-boot and Linux work then...but I'm not quite done arguing yet ;-)
My point is a different one, and it seems I never explicitly stated it before:
My idea of a custodian repository is that it is more than just a working tool for collecting patches and preparing these for merge into mainline. My idea is instea that these are pretty much independent incarnations of U-Boot source trees which users (note: users, not only developers) with specific needs or interests can refer to.
For example, in my set of mind somebody interested in the latest 85xx code would clone the 85xx custodian repository, expecting that he finds there the most current code for this family of processors. Probably he will never sync himself against mainline, but instead continue update (pull) from the 85xx custodian repository.
That means, that my idea is that it is the custodian's responsibility to provide a permanently accessable, consistent view of his repository to users. When he collects patches, he will - after sufficient review and testing - decide that these are good enough to go into his repository. And at certain points we will pull all the stuff that has been collected there into mainline.
But the stuff that has been collected may be in completely different states of development. Some patches may have pending review comments (which showed up after they were committed to the repository.) Some patches may need more testing (which they are much more likely to get after they have been committed to the repository.)
When the merge window comes up, the custodian should submit a merge request for all the patches that are considered complete and fully tested, and this usually involves cherry-picking patches into a freshly created branch, making the history non-linear.
Also, if a bug shows up during testing, it should be folded into the original patch before it's merged upstream, or it will break "git bisect". This is just not possible if you only want to pull from a linear master branch.
You should only pull when explicitly requested to do so. In that case,
Actually I fetch from all custodian repos quite frequently. But I do only pull (merge into mainline) when I'm explicitely told.
How about you do those out-of-band pulls from the master branch (which is not to be rebased and may contain stuff that requires more testing) and only pull into mainline from the branch specified by the custodian?
But note that my idea is that other users may have cloned the custodian repository, and continue to pull from it. For their convenience (and my own) I want to have the current code collected in the master branch, and I think we agree that the master branch must not be rebased.
I have no problem with that. I just think that custodians should be allowed to specify a different branch than "master" when sending a pull request.
If there are conflicting changes and the merge needs manual intervention, you abort the merge and tell the one sending the pull request that it didn't merge cleanly, please rebase.
Right - but this does not depend on how the custodian repos are set up or which branch I'm pulling from.
If you only ever want to pull from the master branch, and the master branch can't be rebased, how are we supposed to rebase?
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.And that is, IMO, exactly why you shouldn't be pulling from the master branch in the first place. People who pull regularly to test stuff that is in progress will run into this problem, and they are most likely to pull the master branch because that's the default.
People pulling the master branch have (IMHO) the right to expect a consisten history. It is the custodians responsibility not to merge stuff into the master branch that causes conflicts.
Agreed.
There are two different kinds of users involved here: You (and other maintainers that are "upstream" from someone), and regular users who want to test stuff. Upstream maintainers should receive a clean
I don't think that we are different types of users - maybe from the kind of work we do, but I don't see why we should access the custodian's repository differently. Actually I think it's a pretty good idea if others test the very same code I will be pulling later.
Sure, but some patches may require more testing than others.
history, i.e. from a branch that is frequently rebased. At the same
I think only "small" topic branches should be rebased - this is the part of the custodian's work that is needed to clean up the stuff and to make it ready for mainline merge. The he prepares a branch for me and ofr other users to pull from.
I think your argument is inconsistent. How is "preparing a branch for you to pull" any different from rebasing?
So we need (at least) two different branches that are maintained in different ways, and I think it's easier to tell you, Wolfgang and other upstream maintainers, to pull from a non-master branch than to tell everyone else in the world.
I still fail to see why separate branches would be needed. I think using the same one makes more sense, as it allows me to pull from tested code.
I think you'll receive more well-tested code if you allow custodians to commit patches to "master" earlier. But this necessarily means either being allowed to rebase the "master" branch or using a different branch for merging (which only contains code that has spent a fair amount of time in the master branch.)
IOW, one branch is for stuff that is ready to merge, the other is for the same _plus_ stuff that needs testing. I think using "master" for the latter will give the to-be-tested code much more exposure before it hits mainline, and that's IMO a good thing.
Haavard
On Tuesday 22 January 2008, Haavard Skinnemoen wrote:
I think you'll receive more well-tested code if you allow custodians to commit patches to "master" earlier. But this necessarily means either being allowed to rebase the "master" branch or using a different branch for merging (which only contains code that has spent a fair amount of time in the master branch.)
IOW, one branch is for stuff that is ready to merge, the other is for the same _plus_ stuff that needs testing. I think using "master" for the latter will give the to-be-tested code much more exposure before it hits mainline, and that's IMO a good thing.
while i havent gotten into the game just yet, Haavard's scheme makes more sense to me and seems to address Wolfgang's desire for usable processor trees. the master branch is never rebased and contains all the latest and greatest (and stuff not ready for mainline). when a custodian wants Wolfgang to pull something, they prepare a non-master branch with cleaned up patches and all that and asks Wolfgang to pull on that branch. otherwise there's no way to get users to test out patches that should be ok but not ready just yet for mainline while at the sametime giving Wolfgang something sane to pull from. -mike
In message 20080122152035.22f1dffd@dhcp-252-066.norway.atmel.com you wrote:
Other people (Linus, for example) do not. I guess I'll just have to use different workflows for my u-boot and Linux work then...but I'm not quite done arguing yet ;-)
I appreciate your comments, really. I don't claim to be perfect, on contrary - git is still new to me and I'm trying to find my way. If it turns out that my ideas are wong, or that following my style imposes a high and avoidable burden to many others I will try to adapt.
But the stuff that has been collected may be in completely different states of development. Some patches may have pending review comments (which showed up after they were committed to the repository.) Some patches may need more testing (which they are much more likely to get after they have been committed to the repository.)
When the merge window comes up, the custodian should submit a merge request for all the patches that are considered complete and fully tested, and this usually involves cherry-picking patches into a freshly created branch, making the history non-linear.
I agree, except that my idea would be not to use a freshly created branch, but master.
Also, if a bug shows up during testing, it should be folded into the original patch before it's merged upstream, or it will break "git bisect". This is just not possible if you only want to pull from a linear master branch.
When the custodian's repo continues to use the master branch, and checks in a commit to fix the bug there, git-bisect should still work fine. The difference is that there will be not a single commit for a "perfect", bug-free patch, but a buggy one plus a fix for the bug.
How about you do those out-of-band pulls from the master branch (which is not to be rebased and may contain stuff that requires more testing) and only pull into mainline from the branch specified by the custodian?
I can do this if really needed, but I see trouble ahead. I know myself. I will see a pull request for repo XXX and pull without specifying a branch. Only when I will reply to the message after I'm done to ACK it I will notice that somewhere near the end of the message there is a note saying "please pull from branch YYY". This already happened, so I know what I'm talking about ;-)
I have no problem with that. I just think that custodians should be allowed to specify a different branch than "master" when sending a pull request.
If really necessary I will have to adjust to this, but I'd rather avoid it.
If you only ever want to pull from the master branch, and the master branch can't be rebased, how are we supposed to rebase?
Consider merging into your master branch as the first step of the pull request - this is the point where you give up control over the patch. Assume I would pull the very same moment. How do you rebase after I have pulled from your branch?
I don't think that we are different types of users - maybe from the kind of work we do, but I don't see why we should access the custodian's repository differently. Actually I think it's a pretty good idea if others test the very same code I will be pulling later.
Sure, but some patches may require more testing than others.
Agreed. Hold them in testing branches as long as testingis needed. When they are ready to be merged into mainline, they can go into your master branch, too. And from there I willpick them up.
I think only "small" topic branches should be rebased - this is the part of the custodian's work that is needed to clean up the stuff and to make it ready for mainline merge. The he prepares a branch for me and ofr other users to pull from.
I think your argument is inconsistent. How is "preparing a branch for you to pull" any different from rebasing?
It means rebasing of your working branches so that they are up to date and don't cause conflicts before merging them into your master branch.
I think you'll receive more well-tested code if you allow custodians to commit patches to "master" earlier. But this necessarily means either being allowed to rebase the "master" branch or using a different branch for merging (which only contains code that has spent a fair amount of time in the master branch.)
To me, your master branch is your "stable" code. Code that needs more testing should use a different branch name. Especially if you have different pots on the fire at the same time.
IOW, one branch is for stuff that is ready to merge, the other is for the same _plus_ stuff that needs testing. I think using "master" for
You may want several independet "testing" branches, not only one. master seems not the best choice to me. I think we should use master == stable.
the latter will give the to-be-tested code much more exposure before it hits mainline, and that's IMO a good thing.
I understand your position, too. As mentioned above, I don't claim that my suggestion is perfect or optimal. I developed my own style of working, others developed theirs. This discussion helps to figure out how to make co-operation easier. Thanks!
Best regards,
Wolfgang Denk
-----Ursprungligt meddelande----- Från: u-boot-users-bounces@lists.sourceforge.net [mailto:u-boot-users-bounces@lists.sourceforge.net] För Wolfgang Denk Skickat: den 22 januari 2008 17:35 Till: Haavard Skinnemoen Kopia: U-Boot Users Ämne: Re: [U-Boot-Users] Revised custodian git writeup
In message 20080122152035.22f1dffd@dhcp-252-066.norway.atmel.com you wrote:
Other people (Linus, for example) do not. I guess I'll just have to use different workflows for my u-boot and Linux work then...but I'm not quite done arguing yet ;-)
I appreciate your comments, really. I don't claim to be perfect, on contrary - git is still new to me and I'm trying to find my way. If it turns out that my ideas are wong, or that following my style imposes a high and avoidable burden to many others I will try to adapt.
[SNIP]
This discussion is interesting, but I really would like to see some new code in u-boot's master branch :)
Jocke
On Tue, 22 Jan 2008 17:34:49 +0100 Wolfgang Denk wd@denx.de wrote:
In message 20080122152035.22f1dffd@dhcp-252-066.norway.atmel.com you wrote:
Other people (Linus, for example) do not. I guess I'll just have to use different workflows for my u-boot and Linux work then...but I'm not quite done arguing yet ;-)
I appreciate your comments, really. I don't claim to be perfect, on contrary - git is still new to me and I'm trying to find my way. If it turns out that my ideas are wong, or that following my style imposes a high and avoidable burden to many others I will try to adapt.
Good. I think I understand your position better now, and I think we actually agree on the fundamental goals.
I can do this if really needed, but I see trouble ahead. I know myself. I will see a pull request for repo XXX and pull without specifying a branch. Only when I will reply to the message after I'm done to ACK it I will notice that somewhere near the end of the message there is a note saying "please pull from branch YYY". This already happened, so I know what I'm talking about ;-)
Just triple-click on the line containing the repository URL followed by the branch name and paste it into your terminal after "git pull".
IIRC, this is why Linus insists that people always put the repository URL and the branch on the same line in pull requests, and why git-request-pull does this automatically.
If you only ever want to pull from the master branch, and the master branch can't be rebased, how are we supposed to rebase?
Consider merging into your master branch as the first step of the pull request - this is the point where you give up control over the patch. Assume I would pull the very same moment. How do you rebase after I have pulled from your branch?
Right. This is the way I usually do it, except that I create a fresh branch from the latest upstream master, and that I consider giving up control over the patches the moment I send the pull request, not necessarily when I push.
But these are just details. Your way seems workable too, now that I understand it fully. Thanks for explaining.
I don't think that we are different types of users - maybe from the kind of work we do, but I don't see why we should access the custodian's repository differently. Actually I think it's a pretty good idea if others test the very same code I will be pulling later.
Sure, but some patches may require more testing than others.
Agreed. Hold them in testing branches as long as testingis needed. When they are ready to be merged into mainline, they can go into your master branch, too. And from there I willpick them up.
Ok. The only issue I have with this approach is that people may be less likely to test them when they're not in "master". But I guess announcing things clearly might help -- perhaps by creating a new "testing" branch when submitting a patch series for review and mention this in the introductory email.
I think you'll receive more well-tested code if you allow custodians to commit patches to "master" earlier. But this necessarily means either being allowed to rebase the "master" branch or using a different branch for merging (which only contains code that has spent a fair amount of time in the master branch.)
To me, your master branch is your "stable" code. Code that needs more testing should use a different branch name. Especially if you have different pots on the fire at the same time.
IOW, one branch is for stuff that is ready to merge, the other is for the same _plus_ stuff that needs testing. I think using "master" for
You may want several independet "testing" branches, not only one. master seems not the best choice to me. I think we should use master == stable.
Good point.
the latter will give the to-be-tested code much more exposure before it hits mainline, and that's IMO a good thing.
I understand your position, too. As mentioned above, I don't claim that my suggestion is perfect or optimal. I developed my own style of working, others developed theirs. This discussion helps to figure out how to make co-operation easier. Thanks!
Yes, I think I understand now how I can make this work with only a couple of minor adjustments to my workflow. Thanks!
Haavard
Haavard Skinnemoen wrote:
On Tue, 22 Jan 2008 09:55:33 +0100 Wolfgang Denk wd@denx.de wrote:
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!
That depends on whether or not you want your commit history filled with "merge with upstream/master" crap or not.
You should only pull when explicitly requested to do so. In that case, if the branch was newly rebased, there will be a clean, linear history from the tip of your master branch to the tip of the one being pulled.
If there are conflicting changes and the merge needs manual intervention, you abort the merge and tell the one sending the pull request that it didn't merge cleanly, please rebase.
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.And that is, IMO, exactly why you shouldn't be pulling from the master branch in the first place. People who pull regularly to test stuff that is in progress will run into this problem, and they are most likely to pull the master branch because that's the default.
There are two different kinds of users involved here: You (and other maintainers that are "upstream" from someone), and regular users who want to test stuff. Upstream maintainers should receive a clean history, i.e. from a branch that is frequently rebased. At the same time, we should avoid exposing testers to the problems of dealing with a branch that is rebased all the time.
I don't see this as a big deal because my methodology (and the proper one, IMHO) is to create a branch in my local repo, pull the current state of the target repo into the branch, and then either merge or cherrypick the "foreign" subrepo changes into my working branch in my repo. At that point, I discard the foreign repo branch because it has served its purpose. Because I discard the foreign repo branch, I don't care of the foreign repo gets rebased and its history is rewritten, I've already discarded that history.
If more things change in the foreign repo, I do the same thing over, starting with creating a new branch.
I'm sure that is how Wolfgang pulls subrepos to - not directly, but into a testing branch and then, if it is OK, into the main u-boot.git repo.
Here are my Cliff Notes(R) for a real example of this interaction with u-boot.git and between myself and Kumar, pulling his libfdt updates into my u-boot-fdt.git repo: http://www.denx.de/wiki/view/UBoot/UBootFdtInfo#All_Your_Base_are_Belong_to_Us
This ultimately was merged by Wolfgang into u-boot.git with no problems (yet ;-).
So we need (at least) two different branches that are maintained in different ways, and I think it's easier to tell you, Wolfgang and other upstream maintainers, to pull from a non-master branch than to tell everyone else in the world.
Just my two cents.
Haavard
+ my 2c, gvb
In message 4795F495.70101@ge.com you wrote:
I'm sure that is how Wolfgang pulls subrepos to - not directly, but into a testing branch and then, if it is OK, into the main u-boot.git repo.
Not exactly - insteadof or ratherin addition to brnaches I also use several copies of repositories which I can throw away if needed.
In one such copy I follow all custodian repos using remote tracking branches. This is also used to pull from such a remote tracking branch if I'm ordered to pull from a custodian's repo. If this causes problems, I'll shout on the ML and either clean up or even throw away the whole repo. If it works, I'll pull this repo into the mailin repo.
The reason for using additional copies of repos instead of branche scomes from the fact that (1) I used to use cogito for a long time, which handled branches differently, and (2) I have seen a copule of situations (with earlier versions of git and cogito) that corrupted a repository such that I was not able to repair it. So I try to make sure I can always throw away everything...
Best regards,
Wolfgang Denk
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
Dear Jerry,
in message 4795F081.5050204@ge.com you wrote:
The conflicting requirements are:
- Wolfgang wishes to pull from the subrepo "master" branch
...and others will do that, too, at unknown points of time.
- Subrepository custodians must rebase to pull the latest changes and
fix any merge conflicts so that Wolfgang's pulls don't have merge conflicts.
...must rebase their working branch(es), but there is no need that I'll be pulling from exactly this/these branches.
As explained before, my idea is that the custodians will merge their code into the master branch (a) for others to test it and (b) for me to pull from.
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.
The idea of rebasing the master branch is something that find frightening.
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.
I'm ot sure if I want to have such a requirement.
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.
This is why I think that master should never be rebased. "master" is (IMO) supposed to always provide a consistent history.
The two differences, as I see it, are:
- 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.
Wrong. I *am* interested in preserving the history of the custodian repos. Somebody mostly interested in ARM processors shall be able to use the ARM custodian's repo for all his daily work exactly the same way as he could use the main repo.
Best regards,
Wolfgang Denk
Dear Wolfgang,
Wolfgang Denk wd@denx.de writes:
in message 4795F081.5050204@ge.com you wrote:
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.
I'm ot sure if I want to have such a requirement.
Not doing this makes it hard to use git-request-pull to generate these cute summaries in case you repeatedly update->merge-a-patch.
Best regards
Markus
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
In message 87myqyx7fp.fsf@denx.de you wrote:
Not doing this makes it hard to use git-request-pull to generate these cute summaries in case you repeatedly update->merge-a-patch.
You're suppoed to merge it only when you're done with it - see my previous message: consider merging into your master branch as the first step of my pulling from your tree.
Best regards,
Wolfgang Denk
Wolfgang Denk wrote:
In message 87myqyx7fp.fsf@denx.de you wrote:
Not doing this makes it hard to use git-request-pull to generate these cute summaries in case you repeatedly update->merge-a-patch.
You're suppoed to merge it only when you're done with it - see my previous message: consider merging into your master branch as the first step of my pulling from your tree.
Best regards, Wolfgang Denk
...but this is a contradiction again. Quoting from different WD emails:
As explained before, my idea is that the custodians will merge their code into the master branch (a) for others to test it and (b) for me to pull from.
You're suppoed to merge it only when you're done with it - see my previous message: consider merging into your master branch as the first step of my pulling from your tree.
To me, your master branch is your "stable" code. Code that needs more testing should use a different branch name. Especially if you have different pots on the fire at the same time.
1) Master branch is for others to actively base from 2) Master branch is updated just before a pull request 3) No merge conflicts with the u-boot.git repo when Wolfgang pulls it
These appear to be contradictory goals. #1 and #2 could be argued to not be contradictory, but I'm not buying into that theory. The point of people pulling and testing is to find problem, which should be fixed *before* a pull request. If the master branch has broken code in it, the broken patch will have to be replaced with a fixed patch (rewriting history - oh-oh) or the fix will have to be added as another patch (ugly and potentially breaking git-bisect).
I'm not sure what happens (how git handles it) if patches are applied in different orders. What I'm thinking about is if custodians #1 and #2 both issue a pull request. Wolfgang pulls #1 and then #2. What happens to #2 when he does a merge with the master u-boot.git? Does git insert custodian #1 patches ahead of his existing (#2) patches, or do the patches end up in a different order in the repos?
Then there is the merge conflict, which will be a result of the order that Wolfgang pulls from the custodian repos. How does a custodian resolve a merge conflict without changing his branch's history?
In my mind, custodian repos should be (must be?) faithful slaves of the master u-boot.git repo - always the current u-boot.git + "value added" (to the best of the custodian's ability to keep up with Wolfgang ;-). The custodian always keeps the "value added" patches at the tip of the tree so that they are clearly identified.
Third party developers can clone u-boot.git, create a branch and pull the custodian's "value added" branch (master or otherwise), and merge or cherry-pick the "value added" patches. While we have not poked into the dark corners of this technique, Kim, Kumar, myself, and Wolfgang (unwittingly for Wolfgang) have done this and it has Just Worked[tm].
-------
FWIIW, my repo seems to have worked fine in this merge window. I actually have two u-boot-fdt repos: a "mirror" copy I synchronize against git://www.denx.de/git/u-boot-fdt.git nightly and a working repo (with local branches). This allows me to watch what is officially advertised, allows me to recover if I shit my working repo.
1) I rebased my working repo against u-boot.git, pushed my "master" branch to denx.de, then issued a pull request. * My "to pull" patches were at the tip of the tree
2) Wolfgang pulled my changes into u-boot.git
3) I did the rebase of my working repo using a "uboot" branch to pull the lastest u-boot.git changes and then rebasing my working repo's "mster" branch. I did that just now, so it has all of everybody's changes.
4) I pushed my working repo's master branch back to denx.de - my custodian repo now matches the master u-boot.git repo (not verified bit-for-bit, but it appears to be done right).
5) I pulled git://www.denx.de/git/u-boot-fdt.git into my "mirror" copy.
All of this Just Worked[tm] with no errors. While it could be argued that I rewrote history with my rebasing, I believe this is a good thing - all of our repos should match (at least on the master branches) and IMHO all of our histories should match at the point that the merge window closes. Emperically, git handled this "history rewriting" with no (apparent) errors.
-------
I've added a link "Intro to Distributed Version Control (Illustrated)" to the Custodian page: http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/
This is somewhat helpful, but doesn't talk about what happens to the custodian repositories after the patches are pulled into the master repository.
Best regards, gvb (going home to soak my brain in ethanol)
In message 4796726E.9030501@ge.com you wrote:
- Master branch is for others to actively base from
others = mostly users aka non-developers
- Master branch is updated just before a pull request
not necessarily only then, but updates should contain code that is considered to be "good" from the custodian's point of view
- No merge conflicts with the u-boot.git repo when Wolfgang pulls it
Ideally, yes.
These appear to be contradictory goals. #1 and #2 could be argued to not be contradictory, but I'm not buying into that theory. The point of people pulling and testing is to find problem, which should be fixed *before* a pull request. If the master branch has broken code in it,
Agreed. Please see previous messages. My idea is that the maste rbranch can be consider as kind of a "stable" branch - it is ahead compared to the main repo in regards to the the custodian's special topic, but considered stable. For testing, other branches should be used (probably with an explicit "-testing" in their name).
I'm not sure what happens (how git handles it) if patches are applied in different orders. What I'm thinking about is if custodians #1 and #2
git has no notation of order or sequence. It is storing content only. If you apply N independent, non-overlapping patches in arbitray order, the result will be the same. The individual commits will have different ID's, but who cares?
both issue a pull request. Wolfgang pulls #1 and then #2. What happens to #2 when he does a merge with the master u-boot.git? Does git insert custodian #1 patches ahead of his existing (#2) patches, or do the patches end up in a different order in the repos?
It doesn't matter as long as there are no conflicts.
Then there is the merge conflict, which will be a result of the order that Wolfgang pulls from the custodian repos. How does a custodian resolve a merge conflict without changing his branch's history?
That's a good point. I have to think about that one...
(going home to soak my brain in ethanol)
The brain or the liver?
Best regards,
Wolfgang Denk
Wolfgang Denk wrote:
In message 4796726E.9030501@ge.com you wrote:
[snip]
I'm not sure what happens (how git handles it) if patches are applied in different orders. What I'm thinking about is if custodians #1 and #2
git has no notation of order or sequence. It is storing content only. If you apply N independent, non-overlapping patches in arbitray order, the result will be the same. The individual commits will have different ID's, but who cares?
both issue a pull request. Wolfgang pulls #1 and then #2. What happens to #2 when he does a merge with the master u-boot.git? Does git insert custodian #1 patches ahead of his existing (#2) patches, or do the patches end up in a different order in the repos?
It doesn't matter as long as there are no conflicts.
I haven't played with git to see what it does with patches in different orders, but I'm not happy if my history doesn't match your history, it makes it tremendously harder to do comparisons of a custodian vs. the master repo. If the two are the same, not a big deal. If I need to figure out why they are different... OUCH.
Then there is the merge conflict, which will be a result of the order that Wolfgang pulls from the custodian repos. How does a custodian resolve a merge conflict without changing his branch's history?
That's a good point. I have to think about that one...
OK, I probably should confess that that was mostly a strawman.
(going home to soak my brain in ethanol)
The brain or the liver?
The brain, the liver is unfortunate collateral damage. Wish I could change history on that! ;-)
Best regards,
Wolfgang Denk
Best regards, gvb
u-boot-users-bounces@lists.sourceforge.net wrote on :
I'm not sure what happens (how git handles it) if patches are applied in different orders. What I'm thinking about is if custodians #1 and #2
git has no notation of order or sequence. It is storing content only. If you apply N independent, non-overlapping patches in arbitray order, the result will be the same. The individual commits will have different ID's, but who cares?
Huh? Normally the commit IDs are the most important thing I care about when working with other git repositories. If I try to compare my git repositroy with another one (mostly the u-boot master branch at denx) then the commit ID is the only way (I know) to make sure that my respository contains the exactly same patches than the other repository. If the topmost patch (or any other) in my respository has the same commit ID as a patch in the other repository i know for sure, that my and the other repository are exactly the same (from the beginnig till the compared patch). If the commit IDs in my repository have no correspondent in the other repository (because the order of the patches is different), I know nothing. Even if I find a patch with the same commit message, I don't know for sure if the patches are the same. Maybe in the other repository is the original patch and in my repository is an updated version (with the same commit message). I don't know.
As far as I understand the git philosophy, using SHA1 signatures as commit IDs was one of the most important things on git. IMO the goal behind that was to be able to refere to one particular state in a git repository by one single commit ID. If I have two git repositories with de facto the same content, but with different commit IDs, what's the worth of the SHA1 commit ID?
I often use for example the (partial) commit ID in the U-Boot boot message to identify from wich particular source state a U-Boot was built. This only works, if the order of patches is the same in all git repositories resulting in the same commit IDs. Otherwise I need to know from wich git repository the U-Boot was built, to identify the source state it was built from. And then I can't compare this repository to another (e. g. the denx master), because the same patches could have different commit IDs.
I tried this already some time ago (merging my u-boot-tq-group master branch, instead of rebasing) and get totally lost in a screwed up history. But maybe I did something wrong.
Best Regards, Martin Krause
In message 47F3F98010FF784EBEE6526EAAB078D10635DDB0@tq-mailsrv.tq-net.de you wrote:
Huh? Normally the commit IDs are the most important thing I care about when working with other git repositories. If I try to compare my git repositroy with another one (mostly the u-boot master branch at denx) then the commit ID is the only way (I know) to make sure that my respository contains the exactly same patches than the other repository. If the topmost patch (or any other) in my respository has
But this does not work.
Assume you and me start with absolutely identical copies of the same git repository - say we copied a disk.
Now we both check in the very same patch from the mailing list using for example git-am. You will see that we get two different commit IDs.
Even if you try to do this twice to identical copies of the git repo you will get different IDs:
-> rm -fr foo -> tar zxf foo.tgz ; cd foo ; echo x >xxx ; git-add xxx; git-commit -m test Created commit 8c934ae: test 1 files changed, 1 insertions(+), 1 deletions(-) -> cd .. -> rm -fr foo -> tar zxf foo.tgz ; cd foo ; echo x >xxx ; git-add xxx; git-commit -m test Created commit b5ae18e: test 1 files changed, 1 insertions(+), 1 deletions(-) -> cd .. -> rm -fr foo -> tar zxf foo.tgz ; cd foo ; echo x >xxx ; git-add xxx; git-commit -m test Created commit 56eb723: test 1 files changed, 1 insertions(+), 1 deletions(-)
You see? Three identical commits, three different commit IDs.
As far as I understand the git philosophy, using SHA1 signatures as commit IDs was one of the most important things on git. IMO the goal
Yes, of course. And the SHA1's of the *objects* are of course the same. But the commit IDs may be different - they include for example the commiter's name and time etc., so they will be different even when you do the very same action again in the very same copy of a repository. See above.
Note that git is tracking content, not history.
behind that was to be able to refere to one particular state in a git repository by one single commit ID. If I have two git repositories with de facto the same content, but with different commit IDs, what's the worth of the SHA1 commit ID?
You can still compare the commits. Just not the commit IDs.
I often use for example the (partial) commit ID in the U-Boot boot message to identify from wich particular source state a U-Boot was
This is OK, as long as you are referring to some repository for which you have a guarantee that the history will not be rewritten.
built. This only works, if the order of patches is the same in all git repositories resulting in the same commit IDs. Otherwise I need
No, this has nothing to do with that.
to know from wich git repository the U-Boot was built, to identify
Yes, of course you need to know that. As soon as you are working n your own tree it may have commits that are present nowhere else. Only as long as you are referring to a known common history you can make references to another repo.
the source state it was built from. And then I can't compare this repository to another (e. g. the denx master), because the same patches could have different commit IDs.
But they will result in the very same content (objcts in the git repo), and git is tracking the content, not the commit ID.
I tried this already some time ago (merging my u-boot-tq-group master branch, instead of rebasing) and get totally lost in a screwed up history. But maybe I did something wrong.
Most probably (or this was with older versions of the tools - as mentioned before, I screwed up more than one repo before ;-)
Best regards,
Wolfgang Denk
wd@denx.de wrote on Wednesday, January 23, 2008 1:48 PM:
In message 47F3F98010FF784EBEE6526EAAB078D10635DDB0@tq-mailsrv.tq-net.de you wrote:
Huh? Normally the commit IDs are the most important thing I care about when working with other git repositories. If I try to compare my git repositroy with another one (mostly the u-boot master branch at denx) then the commit ID is the only way (I know) to make sure that my respository contains the exactly same patches than the other repository. If the topmost patch (or any other) in my respository has
But this does not work.
Assume you and me start with absolutely identical copies of the same git repository - say we copied a disk.
Now we both check in the very same patch from the mailing list using for example git-am. You will see that we get two different commit IDs.
Agreed
Even if you try to do this twice to identical copies of the git repo you will get different IDs:
Agreed
You see? Three identical commits, three different commit IDs.
But if I rebase my repository with yours, my patch will go away (or at least stay on top of my repository as an empty commit, I'm not sure about that) and our repositories are identical again (= identical history). But if I merge my repository with yours they are not identical afterwards. Content yes, history no. And worse, I have no chance to ever get history identical again (without rebasing).
As far as I understand the git philosophy, using SHA1 signatures as commit IDs was one of the most important things on git. IMO the goal
Yes, of course. And the SHA1's of the *objects* are of course the same. But the commit IDs may be different - they include for example the commiter's name and time etc., so they will be different even when you do the very same action again in the very same copy of a repository. See above.
Note that git is tracking content, not history.
As far as I know every commit has an parent. And this parent (its ID) is part of the commit. So history is been tracked as a list of successive commits. Another order of the commits leads to another history and to another commit IDs.
Excerpt from the git README:
Furthermore, since the SHA1 signature of a commit refers to the SHA1 signatures of the tree it is associated with and the signatures of the parent, a single named commit specifies uniquely a whole set of history, with full contents. You can't later fake any step of the way once you have the name of a commit.
behind that was to be able to refere to one particular state in a git repository by one single commit ID. If I have two git repositories with de facto the same content, but with different commit IDs, what's the worth of the SHA1 commit ID?
You can still compare the commits. Just not the commit IDs.
How can I do that?
I often use for example the (partial) commit ID in the U-Boot boot message to identify from wich particular source state a U-Boot was
This is OK, as long as you are referring to some repository for which you have a guarantee that the history will not be rewritten.
No, it does not matter, if the history was rewritten. If I find a repository which contains this commit ID, I can be sure that I could restore the exact soucre code the U-Boot was built from (this does not work for sure, because the commit ID in the U-Boot boot message is only a partial commit ID, but it will work if I would have the complete commit ID). The chance, that a repository with a rewritten history will contain this commit ID is lower, admitted.
built. This only works, if the order of patches is the same in all git repositories resulting in the same commit IDs. Otherwise I need
No, this has nothing to do with that.
to know from wich git repository the U-Boot was built, to identify
Yes, of course you need to know that. As soon as you are working n your own tree it may have commits that are present nowhere else. Only as long as you are referring to a known common history you can make references to another repo.
If I rebase my tree with the public tree my commits will always stay on top of the "known common history". The differences between my and the public repository are easily recognizeable (e. g. with qgit). If I merge my tree with the public tree I get a mixture of history. I don't know a way, how I could get the differences then (but this does not necceseraly mean, that there is no way).
the source state it was built from. And then I can't compare this repository to another (e. g. the denx master), because the same patches could have different commit IDs.
But they will result in the very same content (objcts in the git repo), and git is tracking the content, not the commit ID.
I disagree, see above.
I tried this already some time ago (merging my u-boot-tq-group master branch, instead of rebasing) and get totally lost in a screwed up history. But maybe I did something wrong.
Most probably (or this was with older versions of the tools - as mentioned before, I screwed up more than one repo before ;-)
I'm using git 1.5.3.rc6.
Best regards, Martin Krause
On Wed, 23 Jan 2008 18:27:11 +0100 "Martin Krause" Martin.Krause@tqs.de wrote:
behind that was to be able to refere to one particular state in a git repository by one single commit ID. If I have two git repositories with de facto the same content, but with different commit IDs, what's the worth of the SHA1 commit ID?
You can still compare the commits. Just not the commit IDs.
How can I do that?
Use the SHA1 of the top-level tree instead of the commit. Or just use git diff.
Haavard
On Tue, 22 Jan 2008 15:03:45 +0100 Wolfgang Denk wd@denx.de wrote:
As explained before, my idea is that the custodians will merge their code into the master branch (a) for others to test it and (b) for me to pull from.
And as I've tried to explain, I think those two purposes are conflicting since having a single branch for everything means either (a) only code that has already been tested goes into the master branch, or (b) you get to pull untested code.
Haavard
Jerry Van Baren wrote:
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:
- Wolfgang wishes to pull from the subrepo "master" branch
- 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.
Adding to this thought, rebasing a custodian repo rewrites its history *to match the master u-boot.git repo* (and then add to it). Based on my limited knowledge and experience, I think that is a *good* thing.
If we don't "rewrite" our custodian histories to match the master u-boot.git repo history, very quickly it will be impossible to compare the custodian repo to the master because the patches will be in different order.
We are your slaves, gvb
participants (8)
-
gvb.uboot -
Haavard Skinnemoen -
Jerry Van Baren -
Joakim Tjernlund -
Markus Klotzbücher -
Martin Krause -
Mike Frysinger -
Wolfgang Denk