# [PATCH/WIP] Repair DF conflicts during fetch. 4 messages from 2013-11-29 to 2013-12-01. Participants: Tom Miller, Thomas Rast, Thomas Miller. Thread: https://gitlist.dev/t/35437 ## Tom Miller, 2013-11-29 17:57 Subject: [PATCH/WIP] Repair DF conflicts during fetch. Message-ID: <1385747858-29343-1-git-send-email-jackerran@gmail.com> URL: https://gitlist.dev/e/1385747858-29343-1-git-send-email-jackerran%40gmail.com ``` 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, 2013-11-29 17:57 Subject: [PATCH/WIP] Repair DF conflicts during fetch. Message-ID: <1385747858-29343-2-git-send-email-jackerran@gmail.com> URL: https://gitlist.dev/e/1385747858-29343-2-git-send-email-jackerran%40gmail.com In-Reply-To: <1385747858-29343-1-git-send-email-jackerran@gmail.com> ``` 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 --- builtin/fetch.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) 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, 2013-11-29 19:07 Subject: Re: [PATCH/WIP] Repair DF conflicts during fetch. Message-ID: <871u1zf2nd.fsf@thomasrast.ch> URL: https://gitlist.dev/e/871u1zf2nd.fsf%40thomasrast.ch In-Reply-To: <1385747858-29343-2-git-send-email-jackerran@gmail.com> ``` Tom Miller 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 > --- > 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 ``` ## Thomas Miller, 2013-12-01 15:03 Subject: Re: [PATCH/WIP] Repair DF conflicts during fetch. Message-ID: URL: https://gitlist.dev/e/CAECD2aGaL84n01-0fuNfyy-mx8NPKz2Vbhy3LpTgdOxgWayERw%40mail.gmail.com In-Reply-To: <871u1zf2nd.fsf@thomasrast.ch> ``` On Fri, Nov 29, 2013 at 1:07 PM, Thomas Rast wrote: > Tom Miller 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 >> --- >> 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. ```