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>
