Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Commit hashes different between splitsh-lite and git subtree split, part II #39

Closed
kdambekalns opened this issue Nov 13, 2017 · 6 comments

Comments

@kdambekalns
Copy link
Contributor

This is named like #20, but a different bug, as far as we know.

The commit neos/flow-development-collection@882be01 results in neos/flow@4d563e6 right now, using the subtree split. Splitting using splitsh it ends up in kdambekalns/flow@79cae3e. The latter looks exactly like the commit from the development collection…

Looking further, there is no difference between the results, but the hashes differ. To maximise confusion, GitHub actually shows a difference, locally Git says it's the same (https://github.com/neos/flow/compare/3.0...kdambekalns:3.0-splitsh?expand=1 vs. git diff 3.0..3.0-splitsh after cloning kdambekalns/flow)

The split was done using splitsh-lite --prefix=TYPO3.Flow --origin=origin/3.0 --target=refs/heads/3.0-splitsh

@kdambekalns
Copy link
Contributor Author

To top it off, we created a PR from the "difference" at kdambekalns/flow#1 that showed differences in 20 files. We wanted to have fun and merged that, resulting in no changes (see kdambekalns/flow@f5d167d) - which we expected, since the changes the PR wanted to do, actually existed in the base branch.

After the merge, the fork is now 23 commits ahead of the original, but again (as expected), no differences: https://github.com/neos/flow/compare/3.0...kdambekalns:3.0?expand=1

So, this might even be a bug in git and/or git-subsplit, and splitsh actually gets it right.

@kdambekalns
Copy link
Contributor Author

No bug in GitHub, it’s caused by a “two dot” vs “three dot” diff. But the difference between the results is real.

@kdambekalns
Copy link
Contributor Author

Anyone feels like being able to help with finding out the cause for this?

@dxops
Copy link

dxops commented Feb 28, 2018

I think you have the same case like we discussed some time ago in #26 (comment)

@cebe
Copy link

cebe commented Apr 5, 2018

sounds similar to yiisoft/yii2#15785 (comment)

@kdambekalns
Copy link
Contributor Author

I am more or less convinced this cannot be changed and is the result of changes "to git itself". Thanks everyone for their input!

We'll most likely just accept the different hashes, composer should iron out any glitches for us (by preferring tags over hashes) except in the rarest edge-cases. 🤞

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants