GitFiend / Support

Public repo for GitFiend questions and issues
117 stars 7 forks source link

containing files in a merge commit are confusing #206

Open MrJack91 opened 3 months ago

MrJack91 commented 3 months ago

Hi

How exactly do you display the files containing in a commit?

image

For this merge commit gitfiend does display me the file from the branch I merged to. (Which does not have changed!)

If I use "git log --stat" i'm not able to see this file, which seems to me to be correct. (the "base" file here).

image This file was correctly contained in the 13cff commit.

I did this as a minimal example

mkdir git-merge-ex
cd git-merge-ex/

git init
touch base
touch feature
ll
git add base feature
git commit -a -m "init"

git switch -c dev
git switch -c tst
git switch -c prd
git switch dev

echo "\n\nnew feature on dev" >> base
git commit -a -m "new feat"

git switch tst
git merge dev

git switch prd
echo "hotfix: on feature on prd" > feature
git commit -a -m "hotfix on prd"

git switch tst
git merge prd
git switch dev
git merge prd
git merge tst

git log --stat

# for the last "git merge tst" (to dev), there should be no change. (its like if you use the command line)
# but gitfiend and gitlab do display the base file.

We got some confusion internally, because this behaviour. It seems that gitlab is using the same method you do. But not source tree...

Thanks for any explanation.

Best

GitFiend commented 3 months ago

You can see the code here: https://github.com/GitFiend/gitfiend-core/blob/main/src/git/queries/patches/patches.rs in the function load_patches_for_commit. I haven't yet found an algorithm/git commands that works in every case to show you what you would expect.

MrJack91 commented 3 months ago

Thanks for the quick answer and your awesome work.

For a merge commit there is a: git diff --name-status <merge_commit>^1...<merge_commit>^2

As far that i understand: --> 3 dots, means compare the common ancestor between these commits with the <merge_commit>^2. It's often the case, that the common ancestor is way behind, which lead to many more changes than assumed. And this can lead to confusion.

I don't think this behavior is intuitive und i would prefer the actually affected files. Like all these commands provide:

# just the diff between the commits the merge combines
git diff --name-status <parent_id_1> <parent_id_2>

# or what git show for this commit displays
git show --name-status <merge_commit>

# or what also logs display
git log --stat

The 3dot variant is more for developers, to see what changed since then. But not for the history, where the focus in my opinion should be who changed what, when.

Or in what case is this view more useful?

Or it would be useful to explain this e.g. in the diff window of the merge commits.