3 ms·

Much more than that. `git push -f` and `git rebase -i` are essential tools to keep a history where every commit passes CI. And that is very important for `git b

by sjrd 11y ago

Much more than that. `git push -f` and `git rebase -i` are essential tools to keep a history where every commit passes CI. And that is very important for `git bisect`ing things later. They are also necessary to keep a history where `git blame` can be used effectively.

brianwawok 11y ago
Rebasing shared branches is pretty nasty. Do people really keep a policy of "every branch must pass CI" ? I like rebase on my branches so I merge as a single commit at the head of the branch I am merging into, but rebasing a shared branch is total ick. As for needing every branch to pass CI forever to use git bisect.. that seems a bit extreme. I think I have used git bisect like 3 times in the past 5 years? And each time I wrote a very simple unit test and fed it into git bisect and was able to figure it out without a problem. If you are using git bisect constantly I guess I can see, but that has another smell. Who cares when it was broke, just fix the broke thing!!
- mmanfrin 11y ago
  On shared branches, I think the rules are different. Rebasing a shared branch is very sticky. But for single-dev branches, I think rebasing/forcing is fine -- do what you want until it enters the main stream.
  - brianwawok 11y ago
    Sure but I think OP was advocating rebasing a shared branch so that git bisect would always pass on each commit
    - setpatchaddress 11y ago
      git -f on a shared branch is a surefire way to lose commits. OMFG. It's better not to allow it at all. git revert will undo damage adequately, just not cleanly.
      - brianwawok 11y ago
        You usually won't lose commits with reflog, especially the more users of a repo the more reflogs.. but yes a disaster to go find them again...
- peteretep 11y ago
  As long as you can communicate the change to other branch users, I don't see the problem?

3 ms·

Much more than that. `git push -f` and `git rebase -i` are essential tools to keep a history where every commit passes CI. And that is very important for `git b

by sjrd 11y ago

brianwawok 11y ago
Rebasing shared branches is pretty nasty. Do people really keep a policy of "every branch must pass CI" ? I like rebase on my branches so I merge as a single commit at the head of the branch I am merging into, but rebasing a shared branch is total ick. As for needing every branch to pass CI forever to use git bisect.. that seems a bit extreme. I think I have used git bisect like 3 times in the past 5 years? And each time I wrote a very simple unit test and fed it into git bisect and was able to figure it out without a problem. If you are using git bisect constantly I guess I can see, but that has another smell. Who cares when it was broke, just fix the broke thing!!
- mmanfrin 11y ago
  On shared branches, I think the rules are different. Rebasing a shared branch is very sticky. But for single-dev branches, I think rebasing/forcing is fine -- do what you want until it enters the main stream.
  - brianwawok 11y ago
    Sure but I think OP was advocating rebasing a shared branch so that git bisect would always pass on each commit
    - setpatchaddress 11y ago
      git -f on a shared branch is a surefire way to lose commits. OMFG. It's better not to allow it at all. git revert will undo damage adequately, just not cleanly.
      - brianwawok 11y ago
        You usually won't lose commits with reflog, especially the more users of a repo the more reflogs.. but yes a disaster to go find them again...
- peteretep 11y ago
  As long as you can communicate the change to other branch users, I don't see the problem?