[WIP]: make merge nicer to the user

From: Guillaume Cogoni <cogoni.guillaume@gmail.com>
Date: Mar 27, 2022, 15:41 UTC
Message-ID: <CAA0Qn1sBF=PAduCQCXbYkeu4cphw7O+AnvwFNMWijuKYskaT8g@mail.gmail.com>

Hi, We were working on a patch to make merge nicer to the user on tracked/untracked merge conflicts. You can see that idea on this page: https://git.wiki.kernel.org/index.php/SmallProjectsIdeas

When merging a commit which has tracked files with the same name as local untracked files, Git refuses to proceed. We want to change this behaviour. The idea is to check if the untracked and the tracked file has the same content, so we can overwrite it.

Examples of use cases where it can be interesting: The scenarios are the following:

A team member is modifying the templates for a website we are working on. They are adding some images to the images directory (but forgets to add them under source control). They are sending the images by mail, later, to me. I'm adding the images under the source control and pushing them to GitHub together with other changes They cannot pull updates from GitHub because Git doesn't want to overwrite their files. Source : https://stackoverflow.com/questions/1125968/how-do-i-force-git-pull-to-overwrite-local-files

When using rsync to get files from a distant directory, but then those files are pushed on a repo from the distant directory, you don't want to reset the change when you just need to pull the repo because files are the same.

The following parts is our test file:

diff --git a/t/t7615-merge-conflict.sh b/t/t7615-merge-conflict.sh
new file mode 100644
index 0000000000..4d89fe99ed
--- /dev/null
+++ b/t/t7615-merge-conflict.sh
@@ -0,0 +1,47 @@
+#!/bin/sh
+#
+# Copyright (c) 2022 Cogoni Guillaume and Bressat Jonathan
+#
+test_description='merge conflitct'
+. ./test-lib.sh
+
+test_expect_success '[FAST_FORWARD] merge conflict when untracked
file and tracked file have the same name and content' '
+ echo content >readme.md &&
+ test_commit "README" readme.md &&
+ git branch B &&
+ git checkout -b A &&
+ echo content >file &&
+ test_commit "tracked_file" file &&
+ git switch B &&
+ echo content >file &&
+ test_merge merge A
+'
+
+test_expect_success '[MERGE] merge conflict when untracked file and
tracked file have the same name and content' '
+ echo content >readme.md &&
+ test_commit "README" readme.md &&
+ git branch A &&
+ git checkout -b B &&
+ echo content1 >file1 &&
+ test_commit "B_tracked_file" file1 &&
+ git checkout A &&
+ echo content2 >file2 &&
+ test_commit "A_tracked_file" file2 &&
+ git switch B &&
+ echo content2 >file2 &&
+ test_merge merge A
+'
+
+test_expect_thatfailure 'merge conflict when untracked file and tracked
file have not the same content but the same name' '
+ echo content >readme.md &&
+ test_commit "README" readme.md &&
+ git branch B &&
+ git checkout -b A &&
+ echo content1 >file &&
+ test_commit "tracked_file" file &&
+ git switch B &&
+ echo content2 >file &&
+ test_merge merge A
+'
+
+test_done
Those tests must have assert in the end but it's just to explain our idea.

Our research lead us to these functions:

verify_absent_1() from /unpack-trees.c seems to be called for all files
and it check if a file from the merged branch exists in the current
branch in regard of the name and the path (In our test above, if a file
from the branch A exist in the branch B.). Then call check_ok_to_remove()
from /unpack-trees.c when an untracked file with the same name than a
tracked file on the merged branch is spotted.

static int verify_absent_1(const struct cache_entry *ce,
enum unpack_trees_error_types error_type,
enum absent_checking_type absent_type,
struct unpack_trees_options *o);

static int check_ok_to_remove(const char *name, int len, int dtype,
const struct cache_entry *ce, struct stat *st,
enum unpack_trees_error_types error_type,
enum absent_checking_type absent_type,
struct unpack_trees_options *o);


We think that a good way to solve this problem is to check the hash
of the tracked and untracked file in check_ok_to_remove and then if
they are similar we can
overwrite it (return 0). The hash is in ce->object_id.
In fact, it's more efficient than decompress the file and check
the content.

Do you think, we are going in the good way, and is it a good idea ?

thanks for your help and review.

Guillaume Cogoni and
Jonathan Bressat