Re: git, rebase, and ChangeLog

[Jim Meyering]

Bruno Haible wrote:

> 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.

Hi Bruno,

I use nearly the same process, except I rarely use stash.
Instead, I create a topic branch for the changes you would stash,
using a command like this:

  git checkout -b $(date +%Y-%j)-some-descriptive-branch-name

and then I commit the changes on that branch.
(I use vc-dwim almost exclusively to perform the actual commit,
since it automatically uses the ChangeLog entry to select which
files to commit, and also, e.g., warns me if there's a temp.
file implying an unsaved editor buffer)

When returning to work on that branch, the first step
is usually "git rebase master" to bring it up to date
with the latest on master.

The $(date ...) branch name prefix is to give me something
by which to sort/filter these branches by age.

Of course, I never type that long git checkout command,
but rather get it via 4 or 5 keystrokes (C-r co -b) from shell history
and then add the name suffix.  With shell ("g") and git aliases ("co"),
this is what history search usually dredges up:

  g co -b $(date +%Y-%j)-xxx