Tom Jenkinson wrote on 12/6/18 1:49 PM:
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:
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".
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?
|
