3 ms·

I tend to agree. I haven't used Git in a large project, but...why would I want to rewrite history? The project is what it is. What happened, happened. If there

I tend to agree. I haven't used Git in a large project, but...why would I want to rewrite history? The project is what it is. What happened, happened. If there are a couple of weird commits, who cares? At most, maybe edit the commit messages to explain.

Kamq 3y ago
Usually it's if you committed something you shouldn't have. You still have to change api keys if you ever pushed, because things like github store orphan commits, but if you have something you can't change in there or you catch it before you push, it will at least go away eventually.
snuxoll 3y ago
Because when I am developing in my local repo I have a stream of commits that go “adding xyz because abc is being a pain”. They’re informational for me as I progress through iterating on a feature, but when I’m ready to merge I really don’t want that mess polluting the global commit history. I may also be working on multiple things in parallel and want to isolate them from each other, both to keep a cleaner history but also for code review purposes. There’s plenty of reason to use rebase, but if you’re fine letting the occasional mess slip into the history then it’s fine to NOT use it as well. The one universal case though. Rebase before you submit a patchset for review. I don’t want to fight through merge conflicts to review a change, make sure it’s applied to the current HEAD before you send it.
- kaashif 3y ago
  Rebasing to squash commits or even split commits up before/during making a PR makes sense to me and I do it all the time just to clean up my mess. The order of development and the state of the repo over time isn't faked, this is just labelling and granularity. What doesn't make sense to me is rebasing instead of merging. If master has a lot of changes and you want to pick those up, you can merge in which case history reflects reality - each commit has an actual state of the repo that you had on your machine. Or you can rebase, in which case all of the commits on your branch now contain code that no-one ever had on their machine, not tested, never run, maybe it doesn't compile, maybe it's nonsense. Both result in the same diff from master so are equivalent for submitting a patchset. It's really hard for me to see the value of trashing your history like that. People like linear history but history actually is not linear sometimes.
  - _ikke_ 3y ago
    Lots of criss-cross merges make it really difficult to follow history, making it less useful. Note that merge vs rebase a false dichotomy. After rebasing you still have to merge your branch anyway, either fast-forward or with an explicit merge commit. In the end, it's about commutating your changes effectively. The less noise there is, the better you can communicate. That takes effort from both sides, but many persons put all the burden on the receiving side.
    - gcarvalho 3y ago
      > After rebasing you still have to merge your branch anyway, either fast-forward or with an explicit merge commit You can push directly to the target branch. git push origin my-branch:master If your branch is a direct continuation of master -- which is often the desired result of rebasing -- then no merge and no force-push are necessary. (I'm not saying this is a good workflow, btw.)
      - _ikke_ 3y ago
        Which is the equivalent of a fast-forward merge. Same result, different mechanism.
goku12 3y ago
There are a few legitimate cases where you want to rewrite history. 1. Assume you are a user who is cloning the master/main branch and building it. If that branch contains your development missteps, then you are in for a world of pain. We as users always assume that the master/main Head is always buildable (excluding inadvertent mistakes). 2. If you are sending the commits as patches, then it makes sense to include a complete feature in a single patch. It will otherwise be very hard for the reviewer to make sense of any patch.
rewmie 3y ago
> I tend to agree. I haven't used Git in a large project, but...why would I want to rewrite history? There are plenty of reasons if you're doing non-trivial tasks on local branches within a team. I've mentioned a common usecases I have, which is to reorder commits I make in local branches to afterwards peel them off as stand-alone pull requests.

Kamq 3y ago

Usually it's if you committed something you shouldn't have. You still have to change api keys if you ever pushed, because things like github store orphan commits, but if you have something you can't change in there or you catch it before you push, it will at least go away eventually.

snuxoll 3y ago

Because when I am developing in my local repo I have a stream of commits that go “adding xyz because abc is being a pain”. They’re informational for me as I progress through iterating on a feature, but when I’m ready to merge I really don’t want that mess polluting the global commit history. I may also be working on multiple things in parallel and want to isolate them from each other, both to keep a cleaner history but also for code review purposes. There’s plenty of reason to use rebase, but if you’re fine letting the occasional mess slip into the history then it’s fine to NOT use it as well. The one universal case though. Rebase before you submit a patchset for review. I don’t want to fight through merge conflicts to review a change, make sure it’s applied to the current HEAD before you send it.

kaashif 3y ago
Rebasing to squash commits or even split commits up before/during making a PR makes sense to me and I do it all the time just to clean up my mess. The order of development and the state of the repo over time isn't faked, this is just labelling and granularity. What doesn't make sense to me is rebasing instead of merging. If master has a lot of changes and you want to pick those up, you can merge in which case history reflects reality - each commit has an actual state of the repo that you had on your machine. Or you can rebase, in which case all of the commits on your branch now contain code that no-one ever had on their machine, not tested, never run, maybe it doesn't compile, maybe it's nonsense. Both result in the same diff from master so are equivalent for submitting a patchset. It's really hard for me to see the value of trashing your history like that. People like linear history but history actually is not linear sometimes.
- _ikke_ 3y ago
  Lots of criss-cross merges make it really difficult to follow history, making it less useful. Note that merge vs rebase a false dichotomy. After rebasing you still have to merge your branch anyway, either fast-forward or with an explicit merge commit. In the end, it's about commutating your changes effectively. The less noise there is, the better you can communicate. That takes effort from both sides, but many persons put all the burden on the receiving side.
  - gcarvalho 3y ago
    > After rebasing you still have to merge your branch anyway, either fast-forward or with an explicit merge commit You can push directly to the target branch. git push origin my-branch:master If your branch is a direct continuation of master -- which is often the desired result of rebasing -- then no merge and no force-push are necessary. (I'm not saying this is a good workflow, btw.)
    - _ikke_ 3y ago
      Which is the equivalent of a fast-forward merge. Same result, different mechanism.

goku12 3y ago

There are a few legitimate cases where you want to rewrite history. 1. Assume you are a user who is cloning the master/main branch and building it. If that branch contains your development missteps, then you are in for a world of pain. We as users always assume that the master/main Head is always buildable (excluding inadvertent mistakes). 2. If you are sending the commits as patches, then it makes sense to include a complete feature in a single patch. It will otherwise be very hard for the reviewer to make sense of any patch.

rewmie 3y ago

> I tend to agree. I haven't used Git in a large project, but...why would I want to rewrite history? There are plenty of reasons if you're doing non-trivial tasks on local branches within a team. I've mentioned a common usecases I have, which is to reorder commits I make in local branches to afterwards peel them off as stand-alone pull requests.