Try the following command, which I have tested:

$ cp -pv --parents $(git diff --name-only) DESTINATION-DIRECTORY

Your question conceals a fundamental issue. Let's take a look at a typical commit graph fragment:

...--E--F--G--H--I--J  <-- master

You pick two commits, such as E and I, and run git diff --name-only (or git diff --name-status) to compare them:

$ git diff --name-only <hash-E> <hash-I>
myfolder/a.txt
code/snippet.c
test.txt

but then say:

... the result should be files introduced with the corresponding SHA.

The fact that these file names come out means that all three files are present in commits E and/or I, but if you had commit E in your work-tree and wanted to modify it to get commit I, those three files would need some kind of change: create, modify, or even delete. Using --name-status will give you the kind of change as well: A for "the file is to be newly created", M for "the file is to be modified", and D for "the file is to be deleted". (There are, of course, probably dozens or thousands of files in both E and I that are the same and hence are not printed here.)

But now you ask for the corresponding hash where this change is introduced. There may not be a the hash. There might be more than one. (There must be at least one of course). For instance, test.txt might be removed entirely in F by mistake (instead of being corrected), put back intact-but-wrong in H, and then corrected in I. Meanwhile code/snippet.c might be modified in both G and I.

Which commit hash(es) would you like for each file? The answer to that determines how to find them. (Of course, if there is only one such hash, the problem vanishes.)

xxfelixxx's answer gives a (slighlty faulty but easily fixed and improved) method for obtaining one commit—the first one git log prints. To fix the one bug and improve it a bit, replace the do sequence with:

do echo -n "$file "; git rev-list <starthash>..<endhash> -- "$file" | head -1

That is, we want to find one of the commit hashes printed by git rev-list when run only over the specified start/stop points and looking for changes to the one file. We need <starthash>..<endhash> to do the initial commit-limiting, and the -- $file to select only commits that add, modify, or remove that one path. Note that if there are spaces in the file name you will need to quote it (so I did), although then reading the output of git diff itself gets tricky too.

Using head -1 gets you the most recent commit that touched the file, e.g., with our example where code/snippet.c in both G and I, you get the hash for commit I. This is because Git works backwards, from newer commits to older ones. If you want the first one, use tail -1, and if you want all of them, you will need a fancier format. :-)

