RelNotes: remove duplicate release note
In the 2.18 cycle, directory rename detection was merged, then reverted, then reworked in such a way to fix another prominent bug in addition to the original problem causing it to be reverted. When the reworked series was merged, we ended up with two nearly duplicate release notes. Remove the second copy, but preserve the information about the extra bug fix. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Elijah Newren committed
May 30, 2018 at 20:24 UTC
2161ed80980dc774521b963d8b4b18f746124283
1 file changed
+3
-11
Documentation/RelNotes/2.18.0.txt
+3
-11
@@ -12,7 +12,9 @@ UI, Workflows & Features
12
want to move to z/d by taking the hint that the entire directory
13
'x' moved to 'z'. A bug causing dirty files involved in a rename
14
to be overwritten during merge has also been fixed as part of this
15
- work.
15
+ work. Incidentally, this also avoids updating a file in the
16
+ working tree after a (non-trivial) merge whose result matches what
17
+ our side originally had.
18
19
* "git filter-branch" learned to use a different exit code to allow
20
the callers to tell the case where there was no new commits to
@@ -256,16 +258,6 @@ Performance, Internal Implementation, Development Support etc.
258
repository object (which in turn tells the API which object store
259
the objects are to be located).
260
259
- * Rename detection logic in "diff" family that is used in "merge" has
260
- learned to guess when all of x/a, x/b and x/c have moved to z/a,
261
- z/b and z/c, it is likely that x/d added in the meantime would also
262
- want to move to z/d by taking the hint that the entire directory
263
- 'x' moved to 'z'. A bug causing dirty files involved in a rename
264
- to be overwritten during merge has also been fixed as part of this
265
- work. Incidentally, this also avoids updating a file in the
266
- working tree after a (non-trivial) merge whose result matches what
267
- our side originally had.
268
-
261
* "git pack-objects" needs to allocate tons of "struct object_entry"
262
while doing its work, and shrinking its size helps the performance
263
quite a bit.