7 ms·

If you always rebase, aren't you hiding even more of the history than if you have unlabeled branches? I have to admit I've never understood the point of keepin

If you always rebase, aren't you hiding even more of the history than if you have unlabeled branches? I have to admit I've never understood the point of keeping the history linear.

jolux 5y ago
I find it easier to read linear history.
- brigandish 5y ago
  Could that be because if the history isn’t linear then it’s difficult to read, precisely because of the reasons given above, which would mean you have the same problem but you’ve simply decided to avoid it via a (legitimate) workaround and not complain. That wouldn’t make the complaint invalid though.
  - jolux 5y ago
    I have to admit I don't fully understand the problem as originally formulated. I've never had trouble figuring out what's going on in a Git repository. I do agree that GitHub's interface for these things is anemic. As for that part, I typically squash-merge on GitHub and that links to the PR, which is good enough for me.
- kazinator 5y ago
  And that goes for this Fossil too. When I look at the SQLite timeline, I see confusing swimlanes. I can't make heads or tails out of some of it.
kazinator 5y ago
You're also hiding history if you repeatedly edit the code while you're debugging it, and sometimes undo 17 changes and re-do them differently in your edit buffer and such. A True Scotsmans non-history-destroying version control system would reveal and be able to replay every single editing keystroke that went into a change.
- Spivak 5y ago
  I think you're misunderstanding what's meant by history. I don't care at all about your local history while working on a feature. I care about what code existed where and when in multi-branch workflows and making sure merges are easy to follow when integrating changes from multiple long-lived branches. If your workflow is single branch all PRs merge into main then of course you want to rebase since the only thing that matters to your history is "when did this batch of changes land in main"
- Dylan16807 5y ago
  I mean, it would be good to keep that locally too. But that's all local stuff. It doesn't matter if you delete something nobody else ever saw. Branches are very often passed around to other people, examined and validated in that form. Rebasing a public branch loses some amount of important history. And even for private branches, if you rebase multiple commits at once then the testing you did between those commits gets invalidated.
  - thayne 5y ago
    Does fossil have a way to rebase or ammend commits on a local branch though? My understanding is it doesn't.
    - SQLite 5y ago
      Fossil does not have a "rebase" command, but anything you can do with rebase you can do in Fossil, and more. Fossil allows you (for example) to fix typos in the commit messages of published branches, safely and in a way that does not destroy history and propagates cleanly with "sync". It allows you to modify the DAG safely, and in a way that does not destroy history and propagates cleanly. It does this by providing special tags that when added to a commit change the check-in comment, or branch name, or parents of the commit. The original immutable check-in is preserved, but for display purposes, the tags can override some properties of the original check-in. Real example from just this morning: Last last night I mistakenly merged the wrong way. I merged the reuse-schema branch into trunk, rather than merging trunk into the reuse-schema branch. When I saw the problem this morning, I was able to fix it, even though this mistake had already propagated to other repositories. The change entered the DAG as a supplemental "correction" tag, so no history was lost, and if in 20 years somebody wants to go back and figure out what happened there, they can, because all information is preserved. But for day-to-day viewing of history, it looks as if I had done the merge correctly to begin with.
dahart 5y ago
> I have to admit I’ve never understood the point of keeping the history linear. Bisect, blame, and log, among other features, are all easier to use with a linear history. They’re not unusable with non-linear / many branches, just easier linear. I’m not quite sure I understand your comment though - it implies that you consider linear history to be a strange and/or non-default thing to do. What’s the implied point of not keeping the history linear, or what is your preferred workflow? I’m not entirely sure what’s being compared, but linear is the default you get from more than 1 commit. Linear is very natural with a team of one or only a very small number of people. Linear is a lot nicer than branchy for branches that have exactly 1 commit.
- elsjaako 5y ago
  Ok, that makes sense. > I’m not quite sure I understand your comment though - it implies that you consider linear history to be a strange and/or non-default thing to do. Sometimes you get a branch, I get them even on personal projects if I forget to push and work on a different computer. I've heard people say that, when they do get a branch, they will rebase to make the history linear instead of having a merge. I don't think that is default.

