4 ms·

This is solving the problem with the wrong tool. What you need is documentation. But people working on the project you have to maintain didn't write one. So,

This is solving the problem with the wrong tool. What you need is documentation. But people working on the project you have to maintain didn't write one. So, you are trying to use git blame, astrology and ouija board to guess what the project authors wanted. And, while doing so, you are arguing for never cleaning the house, keeping all the garbage where it falls. Which will only make your situation worse, because the history will bloat with a lot of contradictory or false information.

Izkata 2y ago
> What you need is documentation. But people working on the project you have to maintain didn't write one. Oh there is documentation, but it's old and contradictory. Commits are self-organizing by history. > So, you are trying to use git blame, astrology and ouija board to guess what the project authors wanted. There's no guessing involved. Keep the original commits and it's right there in the commit message and order of changes. Guessing is what happens when you destroy the history by using rebases like this. > And, while doing so, you are arguing for never cleaning the house, keeping all the garbage where it falls. Which will only make your situation worse, because the history will bloat with a lot of contradictory or false information. I'm not saying "don't refactor" at all. Clean the code up as much as you want. The history however is completely hidden and not causing any clutter, it's there when you need it and invisible the rest of the time, so erasing useful history is just busywork for negative benefit. Any apparent contradictions are also easily resolved because commits have timestamps and ordering and are part of the larger completely automatically generated history.
- crabbone 2y ago
  > Oh there is documentation, but it's old and contradictory. That's like saying "oh, but I have food to eat, except it's been eaten by mice and mold. I mean, if documentation doesn't work, then it's the same as "no documentation"... > There's no guessing involved. But that's where you are wrong. The more garbage isn't cleaned from the repository, the more guessing you have to do. What if a comment next to the code contradicts the code? -- It's garbage! But nobody cleaned it, and now you have to guess whether the comment or the code is correct. But this is just an easy-to-understand example. Essentially, any bug is like this: there was an intention to do X, but Y was done instead, and now you need to figure out whether Y was intended or X. History needs to make sense, it doesn't need to document the mistakes that happened along the way. Not for the purpose of development anyways. > Clean the code up as much as you want. The history however is completely hidden and not causing any clutter, I'm not talking about refactoring code, I'm talking about cleaning the history. It's only hidden if you are completely hapless when it comes to working with Git. Any developer worth their salt work with the history regularly. It's not a secret, and it's definitely not hidden. On the contrary, if you believe history to be "invisible" -- just use rsync. There's no need for complicated system that's designed to work with history... If you cannot make use of your history -- why bother keeping it?

Izkata 2y ago

> What you need is documentation. But people working on the project you have to maintain didn't write one. Oh there is documentation, but it's old and contradictory. Commits are self-organizing by history. > So, you are trying to use git blame, astrology and ouija board to guess what the project authors wanted. There's no guessing involved. Keep the original commits and it's right there in the commit message and order of changes. Guessing is what happens when you destroy the history by using rebases like this. > And, while doing so, you are arguing for never cleaning the house, keeping all the garbage where it falls. Which will only make your situation worse, because the history will bloat with a lot of contradictory or false information. I'm not saying "don't refactor" at all. Clean the code up as much as you want. The history however is completely hidden and not causing any clutter, it's there when you need it and invisible the rest of the time, so erasing useful history is just busywork for negative benefit. Any apparent contradictions are also easily resolved because commits have timestamps and ordering and are part of the larger completely automatically generated history.

crabbone 2y ago
> Oh there is documentation, but it's old and contradictory. That's like saying "oh, but I have food to eat, except it's been eaten by mice and mold. I mean, if documentation doesn't work, then it's the same as "no documentation"... > There's no guessing involved. But that's where you are wrong. The more garbage isn't cleaned from the repository, the more guessing you have to do. What if a comment next to the code contradicts the code? -- It's garbage! But nobody cleaned it, and now you have to guess whether the comment or the code is correct. But this is just an easy-to-understand example. Essentially, any bug is like this: there was an intention to do X, but Y was done instead, and now you need to figure out whether Y was intended or X. History needs to make sense, it doesn't need to document the mistakes that happened along the way. Not for the purpose of development anyways. > Clean the code up as much as you want. The history however is completely hidden and not causing any clutter, I'm not talking about refactoring code, I'm talking about cleaning the history. It's only hidden if you are completely hapless when it comes to working with Git. Any developer worth their salt work with the history regularly. It's not a secret, and it's definitely not hidden. On the contrary, if you believe history to be "invisible" -- just use rsync. There's no need for complicated system that's designed to work with history... If you cannot make use of your history -- why bother keeping it?