7 ms·

Quite a few people are suggesting that, when it's time to share your code with others, maybe you should squash/rebase it to clean things up. That's totally up

Quite a few people are suggesting that, when it's time to share your code with others, maybe you should squash/rebase it to clean things up. That's totally up to you... but just know that not everyone thinks rebasing is a good idea. See [1], for example. [1] https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md I think we often feel the urge to rebase and squash not because it actually makes our code changes easier to understand, but because it makes us feel better about ourselves. That's a red flag. Understanding how you got to the goal -- encoding all the fumbles and disoriented thoughts right in the commit history -- that can be a genuine benefit to the reader. Who do we really help by pretending that we're more organized, coherent, and linear than we actually were?

nemetroid 6y ago
> Who do we really help by pretending that we're more organized, coherent, and linear than we actually were? We're helping the future reader who's reading the history because they want to understand why a change was made - and "because the author of the branch initially had the wrong idea" is almost never the answer they're looking for. I sometimes enjoy reading stream-of-consciousness writing, but most of the time (especially when reading code) I'm more interested in the point itself. The same applies to version history. It can be used to tell the raw story, but there's usually a more useful and interesting story to be told.
- acemarke 6y ago
  Exactly. I want to "tell a story" with my commits, and that story is really more of an idealized retelling of what I actually did. Five years from now, no one needs to know that I forgot to add that one line to a prior commit and had to add it separately, or that my first attempt didn't quite pan out as expected. What that future person _will_ care about is: - What final changes actually got made? - What task was I working on? - What was the reason for any of these changes in the first place? - Why did I make some of these changes specifically to implement that task? - What additional side info is important context for understanding the diffs?
  - SamBam 6y ago
    Exactly. It's also great to compartmentalize different aspects of your change. Often my changes are 1. Refactor the existing code to support the new feature 2. Add the new feature It's great to keep these separate, because someone can look at number 1 and see that the two versions of the code ought to be functionally the same (same tests pass, app looks the same, refactor is easy-to-understand), and look at number 2 and see the new feature. There are countless other times where you want to tell the "story" in a logical fashion. (Honestly, I expect that there is a significant correlation between being a good git committed and being a clear story-teller.)
  - gmfawcett 6y ago
    I understand that you want to tell a story. But as someone examining your code, I also want to know how you got there. While you're throwing out your junk, you're also throwing away valuable information. If I'm taking the actual time to review the code history, then let me play it out in real-time, mistakes and all. I know how to step back and summarize, I don't need you do do that for me. This is especially true if your code is clever. I'm much more likely to understand your polished gem if I can see all the things that you bumped into while you were discovering it.
    - mathstuf 6y ago
      That is what comments and commit messages are for. I trawl history all the time. Running into an unbisectable mess of a branch (because a bug that was introduced in commit X~15 is fixed in X on the same branch) is a complete nightmare. I have to discect the branch history and understand what is because of the branch and what is debugging/review/CI cycle cleanups. Commit messages for fixups also tend to be 100% terrible and utter trash. "Fix review comments". Thanks. If we're doing that, let's copy what the comment was in too and why it fixes it. The problem with your request is that 90+% of the time (with the way I develop), the dead ends are on MRs that got closed or code that never got pushed in the first place. So again, comments as to why this approach is used is way better than hiding it in the history because someone coming to "clean up" code sees the thought process instead of having to remember to search for it.
- zoomablemind 6y ago
  > We're helping the future reader who's reading the history because they want to understand why a change was made... "Change" is a subject to interpretation. Most of the time it's the scope that the change belongs to is what has the meaningful value. Say, changes made in connection to fixing an issue are logically tied for inclusion as well as for potential unwinding. Some tangent changes technically should not be casually folded in, just in case this changeset will need to be propagated or rolled back. Thus this elaborate muli-staged commit management in Git. Many projects don't have such need to manange the change flow, so Version control is used as a kind of undo buffer. Which is fine, in such cases the meaning is tied to release states. If anything, it makes more practical sense to preserve only commits with a buildable state, not just some transitional changes.
