Re: [PATCH v3 02/13] Documentation/technical: describe remembering renames optimization
- From
Bagas Sanjaya <bagasdotme@gmail.com>
- Date
- May 20, 2021, 11:32 UTC
- Message-ID
- <ef450bbd-0cbb-a512-d88e-eca6638358aa@gmail.com>
- In-Reply-To
- <4246d0193fed5ff522fb2c442bd779973701c078.1621490982.git.gitgitgadget@gmail.com>
On 20/05/21 13.09, Elijah Newren via GitGitGadget wrote:
Show 27 quoted lines
> +Outline: > + > + 0. Assumptions > + > + 1. How rebasing and cherry-picking work > + > + 2. Why the renames on MERGE_SIDE1 in any given pick are *always* a > + superset of the renames on MERGE_SIDE1 for the next pick. > + > + 3. Why any rename on MERGE_SIDE1 in any given pick is _almost_ always also > + a rename on MERGE_SIDE1 for the next pick > + > + 4. A detailed description of the the counter-examples to #3. > + > + 5. Why the special cases in #4 are still fully reasonable to use to pair > + up files for three-way content merging in the merge machinery, and why > + they do not affect the correctness of the merge. > + > + 6. Interaction with skipping of "irrelevant" renames > + > + 7. Additional items that need to be cached > + > + 8. How directory rename detection interacts with the above and why this > + optimization is still safe even if merge.directoryRenames is set to > + "true". > + > +
For item 1, 2, 3, 5, 8, it seems that you form question sentences but ended with dot, instead of question mark (?). Are these question sentences or descriptive sentences?
Show 9 quoted lines
> +=== 0. Assumptions === > + > +There are two assumptions that will hold throughout this document: > + > + * The upstream side where commits are transplanted to is treated as the > + first parent side when rebase/cherry-pick call the merge machinery > + > + * All merges are fully automatic > +
Did you mean that "fully automatic" merges are merges that can be done without conflicts?
-- An old man doll... just what I always wanted! - Clara