09db7 < -: -- Move git_sort(), a stable sort, into into
> libgit.a
> -: -- > 1: 8a99008a64 Move git_sort(), a stable sort, into into
> libgit.a
This is where the current range-diff could be improved to shine
more. If it were allowed to compute a pairwise diff
With the en/merge-recursive-cleanup patches already having advanced to next,
the problem I discovered when rebasing Git for Windows' branch thicket
becomes quite relevant now: t3030.35 fails consistently in the MSVC build &
test (this part of the Azure Pipeline will be upstreamed later).
The solut
With the en/merge-recursive-cleanup patches already having advanced to next,
the problem I discovered when rebasing Git for Windows' branch thicket
becomes quite relevant now: t3030.35 fails consistently in the MSVC build &
test (this part of the Azure Pipeline will be upstreamed later).
The solut
On Tue, Aug 06, 2019 at 02:16:25PM -0700, Elijah Newren wrote:
> > > + test_i18ngrep ! CONFLICT out &&
> > > + test_i18ngrep ! BUG: err &&
> >
> > The BUG is gone. But should it not use i18ngrep? BUG() isn't localized.
>
> Technically, yes, you're right. However, this line
> > > +
> > > + test_i18ngrep ! CONFLICT out &&
> > > + test_i18ngrep ! BUG: err &&
> >
> > The BUG is gone. But should it not use i18ngrep? BUG() isn't localized.
>
> Technically, yes, you're right. However, this line's purpose isn't
> correctness of the test but documenta
On Tue, Aug 6, 2019 at 1:28 PM Emily Shaffer wrote:
>
> On Mon, Aug 05, 2019 at 03:33:50PM -0700, Elijah Newren wrote:
> > Ever since commit 8c8e5bd6eb33 ("merge-recursive: switch directory
> > rename detection default", 2019-04-05), the default handling with
> >
On Mon, Aug 05, 2019 at 03:33:50PM -0700, Elijah Newren wrote:
> Ever since commit 8c8e5bd6eb33 ("merge-recursive: switch directory
> rename detection default", 2019-04-05), the default handling with
> directory rename detection was to report a conflict and leave unstaged
>
Junio C Hamano writes:
> I do agree that it is sensible to avoid doing any funky thing during
> the virtual base merges, whose result is much less observable (hence
> harder to form the right mental model in end user's head) than the
> outermost merge. Do we want to allow this for inner merges w
directory renames" was introduced, while
> still allowing those who want to help can explore the right fix to
> this codepath.
That might be a bit more jarring. Directory rename detection did not
have this bug in git 2.18, 2.19, 2.20, or 2.21. It was new to 2.22
with the 'conflict' setting
On Tue, Aug 6, 2019 at 9:57 AM Junio C Hamano wrote:
>
> Elijah Newren writes:
>
> > Ever since commit 8c8e5bd6eb33 ("merge-recursive: switch directory
> > rename detection default", 2019-04-05), the default handling with
> > directory rename detection was to
Elijah Newren writes:
> I know this bug doesn't satisfy the normal criteria for making it into
> 2.23 (it's a bug that was present in 2.22 rather than a regression in
> 2.23), but given that it's a BUG() condition, I was hoping it is
> important and safe enough to include anyway.
For maintenance
Elijah Newren writes:
> Ever since commit 8c8e5bd6eb33 ("merge-recursive: switch directory
> rename detection default", 2019-04-05), the default handling with
> directory rename detection was to report a conflict and leave unstaged
> entries in the index. However, when cr
Ever since commit 8c8e5bd6eb33 ("merge-recursive: switch directory
rename detection default", 2019-04-05), the default handling with
directory rename detection was to report a conflict and leave unstaged
entries in the index. However, when creating a virtual merge base in
the recursiv
On 6/8/2019 10:42 AM, Johannes Schindelin via GitGitGadget wrote:
Just another patch from Git for Windows' branch thicket...
Jeff Hostetler (1):
diffcore-rename: speed up register_rename_src
diffcore-rename.c | 13 +
1 file changed, 13 insertions(+)
base-commit: 8104ec994
Just another patch from Git for Windows' branch thicket...
Jeff Hostetler (1):
diffcore-rename: speed up register_rename_src
diffcore-rename.c | 13 +
1 file changed, 13 insertions(+)
base-commit: 8104ec994ea3849a968b4667d072fedd1e688642
Published-As:
https://github.com/gitgitga
On Fri, Apr 5, 2019 at 8:03 AM Elijah Newren wrote:
>
> This series adds a new configuration option, merge.directoryRenames,
> for setting how to make use of directory rename detection heuristics.
> The default becomes "conflict", meaning that conflicts are reported
> i
This series adds a new configuration option, merge.directoryRenames,
for setting how to make use of directory rename detection heuristics.
The default becomes "conflict", meaning that conflicts are reported
instead of silently moving paths according to the heuristics. Also,
change of default problematic,
especially since there was no notice printed when directory rename
detection moved files.
Note that there is also a third possibility here:
C) There are different answers depending on the context and content
that cannot be determined by git, so this is a confli
On Sat, Mar 30, 2019 at 2:12 AM Ævar Arnfjörð Bjarmason
wrote:
> On Sat, Mar 30 2019, Elijah Newren wrote:
>
> I may have more, just quickly skimming this for the first time...
>
> > merge.renames::
> > - Whether and how Git detects renames. If set to "false&qu
On Sat, Mar 30 2019, Elijah Newren wrote:
I may have more, just quickly skimming this for the first time...
> merge.renames::
> - Whether and how Git detects renames. If set to "false",
> - rename detection is disabled. If set to "true", basic rename
change of default problematic,
especially since there was no notice printed when directory rename
detection moved files.
Note that there is also a third possibility here:
C) There are different answers depending on the context and content
that cannot be determined by git, so this is a confli
; instead of
vice-versa in patch 1?
* Similarly, does anyone have a reason to prefer oid,mode pair over
using a diff_filespec as I did in patch 11?
The crux of this series is in patch 15, changing the default for
directory rename detection to treat it as a conflict. It is similar
Elijah Newren writes:
> On Fri, Dec 7, 2018 at 9:51 AM Johannes Sixt wrote:
>>
>> From: Elijah Newren
>>
>> In commit 6aba117d5cf7 ("am: avoid directory rename detection when
>> calling recursive merge machinery", 2018-08-29), the git-rebase manpage
&
On Fri, Dec 7, 2018 at 9:51 AM Johannes Sixt wrote:
>
> From: Elijah Newren
>
> In commit 6aba117d5cf7 ("am: avoid directory rename detection when
> calling recursive merge machinery", 2018-08-29), the git-rebase manpage
> probably should have also been
From: Elijah Newren
In commit 6aba117d5cf7 ("am: avoid directory rename detection when
calling recursive merge machinery", 2018-08-29), the git-rebase manpage
probably should have also been updated to note the stronger
incompatibility between git-am and directory rename detection.
On Wed, Aug 29, 2018 at 5:54 AM Johannes Schindelin
wrote:
>
> Hi Elijah,
>
> On Wed, 29 Aug 2018, Elijah Newren wrote:
>
> > Signed-off-by: Elijah Newren
> > ---
> > merge-recursive.c | 18 +-
> > merge-recursive.h | 1 +
> > 2 files changed, 14 insertions(+), 5 deletions(-)
>
Hi Elijah,
On Wed, 29 Aug 2018, Elijah Newren wrote:
> Signed-off-by: Elijah Newren
> ---
> merge-recursive.c | 18 +-
> merge-recursive.h | 1 +
> 2 files changed, 14 insertions(+), 5 deletions(-)
>
> diff --git a/merge-recursive.c b/merge-recursive.c
> index f110e1c5ec..bf3c
e3}
>
> The core problem is that am does not have access to the original trees; it
> can only construct trees using the blobs involved in the patch. As such,
> it is not safe to perform directory rename detection within am -3.
I read through all three patches, and they look fine to me!
/, and master as just adding both foo/file1 and foo/file2. As
such, it ends up with goo/{file1, file2, file3}
The core problem is that am does not have access to the original trees; it
can only construct trees using the blobs involved in the patch. As such,
it is not safe to perform directory
On Tue, Aug 28, 2018 at 9:58 AM Junio C Hamano wrote:
> Elijah Newren writes:
>
> > - Add a flag to turn off directory rename detection, and set the
> > flag for every call from am.c in order to avoid problems like this.
>
> I'd say this is the only practical s
Signed-off-by: Elijah Newren
---
merge-recursive.c | 18 +-
merge-recursive.h | 1 +
2 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index f110e1c5ec..bf3cb03d3a 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -2843,
Elijah Newren writes:
> Also, since the directory rename detection from this cycle was
> specifically added in merge-recursive and not diffcore-rename, remove the
> 'in "diff" family" phrase from the note.
Thanks.
flags that imply either -m or -i).
Also, since the directory rename detection from this cycle was
specifically added in merge-recursive and not diffcore-rename, remove the
'in "diff" family" phrase from the note. (Folks have requested in the
past that `git diff` detect directory
diff.renames itself. I
do wonder why there is a special need for the status command here
The rename detection feature is nice and we'd like to leave it on
whenever possible. The performance issues only occur when in the middle
of a merge - normal status commands behave reasonably. As a r
On Fri, May 11, 2018 at 12:56:39PM +, Ben Peart wrote:
> After performing a merge that has conflicts git status will, by default,
> attempt to detect renames which causes many objects to be examined. In a
> virtualized repo, those objects do not exist locally so the rename logic
> triggers the
taking hours to complete on very large repos vs seconds with this patch.
Add a new config status.renames setting to enable turning off rename
detection during status and commit. This setting will default to the value
of diff.renames.
Add a new config status.renamelimit setting to to enable
gt; triggers them to be fetched from the server. This results in the status call
> taking hours to complete on very large repos vs seconds with this patch.
>
> Add a new config status.renames setting to enable turning off rename detection
> during status and commit. This setting will
taking hours to complete on very large repos vs seconds with this patch.
Add a new config status.renames setting to enable turning off rename detection
during status and commit. This setting will default to the value of
diff.renames.
Add a new config status.renamelimit setting to to enable
On 5/10/2018 6:31 PM, Elijah Newren wrote:
Hi Ben,
On Thu, May 10, 2018 at 12:09 PM, Ben Peart wrote:
On 5/10/2018 12:19 PM, Elijah Newren wrote:
On Thu, May 10, 2018 at 7:16 AM, Ben Peart
wrote:
Given the example perf impact is arbitrary (the actual example that
triggered this patch to
Ben Peart writes:
> Documentation/config.txt | 10
> Documentation/git-status.txt | 10
> builtin/commit.c | 41
> diff.c | 2 +-
> diff.h | 1 +
> t/t7525-status-rename.sh | 90 +
Elijah Newren writes:
>> Note: I removed the --no-breaks command line option from the original patch
>> as
>> it will no longer be needed once the default has been changed [1] to turn it
>> off.
>>
>> [1]
>> https://public-inbox.org/git/20180430093421.27551-2-eckhard.s.ma...@gmail.com/
>
> I'd
Hi Ben,
On Thu, May 10, 2018 at 12:09 PM, Ben Peart wrote:
> On 5/10/2018 12:19 PM, Elijah Newren wrote:
>> On Thu, May 10, 2018 at 7:16 AM, Ben Peart
>> wrote:
> Given the example perf impact is arbitrary (the actual example that
> triggered this patch took status from 2+ hours to seconds) and
exist locally so the rename logic triggers them to be
fetched from the server. This results in the status call taking hours to
complete on very large repos. Even in a small repo (the GVFS repo) turning off
break and rename detection has a significant impact:
It'd be nice if you could show that i
gic triggers them to
> be
> fetched from the server. This results in the status call taking hours to
> complete on very large repos. Even in a small repo (the GVFS repo) turning
> off
> break and rename detection has a significant impact:
It'd be nice if you could show that imp
taking hours to
complete on very large repos. Even in a small repo (the GVFS repo) turning off
break and rename detection has a significant impact:
git status --no-renames:
31 secs., 105 loose object downloads
git status --no-breaks
7 secs., 17 loose object downloads
git status --no-breaks --no
On 5/9/2018 12:56 PM, Elijah Newren wrote:
Hi Ben,
Overall I think this is good, but I have lots of nit-picky things to
bring up. :-)
Thank you for the review. I appreciate the extra set of eyes on these
changes. Especially when dealing with the merge logic and settings
which I am unf
On 5/9/2018 11:59 AM, Duy Nguyen wrote:
On Wed, May 9, 2018 at 4:42 PM, Ben Peart wrote:
Add a new config status.renames setting to enable turning off rename detection
during status. This setting will default to the value of diff.renames.
Please add the reason you need this config key in
enable detecting
> renames and optionaly setting the similarity index from the command line.
s/optionaly/optionally/
> Notes:
> Base Ref:
No base ref? ;-)
> +status.renameLimit::
> + The number of files to consider when performing rename detection;
> + if not specifie
On Wed, May 9, 2018 at 4:42 PM, Ben Peart wrote:
> Add a new config status.renames setting to enable turning off rename detection
> during status. This setting will default to the value of diff.renames.
Please add the reason you need this config key in the commit message.
My guess (pr
Add a new config status.renames setting to enable turning off rename detection
during status. This setting will default to the value of diff.renames.
Add a new config status.renamelimit setting to to enable bounding the time spent
finding out inexact renames during status. This setting will
Set aggressive flag in git_merge_trees() when rename detection is turned off.
This allows read_tree() to auto resolve more cases that would have otherwise
been handled by the rename detection.
Reviewed-by: Johannes Schindelin
Signed-off-by: Ben Peart
---
merge-recursive.c | 1 +
1 file changed
On Thu, Apr 26, 2018 at 1:52 PM, Ben Peart wrote:
> Set aggressive flag in git_merge_trees() when rename detection is turned off.
> This allows read_tree() to auto resolve more cases that would have otherwise
> been handled by the rename detection.
>
> Reviewed-by: Johannes Schin
Set aggressive flag in git_merge_trees() when rename detection is turned off.
This allows read_tree() to auto resolve more cases that would have otherwise
been handled by the rename detection.
Reviewed-by: Johannes Schindelin
Signed-off-by: Ben Peart
---
merge-recursive.c | 4 +++-
1 file
" output lines (as expected due to patch 35/36)
>> - 53 merged the same other than different "Checking out files: ..."
>> output (I just did a plain merge; no flags like --no-progress)
>> - the remaining 7 commits had non-trivial merge differences, all
>&
same other than different "Checking out files: ..."
> output (I just did a plain merge; no flags like --no-progress)
> - the remaining 7 commits had non-trivial merge differences, all
> attributable to directory rename detection kicking in
>
> So, it looks good to me. I
Hi Junio,
On Thu, Apr 19, 2018 at 8:05 PM, Junio C Hamano wrote:
>> On Thu, Apr 19, 2018 at 10:57 AM, Elijah Newren wrote:
>>> This series is a reboot of the directory rename detection series that was
>>> merged to master and then reverted due to the final patch hav
ue to patch 35/36)
- 53 merged the same other than different "Checking out files: ..."
output (I just did a plain merge; no flags like --no-progress)
- the remaining 7 commits had non-trivial merge differences, all
attributable to directory rename detection kicking in
So, it
Elijah Newren writes:
> On Thu, Apr 19, 2018 at 10:57 AM, Elijah Newren wrote:
>> This series is a reboot of the directory rename detection series that was
>> merged to master and then reverted due to the final patch having a buggy
>> can-skip-update check, as noted a
On Thu, Apr 19, 2018 at 11:35 AM, Elijah Newren wrote:
> On Thu, Apr 19, 2018 at 10:57 AM, Elijah Newren wrote:
>> This series is a reboot of the directory rename detection series that was
>> merged to master and then reverted due to the final patch having a buggy
>> can-
On 4/19/2018 2:41 PM, Stefan Beller wrote:
On Thu, Apr 19, 2018 at 11:35 AM, Elijah Newren wrote:
On Thu, Apr 19, 2018 at 10:57 AM, Elijah Newren wrote:
This series is a reboot of the directory rename detection series that was
merged to master and then reverted due to the final patch having
On Thu, Apr 19, 2018 at 11:35 AM, Elijah Newren wrote:
> On Thu, Apr 19, 2018 at 10:57 AM, Elijah Newren wrote:
>> This series is a reboot of the directory rename detection series that was
>> merged to master and then reverted due to the final patch having a buggy
>> can-
On Thu, Apr 19, 2018 at 10:57 AM, Elijah Newren wrote:
> This series is a reboot of the directory rename detection series that was
> merged to master and then reverted due to the final patch having a buggy
> can-skip-update check, as noted at
> https://public-inbox.org/git/
y/d
+# Commit A: z/{b,c,e_1,f}, y/{d,e_2}
+# Commit B: y/{b,c,d}
+# Expected: z/e_1, y/{b,c,d,e_2,f} + CONFLICT warning
+# NOTE: While directory rename detection is active here causing z/f to
+# become y/f, we did not apply this for z/e_1 because that would
+# give us an ad
O:z/bO:z/cO:z/d &&
+ test_cmp expect actual
+ )
+'
+
+# Testcase 3b, Avoid implicit rename if involved as source on other side
+# (Related to testcases 5c and 7c, also kind of 1e and 1f)
+# Commit O: z/{b,c,d}
+# Commit A: y/{b,c}, x/d
+# Commit B: z/
y renames. Add
+# testcases for both renamed-by-directory-rename-detection and standard
+# rename cases.
+###
+
+# Testcase 11a, Avoid losing dirty contents with simple rename
+# Commit O: z/{a,b_v1},
+# Commit A: z/{a,c_v1},
ould be able to handle
+###
+
+# Testcase 1a, Basic directory rename.
+# Commit O: z/{b,c}
+# Commit A: y/{b,c}
+# Commit B: z/{b,c,d,e/f}
+# Expected: y/{b,c,d,e/f}
+
+test_expect_success '1a-setup: Simple direct
Reviewed-by: Stefan Beller
Signed-off-by: Elijah Newren
Signed-off-by: Junio C Hamano
---
t/t6043-merge-rename-directories.sh | 143
1 file changed, 143 insertions(+)
diff --git a/t/t6043-merge-rename-directories.sh
b/t/t6043-merge-rename-directories.sh
index d045
I came up with the testcases in the first eight sections before coding up
the implementation. The testcases in this section were mostly ones I
thought of while coding/debugging, and which I was too lazy to insert
into the previous sections because I didn't want to re-label with all the
testcase re
Add a long note about why we are not considering "partial directory
renames" for the current directory rename detection implementation.
Reviewed-by: Stefan Beller
Signed-off-by: Elijah Newren
Signed-off-by: Junio C Hamano
---
t/t6043-merge-rename-directorie
.
+#
+# To be fair, we already had non-intuitive or suboptimal behavior for most
+# of these cases in git before introducing implicit directory rename
+# detection, but it'd be nice if there was a modified ruleset out there
+# that handled these cas
>out &&
+ test_line_count = 1 out &&
+ git ls-files -o >out &&
+ test_line_count = 1 out &&
+
+ git rev-parse >actual \
+ :0:y/b :3:y/c &&
+ git rev-parse >expect \
+
Reviewed-by: Stefan Beller
Signed-off-by: Elijah Newren
Signed-off-by: Junio C Hamano
---
t/t6043-merge-rename-directories.sh | 367
1 file changed, 367 insertions(+)
diff --git a/t/t6043-merge-rename-directories.sh
b/t/t6043-merge-rename-directories.sh
index cbbb
Add a testcase showing spurious rename/rename(1to2) conflicts occurring
due to directory rename detection.
Also add a pair of testcases dealing with moving directory hierarchies
around that were suggested by Stefan Beller as "food for thought" during
his review of an earlier patch s
This series is a reboot of the directory rename detection series that was
merged to master and then reverted due to the final patch having a buggy
can-skip-update check, as noted at
https://public-inbox.org/git/xmqqmuya43cs@gitster-ct.c.googlers.com/
This series based on top of master.
This
Reviewed-by: Stefan Beller
Signed-off-by: Elijah Newren
Signed-off-by: Junio C Hamano
---
t/t6043-merge-rename-directories.sh | 396
1 file changed, 396 insertions(+)
diff --git a/t/t6043-merge-rename-directories.sh
b/t/t6043-merge-rename-directories.sh
index 9ae2
This series builds on commit febb3a86098f ("merge-recursive: avoid
spurious rename/rename conflict from dir renames", 2018-02-14), also known
as patch 29/30 of en/rename-directory-detection. That patch series has
been reverted from master[1], due to a bug with patch 30/30, so does not
apply to cur
On Wed, Feb 14, 2018 at 10:51 AM, Elijah Newren wrote:
> This patchset introduces directory rename detection to merge-recursive. See
> https://public-inbox.org/git/20171110190550.27059-1-new...@gmail.com/
> for the first series (including design considerations, etc.) This series
&g
Reviewed-by: Stefan Beller
Signed-off-by: Elijah Newren
---
t/t6043-merge-rename-directories.sh | 367
1 file changed, 367 insertions(+)
diff --git a/t/t6043-merge-rename-directories.sh
b/t/t6043-merge-rename-directories.sh
index cbbb949014..a6cd38336c 1007
we already had non-intuitive or suboptimal behavior for most
+# of these cases in git before introducing implicit directory rename
+# detection, but it'd be nice if there was a modified ruleset out there
+# that handled these cas
Add a testcase showing spurious rename/rename(1to2) conflicts occurring
due to directory rename detection.
Also add a pair of testcases dealing with moving directory hierarchies
around that were suggested by Stefan Beller as "food for thought" during
his review of an earlier patch s
Reviewed-by: Stefan Beller
Signed-off-by: Elijah Newren
---
t/t6043-merge-rename-directories.sh | 396
1 file changed, 396 insertions(+)
diff --git a/t/t6043-merge-rename-directories.sh
b/t/t6043-merge-rename-directories.sh
index 9ae245a522..6db1439675 1007
amp;&
+ test_cmp expect actual
+ )
+'
+
+# Testcase 3b, Avoid implicit rename if involved as source on other side
+# (Related to testcases 5c and 7c, also kind of 1e and 1f)
+# Commit O: z/{b,c,d}
+# Commit A: y/{b,c}, x/d
+# Commit B: z/{b,c}, w/d
+# Expecte
test_line_count = 1 out &&
+ git ls-files -o >out &&
+ test_line_count = 1 out &&
+
+ git rev-parse >actual \
+ :0:y/b :3:y/c &&
+ git rev-parse >expect \
+O:
I came up with the testcases in the first eight sections before coding up
the implementation. The testcases in this section were mostly ones I
thought of while coding/debugging, and which I was too lazy to insert
into the previous sections because I didn't want to re-label with all the
testcase re
Add a long note about why we are not considering "partial directory
renames" for the current directory rename detection implementation.
Reviewed-by: Stefan Beller
Signed-off-by: Elijah Newren
---
t/t6043-merge-rename-directories.sh | 115
1 fi
or both renamed-by-directory-rename-detection and standard
+# rename cases.
+###
+
+# Testcase 11a, Avoid losing dirty contents with simple rename
+# Commit O: z/{a,b_v1},
+# Commit A: z/{a,c_v1}, and z/c_v1 has uncommitted m
able to handle
+###
+
+# Testcase 1a, Basic directory rename.
+# Commit O: z/{b,c}
+# Commit A: y/{b,c}
+# Commit B: z/{b,c,d,e/f}
+# Expected: y/{b,c,d,e/f}
+
+test_expect_success '1a-setup: Simple direct
/{b,c,e_1,f}, y/{d,e_2}
+# Commit B: y/{b,c,d}
+# Expected: z/e_1, y/{b,c,d,e_2,f} + CONFLICT warning
+# NOTE: While directory rename detection is active here causing z/f to
+# become y/f, we did not apply this for z/e_1 because that would
+# give us an add/add conflict for y/e_1
This patchset introduces directory rename detection to merge-recursive. See
https://public-inbox.org/git/20171110190550.27059-1-new...@gmail.com/
for the first series (including design considerations, etc.) This series
continues to depend on en/merge-recursive-fixes in next, at least
Reviewed-by: Stefan Beller
Signed-off-by: Elijah Newren
---
t/t6043-merge-rename-directories.sh | 143
1 file changed, 143 insertions(+)
diff --git a/t/t6043-merge-rename-directories.sh
b/t/t6043-merge-rename-directories.sh
index d045f0e31e..b22a9052b3 1007
I came up with the testcases in the first eight sections before coding up
the implementation. The testcases in this section were mostly ones I
thought of while coding/debugging, and which I was too lazy to insert
into the previous sections because I didn't want to re-label with all the
testcase re
Signed-off-by: Elijah Newren
---
t/t6043-merge-rename-directories.sh | 396
1 file changed, 396 insertions(+)
diff --git a/t/t6043-merge-rename-directories.sh
b/t/t6043-merge-rename-directories.sh
index fbeb8f4316..68bd86f555 100755
--- a/t/t6043-merge-renam
tuitive or suboptimal behavior for most
+# of these cases in git before introducing implicit directory rename
+# detection, but it'd be nice if there was a modified ruleset out there
+# that handled these cases a bit better.
+###
+
test_cmp expect actual
+ )
+'
+
+# Testcase 3b, Avoid implicit rename if involved as source on other side
+# (Related to testcases 5c and 7c, also kind of 1e and 1f)
+# Commit O: z/{b,c,d}
+# Commit A: y/{b,c}, x/d
+# Commit B: z/{b,c}, w/d
+# Expected: y/{b,c}, CONFLICT:(z/d -
Add a testcase showing spurious rename/rename(1to2) conflicts occurring
due to directory rename detection.
Also add a pair of testcases dealing with moving directory hierarchies
around that were suggested by Stefan Beller as "food for thought" during
his review of an earlier patch s
able to handle
+###
+
+# Testcase 1a, Basic directory rename.
+# Commit O: z/{b,c}
+# Commit A: y/{b,c}
+# Commit B: z/{b,c,d,e/f}
+# Expected: y/{b,c,d,e/f}
+
+test_expect_success '1a-setup: Simple directory rename detection'
Signed-off-by: Elijah Newren
---
t/t6043-merge-rename-directories.sh | 143
1 file changed, 143 insertions(+)
diff --git a/t/t6043-merge-rename-directories.sh
b/t/t6043-merge-rename-directories.sh
index d045f0e31e..b22a9052b3 100755
--- a/t/t6043-merge-renam
merge.
###
+
+###
+# SECTION 4: Partially renamed directory; still exists on both sides of merge
+#
+# What if we were to attempt to do directory rename detection when someone
+# "mostly" moved a directory but still left some f
This patchset introduces directory rename detection to merge-recursive. See
https://public-inbox.org/git/20171110190550.27059-1-new...@gmail.com/
for the first series (including design considerations, etc.), and follow-up
series can be found at
https://public-inbox.org/git
muddies up the working directory before
+# we even get to the point of detecting renames, so we need some special
+# handling. This was true even of normal renames, but there are additional
+# codepaths that need special handling with directory renames. Add
+# testcases for both renamed-by-directory-r
1 - 100 of 279 matches
Mail list logo