- Wowfunhappy 6y ago
  As a much newer developer, the biggest problem I have with git is that I rarely end up actually making one change at a time. I'll be working on some larger thing, and in the process I'll notice and quickly fix a smaller thing before returning to the original task. This might be a typo in a code comment, a poorly named variable, or a block of code I realize is dead. I suspect this is the type of tendency which goes away with experience, but it makes git a lot less useful. My commits won't really tell you what changed; the most they can tell you is the primary change I was working on.
  - FrancoisBosun 6y ago
    That is what OP was talking about: after you've done the change, make a commit with just that tiny refactoring. Once you're done and ready to review your work, you can cherry pick just that fix and move it to main / master / it's own PR. Since it is self-contained, it can be processed by itself only.
  - gmfawcett 6y ago
    Many of us do that, and it's not just a new developer thing. Git actually enables this, because you get to pick and choose what to add to the index (`git add`) before committing. So that little tweak you made in the unrelated function? -- no problem, just `git add` that later, and commit it under a different message. Not all SCM tools give you that kind of flexibility. On the other hand, there's a diminishing return to placing every tiny change into a separate commit. Commit messages like "Fixed multiple small things" might make some people clutch their pearls, but sometimes you just need to get shit done and move on to solving bigger problems. My suggestion is to consider breaking your commit into two: one for "fixed this big issue that everyone cares about", and one for "a bunch of tiny cleanup stuff that I happened to notice." (Maybe call that second one "refactoring" -- it will go over better with your audience.)
    - Wowfunhappy 6y ago
      > Git actually enables this, because you get to pick and choose what to add to the index (`git add`) before committing. That assumes the changes are in separate files though, right? I know you can do use the "-i" flag, but it's fairly labor intensive.
dtech 6y ago
The advantage if that you get a more usable and understandable list of historical changes. "You wouldn't publish the first draft of a book" [1] A squashed merge or rebased and cleaned set of commits gives a very clean overview of which changes where made, at what point, why they were made, and what together. That picture tends to get utterly lost in the "set up X", "make test Y", "fix typo", "wip" and "change error handling" commits a feature branch typically has. Additionally I'm not really interested in that my colleague started change X yesterday before lunch, I'm interested in when it went live and became visible for the all developers when it was merged into the main branch. [1] https://git-scm.com/book/en/v2/Git-Branching-Rebasing#_rebase_vs_merge https://git-scm.com/book/en/v2/Git-Branching-Rebasing#_rebas...
- professoretc 6y ago
  You wouldn't publish a first draft, but neither would you burn it once the final draft was off to the printer. Personally, I'd prefer it if "squashing" commits was purely a UI thing; the underlying commits were all still there, but grouped together and displayed as a single big "virtual" commit. That way you could still drill down to the real history if you needed to.
  - gmfawcett 6y ago
    The Fossil designer agrees with you: "So, another way of thinking about rebase is that it is a kind of merge that intentionally forgets some details in order to not overwhelm the weak history display mechanisms available in Git. Wouldn't it be better, less error-prone, and easier on users to enhance the history display mechanisms in Git so that rebasing for a clean, linear history became unnecessary?"
  - mikepurvis 6y ago
    I'm not a user of it myself, but I believe this is the philosophy behind how Fossil approaches it: https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md
  - ulisesrmzroche 6y ago
