Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ee4j-build] git question
Tom Jenkinson wrote on 12/ 7/18 02:34 AM:


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)
Yes, they're two completely different commits that happen to make exactly the same change.  How does git "make them the same"?  Does it throw away one of them because it does the same change as the other one?  Does it create a new commit that replaces the two existing commits?

Surely there must be a description of how this works somewhere in the git documentation, right?...  :-)  (Although too much of the git documentation is written for the people who implemented git, not the people who use it, and thus is impenetrable.)

I guess the bottom line here is that if people would stop making the same change to both master and EE4J_8, we wouldn't have this problem, right?  Why isn't everyone just making the changes to EE4J_8 and then merging or rebasing that on master?

Back to the top