Skip to main content

Return to Answer

very trivial capitalization for a good answer
Source Link
edit approved May 8, 2017 at 3:23
aschultz
edit approved May 8, 2017 at 3:23
aschultz
  • 1.7k
  • 3
  • 23
  • 32

iI think you skipped an important detail when describing your steps. moreMore specifically, your last step, git push on dev, would have actually given you an error, as you can not normally push non-fastforward changes.

soSo you did git pull before the last push, which resulted in a merge commit with C6 and C6' as parents, which is why both will remain listed in log. aA prettier log format might have made it more obvious they are merged branches of duplicated commits.

orOr you made a git pull --rebase (or without explicit --rebase if it is implied by your config) instead, which pulled the original C5 and C6 back in your local dev (and further re-rebased the following ones to new hashes, C7' C5'' C6'').

oneOne way out of this could have been git push -f to force the push when it gave the error and wipe C5 C6 from origin, but if anyone else also had them pulled before you wiped them, you'd be in for a whole lot more trouble... basically every oneeveryone that has C5 C6 would need to do special steps to get rid of them. whichWhich is exactly why they say you should never rebase anything that's already published. it'sIt's still doable if said "publishing" is within a small team, though.

i think you skipped an important detail when describing your steps. more specifically your last step, git push on dev, would have actually given you an error, as you can not normally push non-fastforward changes.

so you did git pull before the last push, which resulted in a merge commit with C6 and C6' as parents, which is why both will remain listed in log. a prettier log format might have made it more obvious they are merged branches of duplicated commits.

or you made a git pull --rebase (or without explicit --rebase if it is implied by your config) instead, which pulled the original C5 and C6 back in your local dev (and further re-rebased the following ones to new hashes, C7' C5'' C6'').

one way out of this could have been git push -f to force the push when it gave the error and wipe C5 C6 from origin, but if anyone else also had them pulled before you wiped them, you'd be in for a whole lot more trouble... basically every one that has C5 C6 would need to do special steps to get rid of them. which is exactly why they say you should never rebase anything that's already published. it's still doable if said "publishing" is within a small team though.

I think you skipped an important detail when describing your steps. More specifically, your last step, git push on dev, would have actually given you an error, as you can not normally push non-fastforward changes.

So you did git pull before the last push, which resulted in a merge commit with C6 and C6' as parents, which is why both will remain listed in log. A prettier log format might have made it more obvious they are merged branches of duplicated commits.

Or you made a git pull --rebase (or without explicit --rebase if it is implied by your config) instead, which pulled the original C5 and C6 back in your local dev (and further re-rebased the following ones to new hashes, C7' C5'' C6'').

One way out of this could have been git push -f to force the push when it gave the error and wipe C5 C6 from origin, but if anyone else also had them pulled before you wiped them, you'd be in for a whole lot more trouble... basically everyone that has C5 C6 would need to do special steps to get rid of them. Which is exactly why they say you should never rebase anything that's already published. It's still doable if said "publishing" is within a small team, though.

Source Link
user4405677
user4405677
  • 181
  • 1
  • 2

i think you skipped an important detail when describing your steps. more specifically your last step, git push on dev, would have actually given you an error, as you can not normally push non-fastforward changes.

so you did git pull before the last push, which resulted in a merge commit with C6 and C6' as parents, which is why both will remain listed in log. a prettier log format might have made it more obvious they are merged branches of duplicated commits.

or you made a git pull --rebase (or without explicit --rebase if it is implied by your config) instead, which pulled the original C5 and C6 back in your local dev (and further re-rebased the following ones to new hashes, C7' C5'' C6'').

one way out of this could have been git push -f to force the push when it gave the error and wipe C5 C6 from origin, but if anyone else also had them pulled before you wiped them, you'd be in for a whole lot more trouble... basically every one that has C5 C6 would need to do special steps to get rid of them. which is exactly why they say you should never rebase anything that's already published. it's still doable if said "publishing" is within a small team though.