5 ms·

No/manual rebase sounds awful

by jjirsa 10y ago

BeetleB 10y ago
Genuinely curious: Why do you need rebasing? I'm mostly a mercurial person, where doing a rebase is highly discouraged and nontrivial. After all these years on mercurial, I've never found a need to do it. Why is it so popular amongst git users?
- spraak 10y ago
  Usually as a way to ensure a working branch stays up to date with master/another branch, so there aren't merge conflicts. Or if there are merge conflicts, to resolve them.
- jdmichal 10y ago
  Rebasing gives you a linear history instead of the diamonds non-rebased branching and merging gives you. I mean, that's the technical reason, anyway.
  - BeetleB 10y ago
    But that's what I'm trying to understand: The branched history was never a problem for me (although I do use a GUI for it).
    - __david__ 10y ago
      For me I dislike branched history because each merge point can (accidentally) have extra non-merge code added and therefore should technically be code-reviewed, too. Git doesn't like showing merge commit diffs (even with `git log -p`) and so it's not easy to see how someone resolved their merge conflicts. I don't find that diamond branch development technique adds much in the way of useful information, so I tend to try to keep it linear.
- iso-8859-1 10y ago
  If you like a readable commit history, rebase is useful to reorder and squash unnecessary commits. Some repositories, like Rails have a lot of merge commits. Why should I have to read through them? Also, all kinds of failed tests may have been developed in a feature-branch during month-long development. Interactive rebasing lets you avoid that mess, I don't think it is that complicated. Mercurial uses the same underlying data structures, so I don't understand how rebasing can be more complicated on Mercurial than Git.
  - detaro 10y ago
    > I don't understand how rebasing can be more complicated on Mercurial than Git. It's more complicated in the sense that there isn't a nice command for it. You still can do it by doing multiple lower-level steps, or installing an extension that makes it nicer.
    - Siecje 10y ago
      You have to enable the rebase extension (comes with Mercurial) and it is just `hg rebase -s src -d dst`
  - BeetleB 10y ago
    So let's say I branched off of master 3 months ago, and slowly developed the feature. Now if I rebase, will the commit history show all my local commits at the time they occurred (i.e. spread across 3 months)? Or will it show up as a single commit at the end? As for "reading through them", I usually use a GUI that shows the commit history, and it will show all the commits in a branch in, well, a branch. I can easily ignore them.
    - jdmichal 10y ago
      Git actually maintains the following: Author and AuthorDate: These will not change during a rebase. Unless maybe you do an interactive rebase and edit the commit... I'm not 100% sure how those interact. Commit and CommitDate: These will change during a rebase, as a rebase is recreating the commit and that will be done with the current user and date.
