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