git: avoiding merges, rebasing

[Bruno Haible]

Hi Jim,

A git question:

In http://lists.gnu.org/archive/html/bug-gnulib/2007-09/msg00130.html
you wrote:
> When one branch (your topic branch) is private, you *can* rebase, and thus
> avoid the merge.
> ...
> That's the whole point of rebasing.
> rebasing is essentially adjusting your deltas so that they apply
> with no fuzz, and no conflicts, to the latest version of the
> parent branch.

It seems that when I do that, I have to do each conflict resolution twice.
Not sure I'm doing everything right.

Here's what I did:
  - Created some modifications to the ChangeLog and other files.
  - Did "git pull". It told me:
    fatal: Entry 'ChangeLog' not uptodate. Cannot merge.
  - I figured that git refuses to do a conflicting merge on modifications
    that are not in the "index". Right?
  - So I did "git-add ChangeLog" and "git pull" again. This time it told me:
    fatal: Entry 'ChangeLog' would be overwritten by merge. Cannot merge.
  - Then I did "git merge 61135ee", but it failed with the same message:
    fatal: Entry 'ChangeLog' would be overwritten by merge. Cannot merge.
  - So I did "git-commit ChangeLog" and "git pull" again. This time it was
    better:
    Auto-merged ChangeLog
    CONFLICT (content): Merge conflict in ChangeLog
    Automatic merge failed; fix conflicts and then commit the result.
  - So I edited the ChangeLog to get rid of the <<< and >>> markers, and did
    "git-commit -i ChangeLog".
  - Now "git pull" tells me:
    Already up-to-date.

But now gitk shows that I have a merge here (see screenshot).

  - So I did "git rebase remotes/origin/master". It tells me:
    Auto-merged ChangeLog
    CONFLICT (content): Merge conflict in ChangeLog
  - So I edited the ChangeLog to get rid of the <<< and >>> markers again,
    then "git rebase --continue".
  - Then finally gitk shows a linear sequence of commits.

But I had to resolve the conflicts twice, which is inefficient. Any hint
how to avoid that?

Bruno