4 ms·

Works extremely well indeed. Like git was basically made to be used like this. However, only because of that 'squash and merge' aka 'sculpt a nice history with

by stinos 5y ago

Works extremely well indeed. Like git was basically made to be used like this. However, only because of that 'squash and merge' aka 'sculpt a nice history with the emphasis on story' bit. Not doing that is in my opinion and experience completely useless for code. As far as I'm concerned there's hardly any difference between one commit with message 'fixes' introducing a 1k loc diff code dump or 1000 commits introducing a one-line diff: a proper git history is a joy to work with when figuring out bugs and why/how things were done the way they are. Anything else is just mediocre at best, usually just worthless. Which I learned the hard way obviously.

piva00 5y ago
> However, only because of that 'squash and merge' aka 'sculpt a nice history with the emphasis on story' bit. Not doing that is in my opinion and experience completely useless for code. A thousand times this, I use `git log` as a debugging and learning tool, if I can find the exact commit that introduced a change that I don't really understand why or how was done I resort to looking into git's history to figure it out. I hate when developers don't put an effort to tell the story of "why" you are doing what you did. The most common failure is just listing down the changes done in the code (the ones you can just read with `git diff`), I hate that. I treat git's history as a breadcrumb trail, I leave as many breadcrumbs as I can on my commits so others can find the trail later on: JIRA ticket reference, background of the change, why a refactoring is being done, what I found during the refactoring that made it end with a strange design, why the documentation needed to be edited, etc. Whatever I can think that would make my life easier in 1-2 years time if I ever had to read `git log` I try to leave for my future colleagues...
- stinos 5y ago
  The most common failure is just listing down the changes done in the code (the ones you can just read with `git diff`), I hate that Exactly. But I have noticed for some people this seems just really hard, don't know why exactly. Even after repeating and explaining the same thing (git commits, just like comments in code, should explain why, not what, the what can be inferred from the code and if not the code is usually not very good) I see people struggling with coming up with an acceptable explanation in full sentences of why a change was made.

by stinos 5y ago

piva00 5y ago

> However, only because of that 'squash and merge' aka 'sculpt a nice history with the emphasis on story' bit. Not doing that is in my opinion and experience completely useless for code. A thousand times this, I use `git log` as a debugging and learning tool, if I can find the exact commit that introduced a change that I don't really understand why or how was done I resort to looking into git's history to figure it out. I hate when developers don't put an effort to tell the story of "why" you are doing what you did. The most common failure is just listing down the changes done in the code (the ones you can just read with `git diff`), I hate that. I treat git's history as a breadcrumb trail, I leave as many breadcrumbs as I can on my commits so others can find the trail later on: JIRA ticket reference, background of the change, why a refactoring is being done, what I found during the refactoring that made it end with a strange design, why the documentation needed to be edited, etc. Whatever I can think that would make my life easier in 1-2 years time if I ever had to read `git log` I try to leave for my future colleagues...

stinos 5y ago
The most common failure is just listing down the changes done in the code (the ones you can just read with `git diff`), I hate that Exactly. But I have noticed for some people this seems just really hard, don't know why exactly. Even after repeating and explaining the same thing (git commits, just like comments in code, should explain why, not what, the what can be inferred from the code and if not the code is usually not very good) I see people struggling with coming up with an acceptable explanation in full sentences of why a change was made.