Suggestion to enable git rerere by default

[Nicolas Richard <youngfrog@members.fsf.org>]

Aurélien Aptel <aurelien.aptel+emacs@gmail.com> writes:

> On Sun, Nov 8, 2015 at 9:38 PM, Ted Zlatanov <tzz@lifelogs.com> wrote:
>>>> Agreed. Aurélien, the diff is huge and there are many conflicts. It
>>>> looks like the fork from master happened in February 2015 and you're
>>>> simply out of date. Can you please rebase against the emacs.git
>>>> origin/master?  Last push...
>
> I already merged master in my branch at some point, and did so with
> `merge --squash` IIRC, note to self: never do that again.

I agree with that conclusion. However I want to mention...

> made any subsequent master merge a lot harder, sorry for that. The
> weird thing is most conflicting changes where actually identical but
> git couldn't tell. The diff were the same on both side but git couldnt
> tell they were from the same commits since they were squashed.

...did you enable git rerere ? (you can check with: git config --get
rerere.enabled). If not, I suggest that you do it:
    git config --global rerere.enabled 1

I'm not 100% sure that would have helped in your usecase, but it's
useful anyway. Excerpt from `git help rerere' :
       In a workflow employing relatively long lived topic branches, the
       developer sometimes needs to resolve the same conflicts over and
       over again until the topic branches are done (either merged to
       the "release" branch, or sent out and accepted upstream).

       This command assists the developer in this process by recording
       conflicted automerge results and corresponding hand resolve
       results on the initial manual merge, and applying previously
       recorded hand resolutions to their corresponding automerge
       results.


Perhaps we could add that as a suggestion in admin/notes/git-workflow :

modified   admin/notes/git-workflow
@@ -124,6 +124,11 @@ the resulting merge, but if you really want to, feel free to do that.
 Note you can also resume gitmerge in a new Emacs session, since the
 current state will be saved to disk.
 
+The following is helpful if you're going to merge the same set of
+changes multiple times :
+
+  git config --global rerere.enabled 1
+
 When everything's done, look hard at the resulting merge.  Skipping
 commits requires separate merges, so don't be surprised to see more
 than one merge commit.  If you're happy, push.
 



-- 
Nicolas Richard