5 ms·

>> easy to use, easy to understand > I already understand git, so does everyone on my team, and everyone that interviews... Really? Because every team I've ev

>> easy to use, easy to understand > I already understand git, so does everyone on my team, and everyone that interviews... Really? Because every team I've ever met could use git but the moment anything left the golden path they had to either 1. delete everything, reclone, and manually fix things up, or 2. turn to the one greybeard who actually did understand git. Either your team is the 99th percentile, or your definition of "understand" is rather generous.

chipdart 3y ago
> Really? Because every team I've ever met could use git but the moment anything left the golden path they had to either (...) I've been using Git for over a decade and I never had the need to "delete everything, reclone". The only time I screwed up a Git repo was when I was experimenting with storing Git repos in USB pens and one of them got corrupted. I have no idea what might lead anyone to screw up a Git repo, because that's simply unrealistic.
- eternityforest 3y ago
  The easiest way is to change a commit you've already pushed, and that something somewhere else references, and then force push it.
  - chipdart 3y ago
    > (...) and then force push it. I don't think this is a good example. Forcing a push means that the repository will lose commits, but you still keep yours in your local branch. This means the repo is not broken, but at best you have a perfectly valid local repository that just happens to be out of sync. If you rename your local branch and set it to not track the remote one, and afterwards you fetch changes from the remote branch, then you're done.