Graham Percival <[email protected]> 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 _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
