[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Suggestion to enable git rerere by default
From: |
Nicolas Richard |
Subject: |
Suggestion to enable git rerere by default |
Date: |
Tue, 10 Nov 2015 10:35:29 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) |
Aurélien Aptel <address@hidden> writes:
> On Sun, Nov 8, 2015 at 9:38 PM, Ted Zlatanov <address@hidden> 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
- Re: Dynamic loading progress, (continued)
- Re: Dynamic loading progress, Ted Zlatanov, 2015/11/09
- Re: Dynamic loading progress, Aurélien Aptel, 2015/11/09
- Re: Dynamic loading progress, Steinar Bang, 2015/11/09
- Re: Dynamic loading progress, Steinar Bang, 2015/11/09
- Re: Dynamic loading progress, Aurélien Aptel, 2015/11/09
- Re: Dynamic loading progress, Aurélien Aptel, 2015/11/09
- Re: Dynamic loading progress, Aurélien Aptel, 2015/11/09
- Re: Dynamic loading progress, Ted Zlatanov, 2015/11/09
- Re: Dynamic loading progress, Philipp Stephani, 2015/11/09
- Re: Dynamic loading progress, Steinar Bang, 2015/11/09
- Suggestion to enable git rerere by default,
Nicolas Richard <=
- Re: Suggestion to enable git rerere by default, Artur Malabarba, 2015/11/10
- Re: Suggestion to enable git rerere by default, Nicolas Richard, 2015/11/10
- Re: Dynamic loading progress, John Wiegley, 2015/11/09
- Re: Dynamic loading progress, Ted Zlatanov, 2015/11/09
Re: Dynamic loading progress, Philipp Stephani, 2015/11/08