
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