(There is another subtle difference here, between git log and git rev-list, involving merge commits, but that probably won't affect you.)

According to GitConfig there is no such option among configuration variables, so you can only achieve this using Git Aliases

git config --global alias.diffn 'diff --name-only'

Or setting it manually in .gitconfig under [alias] section:

diffn = diff --name-only

I would also recommend looking at dotfiles repos for more inspiration on aliases and .gitconfig

AFAIK this is not provided by git since this is a pretty unusual requirement. For example my first try in my repository yielded about a dozen lines, each saying pom.xml because I just created a new version.

You can use a small script though. basename is your friend here.

I like xargs so I'd do it like this

git diff --name-only <commit> <commit> | xargs -n1 basename

This will fail if git diff provides no output.

Or for a loopy version

for s in `git diff --name-only <commit> <commit>` ; do basename $s ; done

Building on torek's answer, I was able to achieve this in one line using the --line-prefix flag:

git diff --name-only --line-prefix=`git rev-parse --show-toplevel`/ HEAD release

Besides the --name-flag that displays only the file name, the git diff command (without other arguments) will display the difference between your index and your working directory (as explained in the diagaram here).

Whereas the git status command will display the whole current status of your working tree (files that are staged, modified, deleted, untracked etc.)

However, by considering the -s flag that shorten the output of the status command (which typically display only names), we can have some situations where these two commands will give you "almost" the exact same output.. It all depends of what you already did in your working directory.

For example, if you do git status -s, you will get all the differences from your working directory against your HEAD and your index including untracked files.. (But say you don't have untracked files..)

On the other hands, and regardless of what you already staged or not, if you do git diff --name-only HEAD (see the above-mentioned diagram), there is a chance that you get almost the same output.

Also, the results are almost the same (not exactly the same) because git status -s shows pretty useful additional information:

• a letter at the beginning of the line that summarize the status (M for modified, D for deleted, A for added, ? for untracked files)
• a color code that shows what are already staged (green for staged, red for unstaged).

So, we can consider that diff is more suited to view differences in actual file contents. That is why not displaying untracked files by diff makes sense.. Comparing differences starting from only something we have (the tracked files)..

All that said, if you want some concise output about your actual changes (after all this is the rational for using --name-only) you should really consider git status -s.

#! /bin/sh
# See the discussion at https://stackoverflow.com/q/67724347/7976758

if [ -z "$1" ]; then
    echo "Usage $0 from_commit [to_commit]"
    exit 1
fi

if [ -z "$prog_dir" -o -z "$prog_name" ]; then
    start_dir="`pwd`"
    prog_dir="`dirname \"$0\"`"
    prog_name="`basename \"$0\"`"
    cd "$prog_dir"
    # Get full path
    prog_dir="`pwd`"
    cd "$start_dir"
    export prog_dir prog_name
fi

from_commit="$1"
to_commit="${2:-HEAD}"
export from_commit to_commit

# In the superproject
git --no-pager diff --name-only "$from_commit" "$to_commit"

git submodule foreach '
    # In submodule "$name"
    prev_commit=`(git -C "$toplevel" ls-tree "$from_commit" "$sm_path" | awk "{print \\$3}")`
    curr_commit=`(git -C "$toplevel" ls-tree "$to_commit" "$sm_path" | awk "{print \\$3}")`
    "$prog_dir/$prog_name" $prev_commit $curr_commit
'

You can use the -z option to get nul termination instead of the C string literal quoting to deal with non-ASCII characters in paths.

files=$(
    git diff -z --cached --name-only --diff-filter=ACMR \
    | grep -Ez "$extension_regex" \
    | tr \\0 \\n
)

utf-8 is still not completely universal and may never be, filesystems are so disparate that anything beyond ASCII is not entirely portable. Git's playing it annoyingly safe with its default to encoding anything that won't roundtrip in ASCII using C string literal conventions, but its choice does have that safe roundtrippability going for it which basically nothing else does (at least not yet) so there's that.

If you're not worried about completely unconstrained file names, in particular if you don't need to handle file names containing their own \n's, newlines, you can hike the tr up a step and remove the -z option on the grep, or drop the -z option entirely, turn core.quotepath off. From the command line:

git -c core.quotepath=false diff --name-only | grep etc

or in the configs.

Once a file is under version control, ignoring it doesn't work. You can ignore untracked files only. If you don't want to delete the file, fix the line endings and take a look at Dealing with line endings.

Line endings and encoding are common problems when different platforms are used in the same project. Add a .gitattributes file, as described in the GitHub article. Be aware that setting the line endings in git's configuration is not enough, you will have to fix the files yourself or use the suggested auto-fix in the article.

Here's the solution I came up with:

files0 = %x(git diff --name-only master).split($RS)

require 'rugged'
files1 = []
changed = %i(index_modified index_new worktree_modified worktree_new)
repo = Rugged::Repository.new(Dir.pwd)
repo.status { |f, d| files1 << f unless (changed & d).empty? }

puts(files0.sort == files1.sort ? "PASS" : "FAIL")

You can use this command to see the changed file names, but not with line numbers:

git diff --name-only

Go forth and diff!

git diff --name-only produces a list of files; you need to give that list to grep in a form it will understand, i.e. as command-line arguments. One way to do this is

git -C "${dir}" diff -z --name-only HEAD^ HEAD | xargs -0 grep -lw --include="*.yml" --exclude-dir="$excluded_paths" -e "- name:"

I added -z so that the file names are separated by null bytes; the -0 xargs option specifies the same delimiter for use in xargs’ input. I removed the -r option from grep — that is used for recursive searches, which is counter-productive here since the exact list of files to check is given.

It's an "imaginary diff option", used to indicate to the reader that it's not just the output of running the diff command. For example, in git's own git repo:

$ git diff HEAD~1..HEAD | head
diff --git Documentation/git.txt Documentation/git.txt
index bd659c4..7913fc2 100644
--- Documentation/git.txt
+++ Documentation/git.txt
@@ -43,6 +43,11 @@ unreleased) version of Git, that is available from the 'master'
 branch of the `git.git` repository.
 Documentation for older releases are available here:
 
+* link:v2.10.0/git.html[documentation for release 2.10]
+
$ 

The diff command itself, if you invoked it with the same file name twice, would show no differences. git presumably creates temporary files corresponding to two different versions of Documentation/git.txt and feeds them to diff -- but the names of those temporary files would not be useful. I think git diff massages the output of diff to make it more meaningful to the reader. (This speculation was not entirely correct. See below.)

Diving into the git source code, diff.c has the string "diff --git" hardwired as a string literal:

strbuf_addf(&header, "%s%sdiff --git %s %s%s\n", line_prefix, meta, a_one, b_two, reset);

And looking into the history of diff.c for the earliest version that contains that string:

$ git log -n 1 b58f23b3
commit b58f23b38a9a9f28d751311353819d3cdf6a86da
Author: Junio C Hamano <[email protected]>
Date:   2005-05-18 09:10:47 -0700

    [PATCH] Fix diff output take #4.
    
    This implements the output format suggested by Linus in
    <[email protected]>, except the
    imaginary diff option is spelled "diff --git" with double dashes as
    suggested by Matthias Urlichs.
    
    Signed-off-by: Junio C Hamano <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
$ 

Presumably <Pine.LNX...> is the message-id of some email message in a mailing list somewhere. In any case, this commit message makes it clear that diff --git is an "imaginary diff option".

This email message, cited by nos in a comment, appears to be part of the discussion that led to this. Update: That link is now dead, and I don't know whether the archive is available elsewhere.

UPDATE: I speculated above that git diff massages the output of diff, adding this information. I just tried running git diff under strace. It doesn't actually invoke the diff command, or any other command. Rather, all the output is printed by the git process itself, and apparently it computes the differences internally. This behavior might also depend on the version of git (I'm using 2.23.0), the diff command(s) available, and the arguments used.

I'll note that GNU diff has a --label=LABEL option that could be used for this kind of thing:

'-L LABEL'
'--label=LABEL'
     Use LABEL instead of the file name in the context format (*note
     Context Format::) and unified format (*note Unified Format::)
     headers.  *Note RCS::.

but git diff doesn't use it, at least in the one case I tried, and I don't see a reference to it in the git sources.