3 ms·

Couldn't you rewrite history locally on your own branch and nobody would know?

by peteradio 4y ago

prettyStandard 4y ago
Yeah... You should never rewrite history of shared branches. You are just asking for trouble in that case.
danpalmer 4y ago
We informally allowed whatever you wanted until you opened a pull request.
chrisfinazzo 4y ago
Hard agree. Do whatever the heck you want locally, just try not to screw everybody else up when you push. (From the guy who force-pushed on a personal project yesterday to resolve a situation with multiple remote heads - I am ashamed)
opsy_ 4y ago
Sure, unless you bork your local repo enough you need help from a teammate getting your work into a PR. Not to say that doesn't make for a good learning moment.
- OkayPhysicist 4y ago
  At some point, every junior is going to mangle something, and need a senior to sit them down and give them the git reflog talk. It's an inevitability, and should be embraced as a natural part of the evolution of a developer.
  - prettyStandard 4y ago
    Haha. what's the git reflog talk? To be clear I know what reflog is, but what's "the talk"?
    - olddustytrail 4y ago
      Probably just making them aware of it. But I can give a slightly longer spiel: Commits in git are immutable. They're identified by their hash, so they have to be. What's more they have the hash of the previous commits so the whole chain back to the first commit can't be changed. You can only add new chains. As a consequence, if your main branch points to commit abc123 and your feature branch points to commit def456 then it doesn't matter if you merge, cherry pick, rebase or dance the fandango, if you point those branches back to those commits, the branches must by necessity look identical to the way they looked before you did anything. And you can find out where they used to point in the reflog.
      - chrisfinazzo 4y ago
        I'm certainly aware of reflog and have (thankfully) only had occasion to use it once or twice that I can remember. To my original comment - having to force-push in order to resolve heads - is there a "correct" way to do this that doesn't feel gross?
        Dylan16807 4y ago
        You're going to have to explain your problem in more detail than "resolve a situation with multiple remote heads".
        chrisfinazzo 4y ago
        To explain, I'll borrow the solution that I first saw in a Fog Creek presentation from ages ago ("DVCS University")... Essentially, if you have more than one person making changes to the same piece of code, the method for resolving them is: 1) Pull - gets their changes 2) Merge - puts their changes together with yours and you can reorganize them at that point. Note, this was done with Mercurial which doesn't have the concept of a stage, so Pull feels like it has a slightly different meaning when you look at it that way. One [suggestion][1] for Git if you want to achieve the same effect - getting a Fast-Forward at the end - is to Rebase, then Merge last. Part of me knew this, I simply forgot and wanted to get out of this particular hole. [suggestion]: https://www.atlassian.com/git/tutorials/rewriting-history/git-rebase https://www.atlassian.com/git/tutorials/rewriting-history/gi...

Couldn't you rewrite history locally on your own branch and nobody would know?

prettyStandard 4y ago

Yeah... You should never rewrite history of shared branches. You are just asking for trouble in that case.

danpalmer 4y ago

We informally allowed whatever you wanted until you opened a pull request.

chrisfinazzo 4y ago

Hard agree. Do whatever the heck you want locally, just try not to screw everybody else up when you push. (From the guy who force-pushed on a personal project yesterday to resolve a situation with multiple remote heads - I am ashamed)

opsy_ 4y ago

Sure, unless you bork your local repo enough you need help from a teammate getting your work into a PR. Not to say that doesn't make for a good learning moment.

OkayPhysicist 4y ago
At some point, every junior is going to mangle something, and need a senior to sit them down and give them the git reflog talk. It's an inevitability, and should be embraced as a natural part of the evolution of a developer.
- prettyStandard 4y ago
  Haha. what's the git reflog talk? To be clear I know what reflog is, but what's "the talk"?
  - olddustytrail 4y ago
    Probably just making them aware of it. But I can give a slightly longer spiel: Commits in git are immutable. They're identified by their hash, so they have to be. What's more they have the hash of the previous commits so the whole chain back to the first commit can't be changed. You can only add new chains. As a consequence, if your main branch points to commit abc123 and your feature branch points to commit def456 then it doesn't matter if you merge, cherry pick, rebase or dance the fandango, if you point those branches back to those commits, the branches must by necessity look identical to the way they looked before you did anything. And you can find out where they used to point in the reflog.
    - chrisfinazzo 4y ago
      I'm certainly aware of reflog and have (thankfully) only had occasion to use it once or twice that I can remember. To my original comment - having to force-push in order to resolve heads - is there a "correct" way to do this that doesn't feel gross?
      - Dylan16807 4y ago
        You're going to have to explain your problem in more detail than "resolve a situation with multiple remote heads".
        chrisfinazzo 4y ago
        To explain, I'll borrow the solution that I first saw in a Fog Creek presentation from ages ago ("DVCS University")... Essentially, if you have more than one person making changes to the same piece of code, the method for resolving them is: 1) Pull - gets their changes 2) Merge - puts their changes together with yours and you can reorganize them at that point. Note, this was done with Mercurial which doesn't have the concept of a stage, so Pull feels like it has a slightly different meaning when you look at it that way. One [suggestion][1] for Git if you want to achieve the same effect - getting a Fast-Forward at the end - is to Rebase, then Merge last. Part of me knew this, I simply forgot and wanted to get out of this particular hole. [suggestion]: https://www.atlassian.com/git/tutorials/rewriting-history/git-rebase https://www.atlassian.com/git/tutorials/rewriting-history/gi...