Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ee4j-build] git question


On Thu, 6 Dec 2018 at 22:14, Bill Shannon <bill.shannon@xxxxxxxxxx> wrote:
Tom Jenkinson wrote on 12/6/18 1:49 PM:


On Thu, 6 Dec 2018 at 18:54, Bill Shannon <bill.shannon@xxxxxxxxxx> wrote:
Tom Jenkinson wrote on 12/6/18 3:38 AM:
As soon as a commit in your tree does not have identical SHA to what is in the main repo it won't push cleanly.
I don't understand.  How are two commits considered to be "the same" if not by their SHA?

If there's a commit in my repo that's not in the remote, and there's a commit in the remote, that's not in my repo, I understand.  But if I do a "pull -r", how can there be a commit in the remote that I don't have?  Doesn't "pull -r" pull down everything from the remote and add my stuff on top of it, without changing what it pulled down?


I tried to simulate it a bit with creating two branches using your current master and then on one of the branches doing a "git commit --amend --no-edit" so although they are both functionally identical both branches have a different SHA for the head commit.
"commit --amend" is effectively the same as completely removing that commit and replacing it with a new commit, right?

I understand how that would get things out of sync, but I wasn't doing that.


git diff test2 (my second branch) - shows no differences

but if I do "git rebase test2" it changes the branch I am on to use the SHA from the test2 branch. History looks clean still but it can't be clean pushed.

If I do "git merge test2" instead, it can be pushed but history does not look nice.

Here are the branches:
My simulation of your master: https://github.com/tomjenkinson/javamail/commits/test (originally exactly like your master - but now the result of running git merge test2)
My simulation of your EE4J_8 branch: https://github.com/tomjenkinson/javamail/commits/test2 (note the SHA is different on the commit "Support building mbox native code on Linux; fix building on JDK 9." - like your commits in EE4J_8 branch have different SHA

There reason they all have different SHA is because the second two commits are in a different order. If master was going to have exactly the same commits in the exact same order you could have done "git rebase EE4J_8" each time and it should have pulled in the lastest commits without changing their SHAs. In practice I don't see how that would have been possible over time as at some point they would diverge.

Whenever I try to sync two branches I cherry-pick commits from the branch that is ahead onto the other branch. That means that history is not re-written on the branch I am cherry-picking to and so I don't need to force push.
So you're saying that rebase might rewrite commits on the main branch, not just add commits from the other branch?  Ouch!

How does it know which commits to rewrite?
From what I know, it will rewrite anything that is different, because you diverged after beab9265aa39a4c3c4a2e220b1e4c198060803a5 then anything after that would be changed.
I don't understand what you mean by "anything after that would be changed".

Yes, the EE4J_8 branch forked from the master after the first commit to the master.


If you do "git rebase EE4J_8" on master it will be made to look like the EE4J_8 branch where the commits are the same.
I don't understand "made to look like".

I think this is the crucial thing, these two commits are not the same:
When you do a rebase, then git will try to make them the same (and in your case it is able to do that)



Doesn't rebase just redo the changes from the branch commits and apply them to the code on the master, adding new commits to the end of master?

If you do it twice in a row it won't touch them the next time. That said, if you add more commits to your EE4J_8 branch and rebase master with them you will be back needing to force push because "Support building mbox native code on Linux; fix building on JDK 9" for instance will be re-written and get a new SHA (because it does not occur in the EE4J_8 branch).
After rebasing EE4J_8 onto master, I planned to delete the EE4J_8 branch since it was no longer needed.  (I just haven't gotten around to doing that yet.)


If it helps, the parent commit seems to have an influence on the SHA of a commit, a functionally equivalent commit with a different parent gets a different SHA. For example:
At time 1 let the following commits exist in master: 1,2,3,5 (the numbers are SHAs)
At time 1 let the following commits exist in EE4J_8: 1,2,3,4
Then at time 2, say you want to "git rebase EE4J_8 "(on master), master ends up with the following commits: 1,2,3,4,6 (6 used to be 5, but it is not able to be 5 anymore because the SHA of 5 was calculated with a parent of 3, but after the rebase it now has a parent of 4)
So rebase is inserting the branch commits before the existing commits on the master, instead of after?  How does it know to insert 4 before 5 and then change 5 to 6, instead of adding 4 after 5 to create a new commit?

If rebasing the branch ont master is changing the local master, why doesn't a subsequent "pull -r" from the remote (with no intervening changes to the remote) also change the local master?

Back to the top