2

Hello i have 2 branches

  • master
  • feature_xyz

Some how it happens a couple of commits which originated in master branch and also in feature_xyz got different commit ids.

So it is not more possible to find out which commits are really related to the feature.

We dont cherry-pick those commits.

How is it possible that a commit got different commit ids? Normaly a commit should have the same id in all branches.

Is there any merge or rebase option that can cause this issue?

Here my try to reproduce

##### simple Test Setup
git init
echo "test" > a ; git add a ; git commit -m "master commit 1"
git checkout -b feature_xyz
echo "test" > b ; git add b ; git commit -m "feature commit 1"
git checkout master
echo "test" > c ; git add c ; git commit -m "master commit 2"
git checkout feature_xyz
echo "test" > d ; git add d ; git commit -m "feature commit 2"

### Test run 1
git rebase master
# Validating by    git log master    compare to     git log feature     The commit ids are identical.


##### complex Test Setup
rm ./* ; rm .git -rf
git init
echo "test" > a ; echo "hello" >> a ; echo "World" >> a ; git add a ; git commit -m "master commit 1"
git checkout -b feature_xyz
echo "test" > b ; git add b ; git commit -m "feature commit 1"
git checkout master
sed -i -e 's/World/wOrlD/g' a ; git add a ; git commit -m "master commit 2"
git checkout feature_xyz 
sed -i -e 's/hello/HELL/g' a ; git add a ; git commit -m "feature commit 2"
########################

### Test run 2
git rebase master
git mergetool
git rebase --continue
# Validating by    git log master    compare to     git log feature     The commit ids are identical.

### Test run 3
git merge master
git mergetool
git commit
# Validating by    git log master    compare to     git log feature     The commit ids are identical.

In real world the feature branch is ages old an i have no clue how this effect happen.

GreenRover
  • 1,486
  • 1
  • 14
  • 33
  • 1
    Commit ids include the complete history of that commit. Rebasing changes history and thus the commit id. – melpomene Jun 09 '17 at 11:29
  • should a rebase no change the commit ids of the commits qhich are newly in the feature branch but not the commit ids from master? – GreenRover Jun 09 '17 at 11:30
  • 2
    Possible duplicate of [git rebase -- unexpected mismatch of my hashes](https://stackoverflow.com/questions/5144776/git-rebase-unexpected-mismatch-of-my-hashes) – Joe Jun 09 '17 at 11:32
  • 1
    How did those commits get into two branches? – melpomene Jun 09 '17 at 11:33

2 Answers2

1

If you have one commit, then it always has the same SHA value. If you modify this commit somehow, it will get a new SHA value. A rebase is effectively the same as a cherry-pick, just in an automated way. The author, commiter, author date, committer date, changes, message and history (parent commits) all are part of the SHA of a commit. If you change any of these variables e. g. by rebasing or cherry-picking, you get a new commit with a different SHA that happens to introduce the same changes as your previous commit. A commit never belongs to any branch, it is just part of a branch at a certain point in time. But as you can repoint a branch pointer to any other commit at any time, this may change at any time.

Vampire
  • 35,631
  • 4
  • 76
  • 102
  • Can you modify my reproducer to run into this problem? – GreenRover Jun 09 '17 at 11:55
  • To be honest I didn't really look at your reproducer. I just gave general information about the SHAs, when they change and especially as you mentioned rebase. – Vampire Jun 09 '17 at 12:23
  • Especially as I don't know which SHAs you expect to be different. It would help if you could grant a look at the repository history where the effect is in place, then it can maybe be told how this could have happened. – Vampire Jun 09 '17 at 12:28
  • Sorry this repository is not public. But i have the same commit (identical commit message, author ...) But the commit id differs between the master and feature branch. – GreenRover Jun 09 '17 at 12:29
  • I already told you what is part of the SHA. If the SHAs are different, they are **not** the same commit. If you have a commit with the same changes and metadata on two different branches with different parent commits, they are **not** the same commit and thus have idfferent SHAs. – Vampire Jun 09 '17 at 12:43
1

You wrote that you did not cherry-pick the commit, but later mentioned rebase. But rebase is basically performing cherry-picks. So could it be the you have rebased those commits?

Anyway, to get more light on the issue, check both author and committer fields on the commits. You can find them by command git show -s --pretty=fuller <commit id>. You should get this (copied from manual):

commit <sha1>
Author:     <author>
AuthorDate: <author date>
Commit:     <committer>
CommitDate: <committer date>
<title line>
<full commit message>

Usually at cherry-pick or rebase the committer info is created new, and author is preserved. So you can find who and when performed the cherry-pick and rebase.

max630
  • 8,762
  • 3
  • 30
  • 55