git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: re-running merge on a single file

From
Kris Shannon <kris@shannon.id.au>
Date
Mar 14, 2010, 12:24 UTC
Message-ID
<e51f4f551003140524r18546bd6i202f1b886de9d7a9@mail.gmail.com>
In-Reply-To
<a038bef51003121543t52a864ddlab345dd1bcf6c906@mail.gmail.com>
On 13 March 2010 10:43, Chris Packham <judge.packham@gmail.com> wrote:
Show 8 quoted lines
> On Fri, Mar 12, 2010 at 3:07 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>  (3) If you have rerere enabled, then the conflicts would be already
>>     resolved in your working tree at this point, but not in the index, so
>>     you can reproduce the conflicted state with "checkout -m".
>
> Mental note: Need to learn more about git rerere. Sounds like what I
> need to do the job.
>

There is a script in the contrib directory written by Nanako Shiraishi called rerere-train.sh which can be used to prime the rr-cache even if you didn't have rerere enabled before you orginally did the merge.

Previous: Chris PackhamNext: Jakub Narebski
Message 13 of 14 in “re-running merge on a single file”
  1. Chris PackhamMar 11, 2010
  2. Chris PackhamMar 11, 2010
  3. Markus HeidelbergMar 11, 2010
  4. Chris PackhamMar 11, 2010
  5. Jakub NarebskiMar 11, 2010
  6. Chris PackhamMar 12, 2010
  7. Johannes SixtMar 12, 2010
  8. Junio C HamanoMar 12, 2010
  9. Chris PackhamMar 12, 2010
  10. Chris PackhamMar 12, 2010
  11. Junio C HamanoMar 12, 2010
  12. Chris PackhamMar 12, 2010
  13. Kris ShannonMar 14, 2010
  14. Jakub NarebskiMar 12, 2010

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.