5 ms·

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 too

by 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.
- Vinnl 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. I guess I just don't see how that's not "telling a story". The commit is not a recording of the process you went through to get the code in a certain state, but a piece of work of which you decided it should be entered into record, with a message you wrote that explains it.
- daveFNbuck 7y ago
  So if I fix a typo and commit the fix in my feature branch within a few hours, it's ok to squash the fix, but if someone notices it on code review the next day, I should keep the typo fix as a separate commit? What's the value of having this in your audit log? Is it more valuable than being able to revert the commits without having to first revert the typo fix, or do a git bisect without running into broken commits that exist only to preserve an audit log?
- CraigJPerry 7y ago
  >> The way I view it, my editor is my sandbox This position makes no sense to me. How can your editor be your sandbox but your branch before pushing is not? That’s an arbitrary distinction without merit. Noone rebases on a public branch so both scenarios are about what you do before publishing your work. I think the whole conversation about history is missing the point. The problem we’re trying to solve is complexity. Having a bunch of out of date commits floating about does nothing to reduce complexity.
  - deleted 7y ago
    [deleted]
fulafel 7y ago
> 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. Sure, that is the intention. But humans are very fallible in communication and communication is hard. Being later able to see what you did along with of what you explained is of obvious utility.

by Vinnl 7y ago

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.
Vinnl 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. I guess I just don't see how that's not "telling a story". The commit is not a recording of the process you went through to get the code in a certain state, but a piece of work of which you decided it should be entered into record, with a message you wrote that explains it.
daveFNbuck 7y ago
So if I fix a typo and commit the fix in my feature branch within a few hours, it's ok to squash the fix, but if someone notices it on code review the next day, I should keep the typo fix as a separate commit? What's the value of having this in your audit log? Is it more valuable than being able to revert the commits without having to first revert the typo fix, or do a git bisect without running into broken commits that exist only to preserve an audit log?
CraigJPerry 7y ago
>> The way I view it, my editor is my sandbox This position makes no sense to me. How can your editor be your sandbox but your branch before pushing is not? That’s an arbitrary distinction without merit. Noone rebases on a public branch so both scenarios are about what you do before publishing your work. I think the whole conversation about history is missing the point. The problem we’re trying to solve is complexity. Having a bunch of out of date commits floating about does nothing to reduce complexity.
- deleted 7y ago
  [deleted]

fulafel 7y ago

> 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. Sure, that is the intention. But humans are very fallible in communication and communication is hard. Being later able to see what you did along with of what you explained is of obvious utility.