Using the command git log --numstat I can see that the last commit for the file MyFile shows some lines added. Which means that the last thing it has been done to MyFile is that somebody has added some lines to it.

At the same time I can not find MyFile in the project folder. Therefore I assume that MyFile is referenced in some branches but not in the current branch.

Is this a correct assumption? If so, is there a way to find which branches actually have references to MyFile?

CodePudding user response：

This could be explained if the following occurred:

1. The file was deleted on branch A.
2. The same file was modified on branch B after the deletion occurred (timewise).
3. Branch B is merged into branch A, which resulted in a conflict, and the deletion was selected.

Here's an example bash script to demonstrate this:

#!/bin/bash -v

git init

echo asdf > asdf.txt && git add . && git commit -m "Add file asdf.txt"

git branch test-branch

rm asdf.txt && git add . && git commit -m "Delete asdf.txt"

git switch test-branch

sleep 1 # pause for one second to make sure commit datetimes are different

echo qwer >> asdf.txt && git add . && git commit -m "Add qwer to asdf.txt"

git switch main

git merge test-branch --strategy=ours --no-edit # cheat to prevent a conflict and skip the other commit

ls -la # prove there are no files

git log --numstat # the most recent commit of asdf.txt is adding a line

CodePudding user response：

As Lasse V. Karlsen said in a comment, by default, git log starts from the current or HEAD commit, and then works backwards from there. So:

$ git log
commit cefe983a320c03d7843ac78e73bd513a27806845 (HEAD -> master ...
...
5       0       Documentation/RelNotes/2.34.0.txt

commit 45d141a1ddbc55c220ad4c726c02bbbf7a69247a
  :
  :

commit 187fc8b8b6e7a2b65f7c74cfaa8aa6bad36a18b2
...
29      15      unicode-width.h

Here we see that unicode-width.h was modified in commit 187fc8b8b6e7a2b65f7c74cfaa8aa6bad36a18b2. Just read upwards a bit from the numstat output to find the commit hash ID where, based on the result of git diff, the parent-vs-child has the given change to the given file.

At the same time I can not find MyFile in the project folder. Therefore I assume that MyFile is referenced in some branches but not in the current branch.

Branches (branch names) are irrelevant; only commits matter. Each commit is on zero or more branches, so commit 187fc8b8b6e7a2b65f7c74cfaa8aa6bad36a18b2 could be on 27 branches, or just on master (it's definitely on master since my git log started from HEAD which names master). The file unicode-width.h is definitely in that commit.

Whether a file is in your working tree is also not really relevant, but if a file MyFile isn't in your working tree, running:

git log MyFile

will usually give you an error. However:

git log -- MyFile

will not give you an error. The reason is that here, git log knows to use MyFile as a path name:

$ rm Makefile
$ git log Makefile
fatal: ambiguous argument 'Makefile': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'

Git is trying to treat Makefile as a hash ID (it can't be one: it has some bad letters in it; badf00d or deadcab or feedc0ffee could be an abbreviated hash ID, but c0mmand0 cannot be because neither m nor n are valid hexadecimal digits), or as a branch or tag name (but it isn't one), or some other way of finding a commit: see the gitrevisions documentation for some of the many, many ways to specify particular commits. The -- syntax, however, tells Git commands that what follows is not an option, even if it resembles one, and in this case not a revision specifier either. So git log now treats it as a file name:

$ git log -- Makefile
commit 8f79fb6445cb1d17c5527ba958e460725e7b111e
Merge: 68658a867d 32da6e6daf
Author: Junio C Hamano ...

(and of course I can restore the file I removed with git restore or git checkout or git reset --hard or whatever, which I did since I do not really want to remove it).