Thank you. I was hoping to be the one that fixed this because it was a level of logic that matched my current knowledge level. I appreciate you jumping in with a fix and also confirming this was unexpected behavior. I was kind of surprised no one has reported this before. Cheers, Ryan > On Oct 30, 2021, at 1:39 PM, Johannes Altmanninger <aclopte@xxxxxxxxx> wrote: > > On Tue, Oct 26, 2021 at 03:11:36PM +0000, Ryan Hodges (rhodges) wrote: >> Hi all, >> >> I’ve got a quick question about ‘git apply –intent-to-add’. If I’ve got a patch that just adds one file to the tree: >> >> [sjc-ads-2565:t.git]$ git diff >> diff --git a/c.c b/c.c >> new file mode 100644 >> index 0000000..9daeafb >> --- /dev/null >> +++ b/c.c >> @@ -0,0 +1 @@ >> +test >> >> and I apply that patch with –intent-to-add: >> >> [sjc-ads-2565:t.git]$ git apply --intent-to-add c.diff >> >> The newly added file is tracked but other files in the tree get marked as deleted: >> >> [sjc-ads-2565:t.git]$ git status >> On branch master >> Changes to be committed: >> (use “git restore –staged <file>…” to unstage) >> deleted: a.c > > Yep, looks like a bug to me. > git apply should never change the status of files that are not mentioned in > the input patch. > >> deleted: b.c >> >> Changes not staged for commit: >> (use “git add <file>…” to update what will be committed) >> (use “git restore <file>…” to discard changes in working directory) >> new file: c.c >> >> It looks like Git created a new index with only the newly added file in the patch. > > Seems so. > >> However, I’d like Git to just add one entry to the index corresponding >> to the newly added file in the patch. Is this a bug or am I completely >> misinterpreting the goal of ‘intent-to-add’. > > Yeah, I think your "git apply --intent-to-add c.diff" should behave exactly like > > echo test > c.c && git add --intent-to-add c.c
