threads / patch / 35437

patchRepair DF conflicts during fetch.

Subject: [PATCH/WIP] Repair DF conflicts during fetch.

## tl;dr

4 messages between Nov 29, 2013 and Dec 1, 2013. Diffs are folded; open one to read it.

replies: 3people: 2as markdown or json

Tom Miller· Nov 29, 2013, 17:57 UTC · lore

I encountered a directory/file conflict when running `git fetch --prune origin`. I figured passing --prune would automatically fix DF conflicts. After looking in the code I found that prune is called after fetching. It seemed to be intentional according historical commits. I made this patch to change it, which seems to work as I expected it to. This patch doesn't have any tests and it breaks the output when it does prune branches. I'm looking for guidance to help with fixing the broken output. I tried to figure out a way to do it on my own but I realize that I don't have the expertise with the codebase or C.

Thanks, for any help that I may recieve in advaned this is my first time posting. If I have submitted this wrong I applogize and look forward to any advice that I may recieve in correcting my mistakes.

Tom Miller (1):
  Repair DF conflicts during fetch.

 builtin/fetch.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

-- 
1.8.5.rc3.dirty

Tom Miller· Nov 29, 2013, 17:57 UTC · re: Tom Miller · lore

When a DF conflict occurs during a fetch, --prune should be able to fix it. When fetching with --prune, the fetching process happens before pruning causing the DF conflict to persist and report an error. This patch prunes before fetching, thus correcting DF conflicts during a fetch.

Signed-off-by: Tom Miller <jackerran@gmail.com>
---
 builtin/fetch.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

Show changes to builtin/fetch.c +5 −5

diff --git a/builtin/fetch.c b/builtin/fetch.c
index bd7a101..f7959d0 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -824,11 +824,6 @@ static int do_fetch(struct transport *transport,
 
 	if (tags == TAGS_DEFAULT && autotags)
 		transport_set_option(transport, TRANS_OPT_FOLLOWTAGS, "1");
-	if (fetch_refs(transport, ref_map)) {
-		free_refs(ref_map);
-		retcode = 1;
-		goto cleanup;
-	}
 	if (prune) {
 		/*
 		 * If --tags was specified, pretend that the user gave us
@@ -857,6 +852,11 @@ static int do_fetch(struct transport *transport,
 			prune_refs(transport->remote->fetch, transport->remote->fetch_refspec_nr, ref_map);
 		}
 	}
+	if (fetch_refs(transport, ref_map)) {
+		free_refs(ref_map);
+		retcode = 1;
+		goto cleanup;
+	}
 	free_refs(ref_map);
 
 	/* if neither --no-tags nor --tags was specified, do automated tag

-- 
1.8.5.rc3.dirty

Thomas Rast· Nov 29, 2013, 19:07 UTC · re: Tom Miller · lore

Re: [PATCH/WIP] Repair DF conflicts during fetch.

Tom Miller <jackerran@gmail.com> writes:

Show 10 quoted lines

> When a DF conflict occurs during a fetch, --prune should be able to fix
> it. When fetching with --prune, the fetching process happens before
> pruning causing the DF conflict to persist and report an error. This
> patch prunes before fetching, thus correcting DF conflicts during a
> fetch.
>
> Signed-off-by: Tom Miller <jackerran@gmail.com>
> ---
>  builtin/fetch.c | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)

Good catch.

I can't comment on the correctness of the patch right now, but here's a test you could steal. It just reproduces what you describe, and I did verify that it confirms the fix ;-)

Show changes to diff +14 −0

diff --git i/t/t5510-fetch.sh w/t/t5510-fetch.sh
index 5d4581d..a981125 100755
--- i/t/t5510-fetch.sh
+++ w/t/t5510-fetch.sh
@@ -614,4 +614,18 @@ test_expect_success 'all boundary commits are excluded' '
 	test_bundle_object_count .git/objects/pack/pack-${pack##pack	}.pack 3
 '
 
+test_expect_success 'branchname D/F conflict resolved by --prune' '
+	git branch dir/file &&
+	git clone . prune-df-conflict &&
+	git branch -D dir/file &&
+	git branch dir &&
+	(
+		cd prune-df-conflict &&
+		git fetch --prune &&
+		git rev-parse origin/dir >../actual
+	) &&
+	git rev-parse dir >expect &&
+	test_cmp expect actual
+'
+
 test_done

-- 
Thomas Rast
tr@thomasrast.ch

Thomas Miller· Dec 1, 2013, 15:03 UTC · re: Thomas Rast · lore

Re: [PATCH/WIP] Repair DF conflicts during fetch.

On Fri, Nov 29, 2013 at 1:07 PM, Thomas Rast <tr@thomasrast.ch> wrote:

Show 47 quoted lines

> Tom Miller <jackerran@gmail.com> writes:
>
>> When a DF conflict occurs during a fetch, --prune should be able to fix
>> it. When fetching with --prune, the fetching process happens before
>> pruning causing the DF conflict to persist and report an error. This
>> patch prunes before fetching, thus correcting DF conflicts during a
>> fetch.
>>
>> Signed-off-by: Tom Miller <jackerran@gmail.com>
>> ---
>>  builtin/fetch.c | 10 +++++-----
>>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> Good catch.
>
> I can't comment on the correctness of the patch right now, but here's a
> test you could steal.  It just reproduces what you describe, and I did
> verify that it confirms the fix ;-)
>
> diff --git i/t/t5510-fetch.sh w/t/t5510-fetch.sh
> index 5d4581d..a981125 100755
> --- i/t/t5510-fetch.sh
> +++ w/t/t5510-fetch.sh
> @@ -614,4 +614,18 @@ test_expect_success 'all boundary commits are excluded' '
>         test_bundle_object_count .git/objects/pack/pack-${pack##pack    }.pack 3
>  '
>
> +test_expect_success 'branchname D/F conflict resolved by --prune' '
> +       git branch dir/file &&
> +       git clone . prune-df-conflict &&
> +       git branch -D dir/file &&
> +       git branch dir &&
> +       (
> +               cd prune-df-conflict &&
> +               git fetch --prune &&
> +               git rev-parse origin/dir >../actual
> +       ) &&
> +       git rev-parse dir >expect &&
> +       test_cmp expect actual
> +'
> +
>  test_done
>
>
> --
> Thomas Rast
> tr@thomasrast.ch

Thanks, I appreciate the test. I have added it and gave credit via a "Tested-by" section. I have been looking into adding a pruning header to "fix" the output, but that is just the first solution I've been able to come up with. I believe before I have an elegant solution I'll have to read the code more carefully and brush up on my C.

Thanks, Tom Miller

PS. I apologize for the duplicate message the mailing list rejected my first for not being plaintext only.