ChrisMarshallNY 6y ago
I have found this works a charm, if I want to present a clean repo (for things like tutorials and classes): https://24ways.org/2013/keeping-parts-of-your-codebase-private-on-github/ https://24ways.org/2013/keeping-parts-of-your-codebase-priva... But basically, I let things "all hang out." Tools shouldn't really be running the show.
deleted 6y ago
[deleted]
cesarb 6y ago
> Who do we really help by pretending that we're more organized, coherent, and linear than we actually were? You help the reviewer. To understand why git is the way it is, you have to understand the workflow of the original git-using project (other than git itself), the Linux kernel. Whenever someone proposes a change to the Linux kernel, it's sent as a sequence of patches. Each patch should contain a single logical change, and will be reviewed individually. For instance, suppose you want to change the way a field in a particular structure is stored. The first patch of your series might introduce a couple of helper functions to access the structure fields. Patches 2-5 might each change a separate subsystem to use the new helper functions, instead of accessing the field directly. The next patch changes both the field and the helper functions to use the new representation. When reviewing this sequence, it's easier to see that each patch is correct. And that was a simple example; it's not rare to have patch series with over 15 patches, and even longer patch series are not unheard of. I've seen patch series which refactor whole subsystems, where each patch in the series was an obviously correct transformation, while the final result was completely different.
aspaceman 6y ago
I think that's a pretty valid argument about just wanting to rewrite history. I'll offer an alternative. I love having every commit buildable. When I'm drafting, this isn't going to happen. I'd like to save my work and move between machines more frequently than that. But after a rebase, it's great to only have compiling commits. It makes doing a bisect a lot easier when you're hunting for something.
lamontcg 6y ago
My commit history is often a descent into profane madness.
aldanor 6y ago
> Understanding how you got to the goal -- encoding all the fumbles and disoriented thoughts right in the commit history -- that can be a genuine benefit to the reader. Disagree. Sorry, but I'd rather be rather inclined to read commit history like this: (whether it's reviewing others' code or my own at a later time) - Add functionality X to function y() - Fix a bug in y(): ... - Fix a bug in z(): ... than - X - oops - fuck, typo fix - do it another way - ok, y is fixed now - another typo fix - it has a bug, fix it - z has the same bug - typo fix Whereas the latter can be quite common during dev cycle so as to keep it to yourself. It's not about 'pretending' at all.
dahart 6y ago
From the Fossil page: > Rebasing is lying about the project history This tired hyperbole just won’t seem to ever go away. Please try to ignore this junk, the Fossil devs could and should make their point without the FUD and misleading judgement, if they want to be taken seriously. Rebase has perfectly legitimate uses, and if Fossil makes it so you don’t need to rebase, that’s fantastic. Rebase is most useful before pushing local changes to other people, and most people fluent in git know this fact, and also know that you don’t rebase public branches, you don’t rebase other people’s commits or your own after they’re pushed, except in emergencies and with team communication. Rebasing before you push is the same amount of “lying” as typing something into your editor and then deleting it before you hit save. You don’t actually want your history at the raw keystroke level, right? You aren’t “lying” if you fix a bug you wrote before you push the bug into public branches, right?

nemetroid 6y ago

> Who do we really help by pretending that we're more organized, coherent, and linear than we actually were? We're helping the future reader who's reading the history because they want to understand why a change was made - and "because the author of the branch initially had the wrong idea" is almost never the answer they're looking for. I sometimes enjoy reading stream-of-consciousness writing, but most of the time (especially when reading code) I'm more interested in the point itself. The same applies to version history. It can be used to tell the raw story, but there's usually a more useful and interesting story to be told.

acemarke 6y ago
Exactly. I want to "tell a story" with my commits, and that story is really more of an idealized retelling of what I actually did. Five years from now, no one needs to know that I forgot to add that one line to a prior commit and had to add it separately, or that my first attempt didn't quite pan out as expected. What that future person _will_ care about is: - What final changes actually got made? - What task was I working on? - What was the reason for any of these changes in the first place? - Why did I make some of these changes specifically to implement that task? - What additional side info is important context for understanding the diffs?
- SamBam 6y ago
  Exactly. It's also great to compartmentalize different aspects of your change. Often my changes are 1. Refactor the existing code to support the new feature 2. Add the new feature It's great to keep these separate, because someone can look at number 1 and see that the two versions of the code ought to be functionally the same (same tests pass, app looks the same, refactor is easy-to-understand), and look at number 2 and see the new feature. There are countless other times where you want to tell the "story" in a logical fashion. (Honestly, I expect that there is a significant correlation between being a good git committed and being a clear story-teller.)
