> if you open two copies of the same repo and copy and paste code, you're doing it wrong
It has worked for 10+ years - is that really doing it wrong, or just doing it in a way different from you.
> into something that looks good
Is this a requirement? Or just out of being particular?
>squashed […] before review
Is deleting (obfuscating) the history of your approach (chain of thought) important to you? The reviewer will review the last commit anyway (always) so is this necessary other than subjective neatness? This can be squashed at the point it is merged
It appears you are very efficient at git. I am having difficulty understanding the real utility of much you described. I wonder if it is a justification for finding the fun in using more uncommon features of git, or for “neatness”? Which is fine.
It's about making your tools work for you, not against you. If you've got something that works for you and you don't want to change it, don't.
But when the tool you're using has a feature specifically designed for copying its kind of things from one place to another, and then you choose not to use that feature, and choose to copy things from one place to another using a different but more familiar system, then yes I'm going to say you're doing it wrong. Now, that's just my opinion as a random Internet someone who doesn't know you, your workflow, your use-case, so it's entirely possible I'm wrong about you being wrong. But without clarifying details, yes, that's wrong. Now, wrong things still work, and fundamentally things need to work, so just because it's wrong doesn't mean it doesn't work.
> Is deleting (obfuscating) the history of your approach (chain of thought) important to you?
It's essential. I do dumb things but I don't like looking dumb, so no one needs to know that I spent however many hours going off in the wrong direction before figuring out what I'm really trying to do. The reviewer only sees what I show them, and they'll never see the abandoned commits and branches on my laptop. They don't need to, it's a waste of their time. Treat your reviewer's time as the most valuable thing in the world and don't waste it by having them trawl through your mess.
> I am having difficulty understanding the real utility of much you described.
The real utility, the thing that got me to invest the time into learning git so it works for me, is that when things stop working, I can rewind to when things were working, do a git diff, and it highlights the change which would have taken me hours to find without git.
There's more utility elsewhere, but that's the singular thing that convinced me to invest the time to get good at git.
What's the oldest code you've written? Go back to then and try and tweak a feature. Being neat about git is because that'll happen to you at some point, and future you, two or twenty years from now, will either thank you, or curse you for your commit message.
It has worked for 10+ years - is that really doing it wrong, or just doing it in a way different from you.
> into something that looks good
Is this a requirement? Or just out of being particular?
>squashed […] before review
Is deleting (obfuscating) the history of your approach (chain of thought) important to you? The reviewer will review the last commit anyway (always) so is this necessary other than subjective neatness? This can be squashed at the point it is merged
It appears you are very efficient at git. I am having difficulty understanding the real utility of much you described. I wonder if it is a justification for finding the fun in using more uncommon features of git, or for “neatness”? Which is fine.