Skip to content

Commit

Permalink
RelNotes: remove duplicate release note
Browse files Browse the repository at this point in the history
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>
  • Loading branch information
newren authored and gitster committed Jun 1, 2018
1 parent 12039e0 commit 2161ed8
Showing 1 changed file with 3 additions and 11 deletions.
14 changes: 3 additions & 11 deletions Documentation/RelNotes/2.18.0.txt
Original file line number Diff line number Diff line change
Expand Up @@ -12,7 +12,9 @@ UI, Workflows & Features
want to move to z/d by taking the hint that the entire directory
'x' moved to 'z'. A bug causing dirty files involved in a rename
to be overwritten during merge has also been fixed as part of this
work.
work. Incidentally, this also avoids updating a file in the
working tree after a (non-trivial) merge whose result matches what
our side originally had.

* "git filter-branch" learned to use a different exit code to allow
the callers to tell the case where there was no new commits to
Expand Down Expand Up @@ -256,16 +258,6 @@ Performance, Internal Implementation, Development Support etc.
repository object (which in turn tells the API which object store
the objects are to be located).

* Rename detection logic in "diff" family that is used in "merge" has
learned to guess when all of x/a, x/b and x/c have moved to z/a,
z/b and z/c, it is likely that x/d added in the meantime would also
want to move to z/d by taking the hint that the entire directory
'x' moved to 'z'. A bug causing dirty files involved in a rename
to be overwritten during merge has also been fixed as part of this
work. Incidentally, this also avoids updating a file in the
working tree after a (non-trivial) merge whose result matches what
our side originally had.

* "git pack-objects" needs to allocate tons of "struct object_entry"
while doing its work, and shrinking its size helps the performance
quite a bit.
Expand Down

0 comments on commit 2161ed8

Please sign in to comment.