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
<<inline: gitk-merge.png>>
