Hi Charles, * Charles Wilson wrote on Sat, Aug 28, 2010 at 07:10:25AM CEST: > On 8/27/2010 3:47 PM, Ralf Wildenhues wrote: > > * Charles Wilson wrote on Fri, Aug 27, 2010 at 08:49:24PM CEST: > >> However, once I have finished the requested changes above and the > >> rebasing (plus whatever comes of the four open ***QQQ***uestions), I > >> might ask for a 12 hour halt on updates to master so I can run those > >> tests, if that's ok? > > > > Why should you need the halt? If there are new pushs in the meantime, > > you just merge origin/master into your master, and push. > > Doesn't that mess up the "linear" history of commits in the upstream > master?
Well, yes, if you want to call it "messing up", that is. From git's perspective, origin/master and master are not the same branch in your repository. Just that most of the time, you use fast-forward or rebase when getting the changes from the former into the latter. > After the push, we want master to look like this, right: > > + master (head): chuck's lastest commit > + the next most recent commit > + older commits > + ... Several projects seem to require it for some notion of cleanliness, but no, if there is a good reason against that, we don't necessarily want that. Your having tested a particular commit is such a good reason, IMVHO. > Not this: > + master (head): merge from chuck's local master > + more recent master commit > + some other master commit > +++ (chuck's local master): chuck's latest commit > + master commit just before chuck began his final testing > + older commits The text in the merge is slightly different: master: "merge origin/master" recent master commit .. chuck's latest commit master commit just before chuck began his final testing > Or am I confused about how git handles a merge on a single (tracking) > branch? No, you aren't. Just that I think that's a perfectly acceptable thing in this situation. Cheers, Ralf
