Re: Multi-commit feature sequences...

[David Kastrup]

Graham Percival <address@hidden> writes:

> On Thu, Sep 08, 2011 at 04:12:04PM +0200, David Kastrup wrote:
>> 
>> Well, I tried pushing a multi-commit change as a single merge commit
>> right now.
>
> Thanks for the experiment!  This is useful information for a
> long-away GOP proposal
> http://lilypond.org/~graham/gop/gop_19.html
> (currently "GOP h - separate branches for active development", but
> the url will change if I schedule it earlier)
>
> That said, I'm not completely clear on the difference between
> merging a branch, pulling from a branch, and this "multi-commit
> change" thing.

All the same.

> Well, as long as one git person can give us a reliable series of
> commands to do this, I think it's worth considering -- at least for
> large changes like beam collisions, or even "medium" changes like flag
> styles.

It's more or less, when working in a feature-branch, assuming that
master has no commits of its own:

git fetch (origin is now up to date)
git rebase origin feature-branch (feature-branch is now based on origin)
git checkout master
git merge origin --ff-only (if this fails, stop here, something went awry)
(ok, now master should be up to date and corresponding with origin)
Up to now, that's standard workflow, maybe with a different choice of
commands, no idea.  Now:
git merge feature-branch -m "commit message" --no-ff

If you add the --log line to that last command, you get the first line
of each individual commit mentioned in the merge message.

So the last command really is all that is different, and the --no-ff
does all the difference, namely a true merge rather than just accepting
all the commits individually.

After that, git push should get your merge upstream.

-- 
David Kastrup