6 ms·

The moralising about it doesn't make much sense. In other professions, it's not "lying" or "dishonorable" to present your work in the most clear and understanda

The moralising about it doesn't make much sense. In other professions, it's not "lying" or "dishonorable" to present your work in the most clear and understandable way to others, it's a basic condition for entry. I don't see how software's any different. We had a proposal around commit standards at work recently: we came to the conclusion that rebasing your private branches and squashing out irrelevant commits is the recommended flow, to make reviews easier.

TeMPOraL 7y ago
> In other professions, it's not "lying" or "dishonorable" to present your work in the most clear and understandable way to others, it's a basic condition for entry. I don't see how software's any different. That's because you joined the "it's a story" camp without noticing. If you instead view git history as a sort of gentlemen's audit log, then "refactoring" it is indeed both lying and dishonorable. And in no other profession it would be OK to mess with something used for review / audit purposes. Personally, I'm in favor of the history/audit log view, because you can't predict today what information you may need in the future, and refactoring git history throws away a lot of historical context.
- Vinnl 7y ago
  Not GP, but I'm certainly in the story camp. My commit history is not an audit log, it's documentation about the choices I made while writing my code, and a tool that helps me combine relevant parts. In fact, I'm sure that you're lying too: every time you Ctrl+Z in between commits, you're removing parts of your audit log. Choosing when to commit is telling a story. (Unless Fossil/whatever system you're using stores every character you ever type - I'm not familiar with it.) Edit: To use an example from the article: > Yet, sometimes we come upon a piece of code that we simply cannot understand. If you have never asked yourself, “What was this code’s developer thinking?” you haven’t been developing software for very long. With my commit, I'm telling other developers/my future self what I was thinking, rather than having them try to figure that out by themselves from my code. The assumption there is that I'm better at explaining my thinking than my code is.
  - TeMPOraL 7y ago
    > In fact, I'm sure that you're lying too: every time you Ctrl+Z in between commits, you're removing parts of your audit log. Choosing when to commit is telling a story. And I disagree here. The way I view it, my editor is my sandbox, I keep playing in it until I have something that I want to enter into record. When I commit work, I enter it into record, with a commit message explaining what the piece of work is. But to be honest, my repo clone is sort of my own sandbox too, I don't consider Git a fully append-only log, so I'd sometimes do commit editing on my local repo. But once published, I consider it immutable. (Or rather I'd prefer to; the team in the main project I'm working on right now has a rebase-heavy workflow.) On a practical note, I'm fine with history cleanup done on the spot. E.g. I've committed three things in the past hour, I squash them together. Or I rearrange stuff I made over the course of the day. But I don't like attempts at messing with history that's many days old (or more), because at that point the person doing the cleanup doesn't have the context of the work in their minds anymore, so history edits throw away valuable information.
    - masklinn 7y ago
      > And I disagree here. The way I view it, my editor is my sandbox, I keep playing in it until I have something that I want to enter into record. When I commit work, I enter it into record, with a commit message explaining what the piece of work is. The way I view it, my development branch is my sandbox. I keep playing in it until I have something that I want to enter into the record. When I merge work, I enter it into record with a merge message explaining what the piece of work is. I don't see the point of immutably recording typos a reviewer noticed. I view a pull request (or whatever you call them) as a patch series. Something to be tinkered with, rewrite and resubmit until it's considered good enough. If I want to record every stumble, issue and hare-brained idea, that can go into the patch messages.
    - greenhatman 7y ago
      I view any branch that only I work on as my sandbox as well. You should only ever rebase non-public branches in any case. So I don't see the problem.
    - 7y ago
- mjw1007 7y ago
  For you to believe that "Rebasing is the same as lying" is mistaken, it isn't necessary for you to be in the "it's a story" camp: it's only necessary for you to believe that the "it's a story" camp exists.
- greenhatman 7y ago
  I prefer to squash away commits that leave the code in a non-working state. Because it makes using git bisect easier later if you need to find a commit that broke something.
  - TeMPOraL 7y ago
    A habit I learned when working with SVN-versioned project is to never commit code in a non-working state. There's rarely ever a reason to, if you're thoughtful about your work. With completely new code, you just keep it disconnected from the main product and then you only have to ensure it compiles. With changes, you make them incrementally. Even large-scale changes can be done without breaking commits this way.
    - detaro 7y ago
      So don't commit code before it's gone through automated CI testing, codereview and QA? Or never make mistakes that require any of those to catch them? (At least before CI, it might not even compile correctly everywhere) Git can easily handle getting rid of or modifying commits, so why not make use of that ability in a controlled manner? I.e. I'd typically not re-build the history of the master or another major branch just to fix a bug introduced a while back at the source (although I guess backporting fixes might be similar). But for work in progress, one or a few commits about to be merged, smaller fixes are better made at the source. Not to talk about entirely irrelevant commits like "it's the end of the day, let's commit and push to a branch so it's not just on my machine".
