I don't like the idea of most of the ancient state being culled.
The codebase at my current job has a cutoff from when it was moved to git, and there's even less hope of finding out why something was done for code that predates that than there is for the rest of the codebase.
Maybe I've always worked at the wrong places, but I've never been in a place where I wish there were fewer commits in the history, but a lot of the time I have wished there were more commits (often when trying to review code), so that I had a finer grain insight into why a particular line of code was written, and what else was changed for the same purpose.
I'm 100% with you that losing this information is nothing but a bad thing. I find that even the worst git commits tend to provide the best and most accurate and up-to date documentation of the code; it amazes me that so many people choose to throw that away!
I don't like the idea of most of the ancient state being culled.
Me either.
No need to clone the entire history if you don't need it though?
git clone --depth 100, should be fine?
That way, you're only cloning what you need - and you're not throwing anything away, so if you do need the full history, you can always fetch that later.
@manuartero Sorry, but I fundamentally disagree with your statement:
too much information leads to disinformation
Not, if you understand how Git works and how to read this information correctly.
Once you delete information, via an Interactive Rebase, you lose it forever, which could be disastrous, when trying to track bugs, later on.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Interesting. I have the opposite experience. I use
git stashin those cases, or do yougit rebase --interactiveto clean things up later.I don't like the idea of most of the ancient state being culled.
The codebase at my current job has a cutoff from when it was moved to git, and there's even less hope of finding out why something was done for code that predates that than there is for the rest of the codebase.
Maybe I've always worked at the wrong places, but I've never been in a place where I wish there were fewer commits in the history, but a lot of the time I have wished there were more commits (often when trying to review code), so that I had a finer grain insight into why a particular line of code was written, and what else was changed for the same purpose.
I'm 100% with you that losing this information is nothing but a bad thing. I find that even the worst git commits tend to provide the best and most accurate and up-to date documentation of the code; it amazes me that so many people choose to throw that away!
Me either.
No need to clone the entire history if you don't need it though?
git clone --depth 100, should be fine?That way, you're only cloning what you need - and you're not throwing anything away, so if you do need the full history, you can always fetch that later.
@manuartero Sorry, but I fundamentally disagree with your statement:
Not, if you understand how Git works and how to read this information correctly.
Once you delete information, via an Interactive Rebase, you lose it forever, which could be disastrous, when trying to track bugs, later on.