[PATCH v5 16/34] merge-recursive: introduce new functions to handle rename logic

The amount of logic in merge_trees() relative to renames was just a few lines, but split it out into new handle_renames() and cleanup_renames() functions to prepare for additional logic to be added to each. No code or logic changes, just a new place to put stuff for when the rename detection

[PATCH v5 13/34] directory rename detection: tests for handling overwriting untracked files

Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 337 1 file changed, 337 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh b/t/t6043-merge-rename-directories.sh index c731a1b03..7248c3807 100755 ---

[PATCH v5 02/34] merge-recursive: fix logic ordering issue

merge_trees() did a variety of work, including: * Calling get_unmerged() to get unmerged entries * Calling record_df_conflict_files() with all unmerged entries to do some work to ensure we could handle D/F conflicts correctly * Calling get_renames() to check for renames. An easily

[PATCH v5 15/34] merge-recursive: move the get_renames() function

I want to re-use some other functions in the file without moving those other functions or dealing with a handful of annoying split function declarations and definitions. Signed-off-by: Elijah Newren --- merge-recursive.c | 139

[PATCH v5 09/34] directory rename detection: testcases checking which side did the rename

Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 321 1 file changed, 321 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh b/t/t6043-merge-rename-directories.sh index 468d6d537..50fb8f41e 100755 ---

[PATCH v5 01/34] Tighten and correct a few testcases for merging and cherry-picking

t3501 had a testcase originally added in 05f2dfb965 (cherry-pick: demonstrate a segmentation fault, 2016-11-26) to ensure cherry-pick wouldn't segfault when working with a dirty file involved in a rename. While the segfault was fixed, there was another problem this test demonstrated: namely, that

Re: Bring together merge and rebase

On Wed, Dec 27, 2017 at 03:35:58PM +0200, Alexei Lozovsky wrote: > I think the reasoning behind Theo's words is that it would be better > to first implement the commit relationship tracking as an add-in which > uses commit messages for data storage, then evaluate its usefulness > when it's

Re: [PATCH v2 6/7] wt-status.c: handle worktree renames

On 27/12/2017 02:06, Duy Nguyen wrote: > > > ... > > > >The pathname. In a renamed/copied entry, this > > is the path in the index and in the working tree. > > Gaah.. as you may see in the other mail when I quoted this > (incorrectly). I must have modified this file at

Re: [PATCH v2 7/7] wt-status.c: avoid double renames in short/porcelain format

On 27/12/2017 01:49, Duy Nguyen wrote: > > > I lost you a bit here, partially because of what seems to be an > > incomplete setup script, partially because of this last sentence, as > > Git v2.15.1 doesn`t seem to be showing this, so not sure about "like > > we have been showing until now"

[PATCH] dir.c: avoid stat() in valid_cached_dir()

stat() may follow a symlink and return stat data of the link's target instead of the link itself. We are concerned about the link itself. Signed-off-by: Nguyễn Thái Ngọc Duy --- I noticed this while looking at the untracked cache bug [1] but because it's not directly related

Re: What's cooking in git.git (Dec 2017, #05; Wed, 27)

On Wed, Dec 27, 2017 at 1:34 PM, Junio C Hamano wrote: > * ew/empty-merge-with-dirty-index (2017-12-22) 1 commit > - Merge branch 'ew/empty-merge-with-dirty-index-maint' into > ew/empty-merge-with-dirty-index > (this branch uses ew/empty-merge-with-dirty-index-maint.) > *

Re: [PATCH] status: add a failing test showing a core.untrackedCache bug

On Wed, Dec 27, 2017 at 07:50:29PM +0100, Ævar Arnfjörð Bjarmason wrote: > > This needs SYMLINKS prereq, which in turn means it cannot be tested > > on certain platforms. I thought Duy's answer was that this does not > > need to involve a symbolic link at all? If so, perhaps we can have > >

<    1   2