- banachtarski 7y ago
  I edit emails before I hit send. Guess I should apologize for propagating massive campaigns of deception. Seriously though, I have no idea how you arrive at such a nonsensical conclusion. Before anyone publishes what they made, how can we possibly ascertain what was done, and why should we care.
  - TeMPOraL 7y ago
    > I edit emails before I hit send. Guess I should apologize for propagating massive campaigns of deception. I'm not talking about that. But do you edit your diary to "refactor" the things you wrote a month or year earlier? Related: people here seem to implicitly assume "never rebase published branches". I don't know how widely accepted that rule is, but in the teams I worked with, the workflow was "every now and then, rebase develop / feature branch on top of master, and then push --force".
    - banachtarski 7y ago
      Your "teams" violate standard best practice employed virtually everywhere I've worked and every open source project I've worked on.
      - fulafel 7y ago
        In public debates about this people often defend rebasing feature branches rspecially if they feel nobody else will work on the same branch. My personal experience bears this out as well. It's very easy to accidentally break your own rules, si this goes wrong regularly and the gallout becomes apparent only at some point down the pipeline. It's an added cognitive burden to be vigilant about which git mode you are working in.
    - saagarjha 7y ago
      How do you tag releases? Wouldn’t the commit hash change out from under the commit you cared about?
      - 7y ago
- sfink 7y ago
  Or you could record the original graph of commits during a rebase. When the actual content wasn't that important, you could choose to discard the old commit data but keep that metadata graph. (That way someone who builds on top of an old commit can use that graph to get the right merge logic.) But then you would have reimplemented mercurial's obsolescence markers.
- lars512 7y ago
  I can acknowledge that some settings exist where you might want a strict audit log, where you have pre-agreed the rules and legal requirements, and must stick to them. I don't believe most software development work requires such a strict log. I believe that most teams should be free to use git in the most productive way for them. I believe the "PR-as-story" camp is more productive, and already have war stories where not having that hurt. Always happy to hear war stories from other camps.
taywrobel 7y ago
It makes reviews easier, as well as debugging with things like bisect. If you leave commits with typos or syntax errors in your master branch history, determining weather a commit is good or bad for the right reason becomes a much more arduous task. If you do a rebase + squash on merge approach, the commit history is succinct, descriptive, and healthy, which I’ve found immensely beneficial. (Disclosure: I currently work at GitHub, but these opinions are my own)

TeMPOraL 7y ago

> In other professions, it's not "lying" or "dishonorable" to present your work in the most clear and understandable way to others, it's a basic condition for entry. I don't see how software's any different. That's because you joined the "it's a story" camp without noticing. If you instead view git history as a sort of gentlemen's audit log, then "refactoring" it is indeed both lying and dishonorable. And in no other profession it would be OK to mess with something used for review / audit purposes. Personally, I'm in favor of the history/audit log view, because you can't predict today what information you may need in the future, and refactoring git history throws away a lot of historical context.

Vinnl 7y ago
Not GP, but I'm certainly in the story camp. My commit history is not an audit log, it's documentation about the choices I made while writing my code, and a tool that helps me combine relevant parts. In fact, I'm sure that you're lying too: every time you Ctrl+Z in between commits, you're removing parts of your audit log. Choosing when to commit is telling a story. (Unless Fossil/whatever system you're using stores every character you ever type - I'm not familiar with it.) Edit: To use an example from the article: > Yet, sometimes we come upon a piece of code that we simply cannot understand. If you have never asked yourself, “What was this code’s developer thinking?” you haven’t been developing software for very long. With my commit, I'm telling other developers/my future self what I was thinking, rather than having them try to figure that out by themselves from my code. The assumption there is that I'm better at explaining my thinking than my code is.
- TeMPOraL 7y ago
  > In fact, I'm sure that you're lying too: every time you Ctrl+Z in between commits, you're removing parts of your audit log. Choosing when to commit is telling a story. And I disagree here. The way I view it, my editor is my sandbox, I keep playing in it until I have something that I want to enter into record. When I commit work, I enter it into record, with a commit message explaining what the piece of work is. But to be honest, my repo clone is sort of my own sandbox too, I don't consider Git a fully append-only log, so I'd sometimes do commit editing on my local repo. But once published, I consider it immutable. (Or rather I'd prefer to; the team in the main project I'm working on right now has a rebase-heavy workflow.) On a practical note, I'm fine with history cleanup done on the spot. E.g. I've committed three things in the past hour, I squash them together. Or I rearrange stuff I made over the course of the day. But I don't like attempts at messing with history that's many days old (or more), because at that point the person doing the cleanup doesn't have the context of the work in their minds anymore, so history edits throw away valuable information.
  - masklinn 7y ago
    > And I disagree here. The way I view it, my editor is my sandbox, I keep playing in it until I have something that I want to enter into record. When I commit work, I enter it into record, with a commit message explaining what the piece of work is. The way I view it, my development branch is my sandbox. I keep playing in it until I have something that I want to enter into the record. When I merge work, I enter it into record with a merge message explaining what the piece of work is. I don't see the point of immutably recording typos a reviewer noticed. I view a pull request (or whatever you call them) as a patch series. Something to be tinkered with, rewrite and resubmit until it's considered good enough. If I want to record every stumble, issue and hare-brained idea, that can go into the patch messages.
  - greenhatman 7y ago
    I view any branch that only I work on as my sandbox as well. You should only ever rebase non-public branches in any case. So I don't see the problem.
  - 7y ago
