Re: git, rebase, and ChangeLog

[Bruno Haible]

Hi Paul,

> > when you rebased your proposed commits, the ChangeLog entries did not go
> > in at the top. Are you using the 'git-merge-changelog' driver?
> 
> No, I used "git rebase -i", generated a revised patch, and then
> applied it with "git am".

Hmm, it may be that the merge driver would not used in this case anyway,
even if you had installed it. When I apply patches people have sent through
mail, I routinely have to take care about ChangeLog manually - either because
I get a reject, or because it applies a change at a position other than the
top.

For this reason I mostly avoid the use of 00*.diff files and "git am" inside
my workspace. My workflow looks mostly like this, when I'm ready to commit
something:

  - $ git pull --rebase
    or
    $ git stash
    $ git pull --rebase
    $ git stash pop
    The --rebase option is because I want my own commits to come after
    what's been committed in origin/master, and have a linear history.

  - Prepare ChangeLog entry, $ git commit ChangeLog file1 file2 ...

  - $ gitk
    Now if it's a single commit after origin/master, I can directly write
    the mail and then push.

    Otherwise, reorder the commit(s) to be pushed to be the first after
    origin/master.
      $ git stash
    Then
      $ git rebase -i origin/master
    Then push part of these commits:
      $ git checkout E             # where E is the identifier of the last 
commit to be pushed
      $ git push origin HEAD:master
      $ git checkout master
    The latter three commands can be dangerous if used alone, but are reliable
    in this sequence of commands. Finally
      $ git stash pop

But I do use the 00*.diff files and "git am" approach when the patches need
major rework, not just a bit of rebasing.

This is just a hint; I'll like to hear from Jim, Eric, Ralf, how they do it.

Bruno
-- 
In memoriam Ezechiele Ramin <http://en.wikipedia.org/wiki/Ezechiele_Ramin>