5 ms·

OK, I don't get it. There's lots of praise for this though so I must be missing something that lots of other people get value from, so perhaps someone could be

OK, I don't get it. There's lots of praise for this though so I must be missing something that lots of other people get value from, so perhaps someone could be kind enough to explain where's the benefit to this? I'm fine with the history capturing what has actually happened. a Git history isn't something that is supposed to be admired as if it were a work of art. The git history is the scaffolding, not the cathedral itself. Even the source code isn't the cathedral, that's more super-structure. The product is the goal.

parhamn 2y ago
I don't get your point. Sure, the git log isnt the "cathedral", but also being able to change things quickly doesn't imply or necessitate this.
- xnorswap 2y ago
  My point is that I don't understand where the driving force for desiring to change it at all is coming from.
  - dzaima 2y ago
    Git blame and bisect do care about the state of specific commits. During development of a thing it should be desirable to be able to handle/test just whatever the current thing is and clean up afterwards if necessary, without having to completely drop ability to use git. But this can impact later bisects - having temporary printf("fuck sadjkoisajhdfo")s spamming outputs, project entirely not building on a configuration that wasn't cared about at the moment (or worse, build successfully, but function off enough that it's not obvious that the commit was not intended to be touched). And then there's the general thing of having a feature that you had been working on, but want to move it to some other branch. Or you committed things out of order and the committed order doesn't actually build in the middle. Or you didn't commit some file/change and thus have a sequence of ten completely-non-sensical non-functional commits. The inverse question deserves asking - why would you want to leave in your primary commit history things not meant to ever be looked at?
jamalaramala 2y ago
I think it is a good practice to clean up your branch before you merge it into master. So instead of: * Change 1 * Fix typo * Change 2 * Another typo * Change 3 * That didn't work * Ops, I did it again * Revert Change 3 * Change 3 (final) You'll merge: * Change 1 * Change 2 * Change 3 Which is much better, particularly if you have hundreds of developers working on the same codebase. And it is very easy to do that using `git rebase -i`. (I don't see the need for a GUI)
- WolfeReader 2y ago
  I'd rather have the dirty history than the clean one. It seems really useful to have a record of an approach that didn't work, to save others from trying it again. To see a "clean" history, I can always use log options like git's -first-parent. It works great and doesn't delete history.
- xnorswap 2y ago
  Okay, I guess this is also a consequence of having long lived branches that multiple people contribute to versus short-lived continuous integration into main. I can also see value there if you're not squashing commits at the PR level. I prefer just squashing commits so main becomes: - Feature 1 - Feature 2 - BugFix 1 - Feature 4 etc. The individual branches have the "dirty" history which can be useful, and main is kept neat by having feature of fix-level changes which are quality controlled through gated-commits. If you had to work on long-running feature branches which were more of a free-for-all so /branches/feature effectively becomes your "main" then I could see much more of an argument for re-writing history of individual contributors before merging into that feature branch. I'd still argue you should just set up proper quality control on the feature branch and squash commits going into that, but that's the kind of overhead that can frustrate some teams, so I can better understand now the desire for a half-way cleaning between squashing and the full dirty history.
xorcist 2y ago
I have worked with people have justified downright trash with "it's not supposed to be a work of art". That way lies madness. Code that takes a minute to write takes ten minutes to understand. Code is first and foremost for humans to understand, before it is for machines to execute. Otherwise there would be no need for comments, or sane names for functions. Or commit messages. Please be considerate to your readers.

parhamn 2y ago

I don't get your point. Sure, the git log isnt the "cathedral", but also being able to change things quickly doesn't imply or necessitate this.

xnorswap 2y ago
My point is that I don't understand where the driving force for desiring to change it at all is coming from.
- dzaima 2y ago
  Git blame and bisect do care about the state of specific commits. During development of a thing it should be desirable to be able to handle/test just whatever the current thing is and clean up afterwards if necessary, without having to completely drop ability to use git. But this can impact later bisects - having temporary printf("fuck sadjkoisajhdfo")s spamming outputs, project entirely not building on a configuration that wasn't cared about at the moment (or worse, build successfully, but function off enough that it's not obvious that the commit was not intended to be touched). And then there's the general thing of having a feature that you had been working on, but want to move it to some other branch. Or you committed things out of order and the committed order doesn't actually build in the middle. Or you didn't commit some file/change and thus have a sequence of ten completely-non-sensical non-functional commits. The inverse question deserves asking - why would you want to leave in your primary commit history things not meant to ever be looked at?

jamalaramala 2y ago

I think it is a good practice to clean up your branch before you merge it into master. So instead of: * Change 1 * Fix typo * Change 2 * Another typo * Change 3 * That didn't work * Ops, I did it again * Revert Change 3 * Change 3 (final) You'll merge: * Change 1 * Change 2 * Change 3 Which is much better, particularly if you have hundreds of developers working on the same codebase. And it is very easy to do that using `git rebase -i`. (I don't see the need for a GUI)

WolfeReader 2y ago
I'd rather have the dirty history than the clean one. It seems really useful to have a record of an approach that didn't work, to save others from trying it again. To see a "clean" history, I can always use log options like git's -first-parent. It works great and doesn't delete history.
xnorswap 2y ago
Okay, I guess this is also a consequence of having long lived branches that multiple people contribute to versus short-lived continuous integration into main. I can also see value there if you're not squashing commits at the PR level. I prefer just squashing commits so main becomes: - Feature 1 - Feature 2 - BugFix 1 - Feature 4 etc. The individual branches have the "dirty" history which can be useful, and main is kept neat by having feature of fix-level changes which are quality controlled through gated-commits. If you had to work on long-running feature branches which were more of a free-for-all so /branches/feature effectively becomes your "main" then I could see much more of an argument for re-writing history of individual contributors before merging into that feature branch. I'd still argue you should just set up proper quality control on the feature branch and squash commits going into that, but that's the kind of overhead that can frustrate some teams, so I can better understand now the desire for a half-way cleaning between squashing and the full dirty history.

xorcist 2y ago

I have worked with people have justified downright trash with "it's not supposed to be a work of art". That way lies madness. Code that takes a minute to write takes ten minutes to understand. Code is first and foremost for humans to understand, before it is for machines to execute. Otherwise there would be no need for comments, or sane names for functions. Or commit messages. Please be considerate to your readers.