Re: [ee4j-build] git question

[Bill Shannon <bill.shannon@xxxxxxxxxx>]

Tom Jenkinson wrote on 12/5/18 10:38 AM:

Hi Bill,

With Javamail repo, when you rebase its master on its EE4J_8 branch some of its commits on master have to be altered by git. These commits are the ones that are either not in the EE4J_8 branch at all and commits where they do not have identical SHAs to those in both branches). These commits get a new SHA and even if only a single commit has a different SHA you can't just "git push" anymore.

You can see the commit histories are different if you look at the bottom 3 commits in https://github.com/eclipse-ee4j/javamail/commits/master and https://github.com/eclipse-ee4j/javamail/commits/EE4J_8. Although the first commit is identical the following two commits are then in a different order and have different SHAs between the two branches.

Ya, that's because someone applied the same changes to both master and EE4J_8 separately.

The same principal can be seen if you do the following:

git reset --hard origin/master
git log -1 # look at the sha
git push
git commit --amend --no-edit
git log -1 # look at the sha now, you will see it is different even if the content of the commit appears identical
git push # this won't work because the commit history is different

This might not have been practical for your case, but generally if the commits had been in master first and then you had been able to rebased the EE4J_8 branch on master (or cherry-picked some commit) you would still have been able to "git push" to EE4J_8 branch because the SHAs would have already been pushed would not need to have been changed (unless you had added commits to EE4J_8 branch that were not on master, then you would be in the same position).

Does that help?

I still must be thinking about rebase wrong...

I think what I had was something like this:

A--B--C   (master)
  \
    D--E--F--G--H  (EE4J_8)

Commits B and E made the same change, and commits C and D made the same change.

When I rebase EE4J_8 on master I expected it to apply commits D and E and realize that they were redundant with commits B and C, and thus they didn't actually change anything, but they would still show up as commits.

I expected to end up with:

A--B--C--D'--E'--F'--G'--H'  (master)
  \
    D--E--F--G--H  (EE4J_8)

It seems like I should be able to push that since it's a superset of what's in the remote master.

Apparently D and E didn't actually get applied so I ended up with something like:

A--B--C--F'--G'--H'  (master)
  \
    D--E--F--G--H  (EE4J_8)

Which still seems like something that I should be able to push.

What do you think I actually ended up with when I did the rebase?

And what did the "pull -r" change that into that allowed me to push?



And more importantly, what's the right way to rebase a branch onto master such that I can always push the master?

Do I always have to do a merge instead of a rebase to make this work?