mjw1007 7y ago
For you to believe that "Rebasing is the same as lying" is mistaken, it isn't necessary for you to be in the "it's a story" camp: it's only necessary for you to believe that the "it's a story" camp exists.
greenhatman 7y ago
I prefer to squash away commits that leave the code in a non-working state. Because it makes using git bisect easier later if you need to find a commit that broke something.
- TeMPOraL 7y ago
  A habit I learned when working with SVN-versioned project is to never commit code in a non-working state. There's rarely ever a reason to, if you're thoughtful about your work. With completely new code, you just keep it disconnected from the main product and then you only have to ensure it compiles. With changes, you make them incrementally. Even large-scale changes can be done without breaking commits this way.
  - detaro 7y ago
    So don't commit code before it's gone through automated CI testing, codereview and QA? Or never make mistakes that require any of those to catch them? (At least before CI, it might not even compile correctly everywhere) Git can easily handle getting rid of or modifying commits, so why not make use of that ability in a controlled manner? I.e. I'd typically not re-build the history of the master or another major branch just to fix a bug introduced a while back at the source (although I guess backporting fixes might be similar). But for work in progress, one or a few commits about to be merged, smaller fixes are better made at the source. Not to talk about entirely irrelevant commits like "it's the end of the day, let's commit and push to a branch so it's not just on my machine".
banachtarski 7y ago
I edit emails before I hit send. Guess I should apologize for propagating massive campaigns of deception. Seriously though, I have no idea how you arrive at such a nonsensical conclusion. Before anyone publishes what they made, how can we possibly ascertain what was done, and why should we care.
- TeMPOraL 7y ago
  > I edit emails before I hit send. Guess I should apologize for propagating massive campaigns of deception. I'm not talking about that. But do you edit your diary to "refactor" the things you wrote a month or year earlier? Related: people here seem to implicitly assume "never rebase published branches". I don't know how widely accepted that rule is, but in the teams I worked with, the workflow was "every now and then, rebase develop / feature branch on top of master, and then push --force".
  - banachtarski 7y ago
    Your "teams" violate standard best practice employed virtually everywhere I've worked and every open source project I've worked on.
    - fulafel 7y ago
      In public debates about this people often defend rebasing feature branches rspecially if they feel nobody else will work on the same branch. My personal experience bears this out as well. It's very easy to accidentally break your own rules, si this goes wrong regularly and the gallout becomes apparent only at some point down the pipeline. It's an added cognitive burden to be vigilant about which git mode you are working in.
  - saagarjha 7y ago
    How do you tag releases? Wouldn’t the commit hash change out from under the commit you cared about?
    - 7y ago
sfink 7y ago
Or you could record the original graph of commits during a rebase. When the actual content wasn't that important, you could choose to discard the old commit data but keep that metadata graph. (That way someone who builds on top of an old commit can use that graph to get the right merge logic.) But then you would have reimplemented mercurial's obsolescence markers.
lars512 7y ago
I can acknowledge that some settings exist where you might want a strict audit log, where you have pre-agreed the rules and legal requirements, and must stick to them. I don't believe most software development work requires such a strict log. I believe that most teams should be free to use git in the most productive way for them. I believe the "PR-as-story" camp is more productive, and already have war stories where not having that hurt. Always happy to hear war stories from other camps.

taywrobel 7y ago

It makes reviews easier, as well as debugging with things like bisect. If you leave commits with typos or syntax errors in your master branch history, determining weather a commit is good or bad for the right reason becomes a much more arduous task. If you do a rebase + squash on merge approach, the commit history is succinct, descriptive, and healthy, which I’ve found immensely beneficial. (Disclosure: I currently work at GitHub, but these opinions are my own)