How do I include the list of changed files FOR EACH COMMIT when squashing commits?

When making commits, I tend to say things like "Removed xyz property" in my commit message, where the commit message kind of depends on you seeing the file list in order to see which files had xyz property removed.

When squashing commits, I can get the union of files that changed in all squashed commits. But I don't see a way to list the files that changed for each commit, and put that information down in the commit message. Maybe I am misusing the tool, but I basically want to be able to highlight the "broad-stroke changes" that were done to each file, but not require each change's diff to be separately identified and saved.

To give a simple example, let's say I have files A-D.

1. Removed xyz attribute
   • A, B, C
2. Removed tuv attribute
   • B, C, D

When squashing, I'll get the union, which is A-D. But I want to be able to specify which files changed for each commit, and then put that into the commit message.

If this is too close to "then just don't squash in the first place", then that's fine. But if there is a way to list the files changed for each commit in the commit message when squashing, I would like that. Only way I can see to do it now is to manually fat-finger in each filepath.

My reason for wanting to squash in the first place is that I like to make a bunch of tiny commits, to enumerate each tiny task. Great for reverting if I make a mistake on the feature branch, but once it is time to merge into the main branch, all those tiny commits just clutter up the logs and make it hard to find what you did.

The reason that this is valuable to me is to make it easier to see later on which files had xyz attribute explicitly removed, vs which files didn't have xyz attribute in the first place.

But like I said -- if this is just better served by not squashing in the first place, then please say as much.

if this is just better served by not squashing in the first place, then please say as much.

Yes. Keep your original commits as is. Squash merging is a fundamentally destructive process that looses/discards information as you notice, and any attempts to mitigate that will be just band-aid.

but once it is time to merge into the main branch, all those tiny commits just clutter up the logs and make it hard to find what you did.

When there is a need to provide an overall comment/summary/context for all the commits in a pull request, the commit message for the merge commit is the place to put that. It is an obvious place and easy to find.

I suspect that your frustration is partially caused by not using a good tool to visualize the version history. So start using gitk to view your history, it has also additional benefits.

If you want to have greater visibility of pull request merge commits just create tags for those. I use the following make-pr-tags.sh script:

#!/bin/sh

# Output example from git --oneline:
#   965ca97ad Merge pull request #4993 from node-red/login-prompt

# Corresponding input to sh:
#   git tag pr-4993 965ca97ad

# Adding a "set -e" at the beginning so that when running this script
# after it has been run before it gives up whenever it comes to a tag
# that already has been created rather than continuing all the way back
# to the root commit.
( \
        echo set -e; \
        git log --oneline "$@" | awk '/^[0-9a-f]* Merge pull request /{ sub(/#/, "", $5); print "git tag pr-" $5 " " $1}' | tr -d : \
) | sh

which then makes the pull request commits super easy to spot: