diff --git a/rev_news/drafts/edition-107.md b/rev_news/drafts/edition-107.md index 1e2e5617c..d6348a40b 100644 --- a/rev_news/drafts/edition-107.md +++ b/rev_news/drafts/edition-107.md @@ -33,7 +33,7 @@ This edition covers what happened during the months of December 2023 and January [`git bugreport`](https://git-scm.com/docs/git-bugreport), so his message looks like a filled out form with questions and answers. - He was trying to cherry-pick changes from one repo A to another B, + He was trying to cherry-pick changes from one repo (A) to another (B), while both A and B came from the same original TFS server but with different set of changes. He was disappointed though because some files that had been moved in repo A were matched up by the rename @@ -44,19 +44,19 @@ This edition covers what happened during the months of December 2023 and January While not obvious at first, Jeremy's primary problem specifically centered around cases where there were multiple files with 100% - identical content. Perhaps an example would help. There could have - originally been an `orig/foo.txt` file, while one side of history - does not have that file anymore but instead has both a - `dir2/foo.txt` and a `dir3/foo.txt`; further, both of the new - foo.txt files are identical to the original `orig/foo.txt`. So, Git - has to figure out which foo.txt file the `orig/foo.txt` was renamed - to, whether to `dir2/foo.txt` or `dir3/foo.txt`. + identical content. For example, originally there could have + been an `orig/foo.txt` file, while one of the descendant repos + does not have that file anymore but instead has two files, + `dir2/foo.txt` and `dir3/foo.txt`, both with contents identical + to the original `orig/foo.txt`. So, Git has to figure out which + one of `dir2/foo.txt` and `dir3/foo.txt` is the result of renaming + `orig/foo.txt`. Elijah replied to Jeremy explaining extensively how rename detection works in Git. Elijah pointed out that Jeremy's problem, as described, did not involve directory rename detection (despite looking kind of like a directory rename detection problem). Also, - since Jeremy pointed out that the contents of the "mis-detected" + since Jeremy pointed out that the contents of the "misdetected" renames had identical contents to what they were paired with, that meant that only exact renames were involved. Because of these two factors, Elijah said that the new 'ort' merge strategy, which he @@ -94,7 +94,7 @@ This edition covers what happened during the months of December 2023 and January The thread also involved additional explanations about various facts involving rename detection. This included details about how renames - are just a help for developers as they are not recorded, but are + are just a hint for developers as they are not recorded, but are instead computed from scratch in response to user commands. It also included details about what things like "added by both" means (namely that both sides added the same filename but with different @@ -120,28 +120,27 @@ This edition covers what happened during the months of December 2023 and January the commit to "library-x-1.8/" and changes from other files in the commit to "library-x-1.9/". Elijah explained why this happens and suggested a hack for users dealing with this particular kind of case - to workaround rename detection. + to work around rename detection. Philip Oakley then chimed into the discussion to suggest using "BLOBSAME" for exact renames in the same way as "TREESAME" is used in `git log` for history simplification. Elijah replied to Philip that he thinks that 'exact rename' already works. Junio C Hamano, - the Git maintainer, then chimed into the discussion saying that - "TREESAME" is a property of commits, not trees. So he suggested - using different words than "BLOBSAME" and "TREESAME" in the context - of rename detection. + the Git maintainer, then pointed out that "TREESAME" is a property + of commits, not trees, and suggested using words other than + "BLOBSAME" and "TREESAME" in the context of rename detection. Philip and Elijah discussed terminology at more length, agreeing that good terminology can sometimes help people coming from an "old centralised VCS" make the mind shift to understand Git's model, but - didn't find anything that would help in this case though. + didn't find anything that would help in this case. Finally, Philip requested more information about how Git computes file content similarity (for inexact rename detection), referencing Elijah's mention of "spanhash representation". Elijah explained the internal data structure in detail, and supported his earlier claim - that "comparison of filenames can rival cost of file content - similarity". + that "comparison of filenames can rival the cost of file content + similarity computations".