If you always rebase, aren't you hiding even more of the history than if you have unlabeled branches? I have to admit I've never understood the point of keeping the history linear.

jolux 5y ago

I find it easier to read linear history.

brigandish 5y ago
Could that be because if the history isn’t linear then it’s difficult to read, precisely because of the reasons given above, which would mean you have the same problem but you’ve simply decided to avoid it via a (legitimate) workaround and not complain. That wouldn’t make the complaint invalid though.
- jolux 5y ago
  I have to admit I don't fully understand the problem as originally formulated. I've never had trouble figuring out what's going on in a Git repository. I do agree that GitHub's interface for these things is anemic. As for that part, I typically squash-merge on GitHub and that links to the PR, which is good enough for me.
kazinator 5y ago
And that goes for this Fossil too. When I look at the SQLite timeline, I see confusing swimlanes. I can't make heads or tails out of some of it.

kazinator 5y ago

You're also hiding history if you repeatedly edit the code while you're debugging it, and sometimes undo 17 changes and re-do them differently in your edit buffer and such. A True Scotsmans non-history-destroying version control system would reveal and be able to replay every single editing keystroke that went into a change.

Spivak 5y ago
I think you're misunderstanding what's meant by history. I don't care at all about your local history while working on a feature. I care about what code existed where and when in multi-branch workflows and making sure merges are easy to follow when integrating changes from multiple long-lived branches. If your workflow is single branch all PRs merge into main then of course you want to rebase since the only thing that matters to your history is "when did this batch of changes land in main"
Dylan16807 5y ago
I mean, it would be good to keep that locally too. But that's all local stuff. It doesn't matter if you delete something nobody else ever saw. Branches are very often passed around to other people, examined and validated in that form. Rebasing a public branch loses some amount of important history. And even for private branches, if you rebase multiple commits at once then the testing you did between those commits gets invalidated.
- thayne 5y ago
  Does fossil have a way to rebase or ammend commits on a local branch though? My understanding is it doesn't.
  - SQLite 5y ago
    Fossil does not have a "rebase" command, but anything you can do with rebase you can do in Fossil, and more. Fossil allows you (for example) to fix typos in the commit messages of published branches, safely and in a way that does not destroy history and propagates cleanly with "sync". It allows you to modify the DAG safely, and in a way that does not destroy history and propagates cleanly. It does this by providing special tags that when added to a commit change the check-in comment, or branch name, or parents of the commit. The original immutable check-in is preserved, but for display purposes, the tags can override some properties of the original check-in. Real example from just this morning: Last last night I mistakenly merged the wrong way. I merged the reuse-schema branch into trunk, rather than merging trunk into the reuse-schema branch. When I saw the problem this morning, I was able to fix it, even though this mistake had already propagated to other repositories. The change entered the DAG as a supplemental "correction" tag, so no history was lost, and if in 20 years somebody wants to go back and figure out what happened there, they can, because all information is preserved. But for day-to-day viewing of history, it looks as if I had done the merge correctly to begin with.

dahart 5y ago

> I have to admit I’ve never understood the point of keeping the history linear. Bisect, blame, and log, among other features, are all easier to use with a linear history. They’re not unusable with non-linear / many branches, just easier linear. I’m not quite sure I understand your comment though - it implies that you consider linear history to be a strange and/or non-default thing to do. What’s the implied point of not keeping the history linear, or what is your preferred workflow? I’m not entirely sure what’s being compared, but linear is the default you get from more than 1 commit. Linear is very natural with a team of one or only a very small number of people. Linear is a lot nicer than branchy for branches that have exactly 1 commit.

elsjaako 5y ago
Ok, that makes sense. > I’m not quite sure I understand your comment though - it implies that you consider linear history to be a strange and/or non-default thing to do. Sometimes you get a branch, I get them even on personal projects if I forget to push and work on a different computer. I've heard people say that, when they do get a branch, they will rebase to make the history linear instead of having a merge. I don't think that is default.