[U-Boot-Users] Revised custodian git writeup

[Haavard Skinnemoen <hskinnemoen@atmel.com>]

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