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

Re: [WIP PATCH] Manual rename correction

From
Junio C Hamano <gitster@pobox.com>
Date
Jul 31, 2012, 16:32 UTC
Message-ID
<7vtxwnki1a.fsf@alter.siamese.dyndns.org>
In-Reply-To
<20120731141536.GA26283@do>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
Show 9 quoted lines
> The above output is done with "git diff --manual-rename=foo A B"
> and "foo" contains (probably not in the best format though)
>
> -- 8< --
> attr.c dir.c
> dir.c attr.c
> -- 8< --
> ...
> Comments?

It is a good direction to go in, I would think, to give users a way to explicitly tell that "in comparison between these two trees, I know path B in the postimage corresponds to path A in the preimage".

I however wonder why you did this as a separate function that only does the explicitly marked ones. Probably it was easier as a POC to do it this way, and that is fine.

The real version should do this in the same diffcore_rename() function, by excluding the paths that the user explicitly told you about from the the automatic matching logic, and instead matching them up manually; then you can let the remainder of the paths be paired by the existing code.

Notice how the non-nullness of rename_dst[i].pair is used as a cue to skip the similarity computation in the expensive matrix part of diffcore_rename()? That comes from find_exact_renames() that is called earlier in the function. I would imagine that your logic would fit _before_ we call find_exact_renames() as a call to a new helper function (e.g. "record_explicit_renames()" perhaps). Anything that reduces the cost in the matrix part should come earlier, as that reduces the number of pairs we would need to try matching up.

We might want to introduce a way to express the similarity score for such a filepair that was manually constructed when showing the result, though.

Previous: Nguyen Thai Ngoc DuyNext: Jeff King
Message 2 of 35 in “Manual rename correction”
  1. Manual rename correctionNguyen Thai Ngoc Duy, Jul 31, 2012
  2. Junio C HamanoJul 31, 2012
  3. Jeff KingJul 31, 2012
  4. Junio C HamanoJul 31, 2012
  5. Jeff KingAug 1, 2012
  6. Junio C HamanoAug 1, 2012
  7. Jeff KingAug 1, 2012
  8. Junio C HamanoAug 1, 2012
  9. Jeff KingAug 2, 2012
  10. Junio C HamanoAug 2, 2012
  11. Jeff KingAug 2, 2012
  12. Junio C HamanoAug 2, 2012
  13. Nguyen Thai Ngoc DuyAug 1, 2012
  14. Jeff KingAug 1, 2012
  15. Nguyen Thai Ngoc DuyAug 1, 2012
  16. Junio C HamanoAug 1, 2012
  17. Nguyen Thai Ngoc DuyAug 1, 2012
  18. Jeff KingAug 1, 2012
  19. Jeff KingAug 1, 2012
  20. Nguyen Thai Ngoc DuyAug 2, 2012
  21. Jeff KingAug 2, 2012
  22. 0/8 caching rename resultsJeff King, Aug 4, 2012
  23. 1/8 implement generic key/value mapJeff King, Aug 4, 2012
  24. Junio C HamanoAug 4, 2012
  25. Jeff KingAug 6, 2012
  26. 2/8 map: add helper functions for objects as keysJeff King, Aug 4, 2012
  27. 3/8 fast-export: use object to uint32 map instead of "decorate"Jeff King, Aug 4, 2012
  28. 4/8 decorate: use "map" for the underlying implementationJeff King, Aug 4, 2012
  29. 5/8 map: implement persistent mapsJeff King, Aug 4, 2012
  30. 6/8 implement metadata cache subsystemJeff King, Aug 4, 2012
  31. Junio C HamanoAug 4, 2012
  32. Jeff KingAug 6, 2012
  33. Jeff KingAug 6, 2012
  34. 7/8 implement rename cacheJeff King, Aug 4, 2012
  35. 8/8 diff: optionally use rename cacheJeff King, Aug 4, 2012

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.