- codyps 10y ago
  I end up using it when fixing up local changes which had broken due to upstream modifications. It's generally not seen as very good to send things upstream that conflict with existing changes, and including merges (from master, primarily) in upstream submissions is frowned upon. When I was using mercurial, I ended up using the mq extension [1] to provide a similar work flow. I actually prefer mq's work flow to rebasing in git (simplifies some things when maintaining a set of changes), but the programs like that for git are lacking (I've tried guilt and quilt).
  - BeetleB 10y ago
    I used mq, and really liked it when I used it. Admittedly do not use it much any more (too lazy to do the extra typing).
- amluto 10y ago
  I use git rebase -i as a way to develop. If I make a series of changes and the middle one doesn't compile or I want to restructure things, I'll use git rebase -i. The outcome is a set of patches that a suitable to send out for review. hq's mq extension can do the same thing with a prettier UI but IMO much worse functionality.
  - BeetleB 10y ago
    Interesting: For the short time I used mq, I was quite impressed with the functionality - but did not use a GUI and eventually stopped using it because of the overhead in typing.
- vonuebelgarten 10y ago
  >Genuinely curious: Why do you need rebasing? Mostly to sort the code out before publication. People usually assume rebase as a tool for integration but forget how useful it is in the "local" development stage (ie. before pushing the code for the team). Also, rewriting history (in the good sense of the term). Git have some awesome approaches for minimizing the amount of semantically irrelevant commits in the repository (or plain garbage commits) that other VCSs lack. Mostly the possibility of having local branches (keeping them hidden away from everyone may be a plus in some cases) were a developer safely store that horrible-looking code everybody says they never write, go back, test, fix the code up, add test cases, fix indentation, documentation, etc. all in different commits and, then, rebase or squash-merge them in a self-contained, well-described and semantically split set of commits and then push them to the public repository in a way other team members can follow and understand. For git, history is a tool for documenting the project -- and I love it.
- jjirsa 10y ago
  I regularly need to apply patches written months/years ago to a branch that's changed many many times (maybe a thousand) - for example, patch written at a specific point in time spends 2 months being reviewed, and by that time it no longer cleanly applies to trunk. Rebase may let me replay all of the other changes on top and save me lots of manual effort to get the patch so that it applies cleanly to trunk
sigzero 10y ago
From the git vs fossil faq: "Because of its emphasis on recording history exactly as it happened, rather than as we would have liked it to happen, Fossil deliberately does not provide a "rebase" command. One can rebase manually in Fossil, with sufficient perserverence, but it not something that can be done with a single command." https://www.fossil-scm.org/xfer/doc/trunk/www/fossil-v-git.wiki https://www.fossil-scm.org/xfer/doc/trunk/www/fossil-v-git.w...
rbehrends 10y ago
1. Fossil is designed around having auditable history. 2. Fossil can change meta-information (commit messages, tags, branch names) after the fact. Those changes also leave an audit trail. 3. Fossil has features that handle certain use cases for rebasing (private branches, fossil stash snapshot, etc.). If you absolutely need to, fossil purge can be used to edit local history and the shun mechanism can be used to (e.g.) extirpate sensitive information that was shared by accident. 4. Extensive use of rebasing to produce a linear history is a Git-ism , largely due the fact that in Git, history is a soup of anonymous commit objects that is difficult to visualize. Other version control systems that allow you to label and structure history have less need for this.

No/manual rebase sounds awful

by jjirsa 10y ago

No/manual rebase sounds awful

Genuinely curious: Why do you need rebasing? I'm mostly a mercurial person, where doing a rebase is highly discouraged and nontrivial. After all these years on mercurial, I've never found a need to do it. Why is it so popular amongst git users?

spraak 10y ago
Usually as a way to ensure a working branch stays up to date with master/another branch, so there aren't merge conflicts. Or if there are merge conflicts, to resolve them.
jdmichal 10y ago
Rebasing gives you a linear history instead of the diamonds non-rebased branching and merging gives you. I mean, that's the technical reason, anyway.
- BeetleB 10y ago
  But that's what I'm trying to understand: The branched history was never a problem for me (although I do use a GUI for it).
  - __david__ 10y ago
    For me I dislike branched history because each merge point can (accidentally) have extra non-merge code added and therefore should technically be code-reviewed, too. Git doesn't like showing merge commit diffs (even with `git log -p`) and so it's not easy to see how someone resolved their merge conflicts. I don't find that diamond branch development technique adds much in the way of useful information, so I tend to try to keep it linear.
iso-8859-1 10y ago
If you like a readable commit history, rebase is useful to reorder and squash unnecessary commits. Some repositories, like Rails have a lot of merge commits. Why should I have to read through them? Also, all kinds of failed tests may have been developed in a feature-branch during month-long development. Interactive rebasing lets you avoid that mess, I don't think it is that complicated. Mercurial uses the same underlying data structures, so I don't understand how rebasing can be more complicated on Mercurial than Git.
- detaro 10y ago
  > I don't understand how rebasing can be more complicated on Mercurial than Git. It's more complicated in the sense that there isn't a nice command for it. You still can do it by doing multiple lower-level steps, or installing an extension that makes it nicer.
  - Siecje 10y ago
    You have to enable the rebase extension (comes with Mercurial) and it is just `hg rebase -s src -d dst`
- BeetleB 10y ago
  So let's say I branched off of master 3 months ago, and slowly developed the feature. Now if I rebase, will the commit history show all my local commits at the time they occurred (i.e. spread across 3 months)? Or will it show up as a single commit at the end? As for "reading through them", I usually use a GUI that shows the commit history, and it will show all the commits in a branch in, well, a branch. I can easily ignore them.
  - jdmichal 10y ago
    Git actually maintains the following: Author and AuthorDate: These will not change during a rebase. Unless maybe you do an interactive rebase and edit the commit... I'm not 100% sure how those interact. Commit and CommitDate: These will change during a rebase, as a rebase is recreating the commit and that will be done with the current user and date.
codyps 10y ago
I end up using it when fixing up local changes which had broken due to upstream modifications. It's generally not seen as very good to send things upstream that conflict with existing changes, and including merges (from master, primarily) in upstream submissions is frowned upon. When I was using mercurial, I ended up using the mq extension [1] to provide a similar work flow. I actually prefer mq's work flow to rebasing in git (simplifies some things when maintaining a set of changes), but the programs like that for git are lacking (I've tried guilt and quilt).
- BeetleB 10y ago
  I used mq, and really liked it when I used it. Admittedly do not use it much any more (too lazy to do the extra typing).
amluto 10y ago
I use git rebase -i as a way to develop. If I make a series of changes and the middle one doesn't compile or I want to restructure things, I'll use git rebase -i. The outcome is a set of patches that a suitable to send out for review. hq's mq extension can do the same thing with a prettier UI but IMO much worse functionality.
- BeetleB 10y ago
  Interesting: For the short time I used mq, I was quite impressed with the functionality - but did not use a GUI and eventually stopped using it because of the overhead in typing.
vonuebelgarten 10y ago
>Genuinely curious: Why do you need rebasing? Mostly to sort the code out before publication. People usually assume rebase as a tool for integration but forget how useful it is in the "local" development stage (ie. before pushing the code for the team). Also, rewriting history (in the good sense of the term). Git have some awesome approaches for minimizing the amount of semantically irrelevant commits in the repository (or plain garbage commits) that other VCSs lack. Mostly the possibility of having local branches (keeping them hidden away from everyone may be a plus in some cases) were a developer safely store that horrible-looking code everybody says they never write, go back, test, fix the code up, add test cases, fix indentation, documentation, etc. all in different commits and, then, rebase or squash-merge them in a self-contained, well-described and semantically split set of commits and then push them to the public repository in a way other team members can follow and understand. For git, history is a tool for documenting the project -- and I love it.
jjirsa 10y ago
I regularly need to apply patches written months/years ago to a branch that's changed many many times (maybe a thousand) - for example, patch written at a specific point in time spends 2 months being reviewed, and by that time it no longer cleanly applies to trunk. Rebase may let me replay all of the other changes on top and save me lots of manual effort to get the patch so that it applies cleanly to trunk

sigzero 10y ago

From the git vs fossil faq: "Because of its emphasis on recording history exactly as it happened, rather than as we would have liked it to happen, Fossil deliberately does not provide a "rebase" command. One can rebase manually in Fossil, with sufficient perserverence, but it not something that can be done with a single command." https://www.fossil-scm.org/xfer/doc/trunk/www/fossil-v-git.wiki https://www.fossil-scm.org/xfer/doc/trunk/www/fossil-v-git.w...

rbehrends 10y ago

1. Fossil is designed around having auditable history. 2. Fossil can change meta-information (commit messages, tags, branch names) after the fact. Those changes also leave an audit trail. 3. Fossil has features that handle certain use cases for rebasing (private branches, fossil stash snapshot, etc.). If you absolutely need to, fossil purge can be used to edit local history and the shun mechanism can be used to (e.g.) extirpate sensitive information that was shared by accident. 4. Extensive use of rebasing to produce a linear history is a Git-ism , largely due the fact that in Git, history is a soup of anonymous commit objects that is difficult to visualize. Other version control systems that allow you to label and structure history have less need for this.