All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] RelNotes: remove duplicate release note
@ 2018-05-31  3:24 Elijah Newren
  2018-06-01  1:08 ` Junio C Hamano
  0 siblings, 1 reply; 2+ messages in thread
From: Elijah Newren @ 2018-05-31  3:24 UTC (permalink / raw)
  To: gitster; +Cc: git, Elijah Newren

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>
---
 Documentation/RelNotes/2.18.0.txt | 14 +++-----------
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/Documentation/RelNotes/2.18.0.txt b/Documentation/RelNotes/2.18.0.txt
index c9e2e19721..fd5aecf8e9 100644
--- a/Documentation/RelNotes/2.18.0.txt
+++ b/Documentation/RelNotes/2.18.0.txt
@@ -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
@@ -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.
-- 
2.18.0.rc0


^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [PATCH] RelNotes: remove duplicate release note
  2018-05-31  3:24 [PATCH] RelNotes: remove duplicate release note Elijah Newren
@ 2018-06-01  1:08 ` Junio C Hamano
  0 siblings, 0 replies; 2+ messages in thread
From: Junio C Hamano @ 2018-06-01  1:08 UTC (permalink / raw)
  To: Elijah Newren; +Cc: git

Elijah Newren <newren@gmail.com> writes:

> 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.

Thanks.

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2018-06-01  1:08 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-05-31  3:24 [PATCH] RelNotes: remove duplicate release note Elijah Newren
2018-06-01  1:08 ` Junio C Hamano

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.