Glad to hear, I'll go ahead and close. Thanks for all the input Stephen, I appreciate your time on this.

That is my understanding as well. I did find that 1.8.0.3 fixes this issue. Thanks again for the prompt attention.

Hey stephen.g.jennings,

My colleague just had a thought I had the other day but failed to mention. The SHA is generated by a combination of ancestors, commit message, and files in the commit. Because of the '-n' bug (which has now been fixed) it meant that the commit message was different in your two examples. This is why it was wrong.

If you did the same tests again you should find it works fine (crossing my fingers ). But seriously, that's why it wouldn't have been working. It figures the SHA out from the push, not what's in your repository containing subtrees.

Cheers

stephen.g.jennings this is up on my list, but right now it's not a blocker so forgive me if it goes untouched for a few days. We're trying to get blockers sorted first before these high priority issues.

Thank you! The product is fantastic and I'm eager to start using the subtree support with our team, it's exactly what we've needed.

With the already existing problem the metadata isn't the same - the commit messages are different because of the '-n' issue. Perhaps that's the clue, I'd need to confirm this.

I need to do the hotfix release immediately to resolve the "-n" issue, but I want to make sure we address this issue for 1.8.1. You're completely right in what the documentation says, so we should roll with that ensuring the SHAs do match up as expected.

Cheers

git subtree push is implemented using split:

localrev=$(git subtree split --prefix="$prefix") || die
git push $repository $localrev:refs/heads/$refspec

So, it first uses split to create a synthetic history and stores the resulting commit ID in $localrev. Then it pushes this to the given repository. So, if the commits being generated aren't identical to those created by other Git versions, then I would guess the problem is probably in the split command.

Although calling split does extract a new history each time, it should be identical every time because the generated commits get their commit metadata from the commits they're splitting from. Identical metadata and identical tree = identical commit ID.

After updating Git in your development version, do you not get commit ID 329f350 if you split the test repository?

Hey stephen.g.jennings,

Thanks for the detailed information. We don't use split though, we use 'push', but the very definition of it should be equal of that of what you're suggesting as documented:

Does a 'split' (see below) using the <prefix> supplied
and then does a 'git push' to push the result to the
repository and refspec. This can be used to push your
subtree to different branches of the remote repository.

Which would mean that 'push' itself could be in error. I'd have to take a deeper look into this, but I'm assuming it's because multiple calls to 'push' always extracts a new project history. On the flipside it also says this: "Repeated splits of exactly the same history are guaranteed to be identical".

I'd have to take a further look into this to see what's going on, and what's expected based on the issued commands.

As a test, I just cloned the repository above on a different computer (a Windows machine, Git 1.8.4.0, different user.email setting), ran git subtree split, and got back commit ID 329f350, which is the same commit ID I got from my Mac when I use the system version of Git.

Hi Kieran,

Thanks for taking a look at this so quickly.

The documentation says that git-subtree split should be identical every time:

https://github.com/git/git/blob/master/contrib/subtree/git-subtree.txt#L116

If they're not identical, it causes chaos in the split-off repository. Imagine a scenario where there is a super project ("Super") which has a folder inside that you choose to split off into it's own repo ("Sub") using git-subtree.

Using Git 1.8.4.2, you split off the history of Sub and end up with three commits that you push to the Sub public repository:

A -> B -> C

Now you add another commit to Super that affects Sub. You also upgrade to Git 1.8.5. You run git subtree split again (or push, which calls split under the hood) and end up with these commits:

A' -> B' -> C' -> D'

Notice that all the commits are different. A and A' contain the same tree, but the commit message doesn't have the extra "-n" in it so the commits IDs are different. Now when you try to push this history to the Sub public repository, you get a merge conflict with no common ancestor.