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