- gmfawcett 6y ago
  I understand that you want to tell a story. But as someone examining your code, I also want to know how you got there. While you're throwing out your junk, you're also throwing away valuable information. If I'm taking the actual time to review the code history, then let me play it out in real-time, mistakes and all. I know how to step back and summarize, I don't need you do do that for me. This is especially true if your code is clever. I'm much more likely to understand your polished gem if I can see all the things that you bumped into while you were discovering it.
  - mathstuf 6y ago
    That is what comments and commit messages are for. I trawl history all the time. Running into an unbisectable mess of a branch (because a bug that was introduced in commit X~15 is fixed in X on the same branch) is a complete nightmare. I have to discect the branch history and understand what is because of the branch and what is debugging/review/CI cycle cleanups. Commit messages for fixups also tend to be 100% terrible and utter trash. "Fix review comments". Thanks. If we're doing that, let's copy what the comment was in too and why it fixes it. The problem with your request is that 90+% of the time (with the way I develop), the dead ends are on MRs that got closed or code that never got pushed in the first place. So again, comments as to why this approach is used is way better than hiding it in the history because someone coming to "clean up" code sees the thought process instead of having to remember to search for it.
zoomablemind 6y ago
> We're helping the future reader who's reading the history because they want to understand why a change was made... "Change" is a subject to interpretation. Most of the time it's the scope that the change belongs to is what has the meaningful value. Say, changes made in connection to fixing an issue are logically tied for inclusion as well as for potential unwinding. Some tangent changes technically should not be casually folded in, just in case this changeset will need to be propagated or rolled back. Thus this elaborate muli-staged commit management in Git. Many projects don't have such need to manange the change flow, so Version control is used as a kind of undo buffer. Which is fine, in such cases the meaning is tied to release states. If anything, it makes more practical sense to preserve only commits with a buildable state, not just some transitional changes.
Wowfunhappy 6y ago
As a much newer developer, the biggest problem I have with git is that I rarely end up actually making one change at a time. I'll be working on some larger thing, and in the process I'll notice and quickly fix a smaller thing before returning to the original task. This might be a typo in a code comment, a poorly named variable, or a block of code I realize is dead. I suspect this is the type of tendency which goes away with experience, but it makes git a lot less useful. My commits won't really tell you what changed; the most they can tell you is the primary change I was working on.
- FrancoisBosun 6y ago
  That is what OP was talking about: after you've done the change, make a commit with just that tiny refactoring. Once you're done and ready to review your work, you can cherry pick just that fix and move it to main / master / it's own PR. Since it is self-contained, it can be processed by itself only.
- gmfawcett 6y ago
  Many of us do that, and it's not just a new developer thing. Git actually enables this, because you get to pick and choose what to add to the index (`git add`) before committing. So that little tweak you made in the unrelated function? -- no problem, just `git add` that later, and commit it under a different message. Not all SCM tools give you that kind of flexibility. On the other hand, there's a diminishing return to placing every tiny change into a separate commit. Commit messages like "Fixed multiple small things" might make some people clutch their pearls, but sometimes you just need to get shit done and move on to solving bigger problems. My suggestion is to consider breaking your commit into two: one for "fixed this big issue that everyone cares about", and one for "a bunch of tiny cleanup stuff that I happened to notice." (Maybe call that second one "refactoring" -- it will go over better with your audience.)
  - Wowfunhappy 6y ago
    > Git actually enables this, because you get to pick and choose what to add to the index (`git add`) before committing. That assumes the changes are in separate files though, right? I know you can do use the "-i" flag, but it's fairly labor intensive.

dtech 6y ago

The advantage if that you get a more usable and understandable list of historical changes. "You wouldn't publish the first draft of a book" [1] A squashed merge or rebased and cleaned set of commits gives a very clean overview of which changes where made, at what point, why they were made, and what together. That picture tends to get utterly lost in the "set up X", "make test Y", "fix typo", "wip" and "change error handling" commits a feature branch typically has. Additionally I'm not really interested in that my colleague started change X yesterday before lunch, I'm interested in when it went live and became visible for the all developers when it was merged into the main branch. [1] https://git-scm.com/book/en/v2/Git-Branching-Rebasing#_rebase_vs_merge https://git-scm.com/book/en/v2/Git-Branching-Rebasing#_rebas...

