Re: documentation for committing with git

Magnus Hagander wrote:
>> Personally, I have a strong opinion that for everything but totally trivial
>> patches, the committer should create a short-lived work branch where all the
>> work is done, and then do a squash merge back to the main branch, which is
>> then pushed. This pattern is not mentioned at all. In my experience, it is
>> essential, especially if you're working on more than one thing at a time, as
>> many people often are.
>>     
>
> Uh, that's going to create an actual merge commit, no? Or you mean
> squash-merge-but-only-fast-forward?
>   

Yes, exactly that. Something like:
   git checkout -b myworkbranch   ... work, test, commit, rinse, lather repeat ...   git checkout RELn_m_STABLE   git
pull  git merge --squash myworkbranch   git push
 

> I *think* the docs is based off the pattern of the committer having
> two repositories - one for his own work, one for comitting, much like
> I assume all of us have today in cvs.
>
>   

So then what? After you've done your work you'll still need to pull the 
stuff somehow into your commit tree. I don't think this will buy you a 
lot. I usually clone the whole CVS tree for non-trivial work, but I'm 
not sure that's an ideal work pattern.

cheers

andrew