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