professoretc 6y ago
You wouldn't publish a first draft, but neither would you burn it once the final draft was off to the printer. Personally, I'd prefer it if "squashing" commits was purely a UI thing; the underlying commits were all still there, but grouped together and displayed as a single big "virtual" commit. That way you could still drill down to the real history if you needed to.
- gmfawcett 6y ago
  The Fossil designer agrees with you: "So, another way of thinking about rebase is that it is a kind of merge that intentionally forgets some details in order to not overwhelm the weak history display mechanisms available in Git. Wouldn't it be better, less error-prone, and easier on users to enhance the history display mechanisms in Git so that rebasing for a clean, linear history became unnecessary?"
- mikepurvis 6y ago
  I'm not a user of it myself, but I believe this is the philosophy behind how Fossil approaches it: https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md
- ulisesrmzroche 6y ago

ChrisMarshallNY 6y ago

I have found this works a charm, if I want to present a clean repo (for things like tutorials and classes): https://24ways.org/2013/keeping-parts-of-your-codebase-private-on-github/ https://24ways.org/2013/keeping-parts-of-your-codebase-priva... But basically, I let things "all hang out." Tools shouldn't really be running the show.

deleted 6y ago

[deleted]

cesarb 6y ago

> Who do we really help by pretending that we're more organized, coherent, and linear than we actually were? You help the reviewer. To understand why git is the way it is, you have to understand the workflow of the original git-using project (other than git itself), the Linux kernel. Whenever someone proposes a change to the Linux kernel, it's sent as a sequence of patches. Each patch should contain a single logical change, and will be reviewed individually. For instance, suppose you want to change the way a field in a particular structure is stored. The first patch of your series might introduce a couple of helper functions to access the structure fields. Patches 2-5 might each change a separate subsystem to use the new helper functions, instead of accessing the field directly. The next patch changes both the field and the helper functions to use the new representation. When reviewing this sequence, it's easier to see that each patch is correct. And that was a simple example; it's not rare to have patch series with over 15 patches, and even longer patch series are not unheard of. I've seen patch series which refactor whole subsystems, where each patch in the series was an obviously correct transformation, while the final result was completely different.

aspaceman 6y ago

I think that's a pretty valid argument about just wanting to rewrite history. I'll offer an alternative. I love having every commit buildable. When I'm drafting, this isn't going to happen. I'd like to save my work and move between machines more frequently than that. But after a rebase, it's great to only have compiling commits. It makes doing a bisect a lot easier when you're hunting for something.

lamontcg 6y ago

My commit history is often a descent into profane madness.

aldanor 6y ago

> Understanding how you got to the goal -- encoding all the fumbles and disoriented thoughts right in the commit history -- that can be a genuine benefit to the reader. Disagree. Sorry, but I'd rather be rather inclined to read commit history like this: (whether it's reviewing others' code or my own at a later time) - Add functionality X to function y() - Fix a bug in y(): ... - Fix a bug in z(): ... than - X - oops - fuck, typo fix - do it another way - ok, y is fixed now - another typo fix - it has a bug, fix it - z has the same bug - typo fix Whereas the latter can be quite common during dev cycle so as to keep it to yourself. It's not about 'pretending' at all.

dahart 6y ago

From the Fossil page: > Rebasing is lying about the project history This tired hyperbole just won’t seem to ever go away. Please try to ignore this junk, the Fossil devs could and should make their point without the FUD and misleading judgement, if they want to be taken seriously. Rebase has perfectly legitimate uses, and if Fossil makes it so you don’t need to rebase, that’s fantastic. Rebase is most useful before pushing local changes to other people, and most people fluent in git know this fact, and also know that you don’t rebase public branches, you don’t rebase other people’s commits or your own after they’re pushed, except in emergencies and with team communication. Rebasing before you push is the same amount of “lying” as typing something into your editor and then deleting it before you hit save. You don’t actually want your history at the raw keystroke level, right? You aren’t “lying” if you fix a bug you wrote before you push the bug into public branches, right?