4 ms·
As far as danger goes, I've never got into a state I couldn't back out of using the reflog - though the user experience surrounding getting there and back could
by lotyrin 13y ago
As far as danger goes, I've never got into a state I couldn't back out of using the reflog - though the user experience surrounding getting there and back could definitely use some polishing.
As far as having mutable histories, from the standpoint of someone who has to review and integrate lots of branches from a large distributed team, its amounts to a necessary evil. It's difficult to review and merge anything more than a concise set of changes that achieve their end goal and it's also difficult to have committed such a changeset on the first try. Not having the team rebase out experimental and exploratory commits would be a huge mess and while it's an option to just wait to commit until you're done, that risks losing things, and leads to giant one-shot patches that can still be tricky to review and ship.
I'm not sure what workflows hg users that loathe to alter history adopt where they don't suffer from trying to integrate messy branches.
- kasey_junk 13y ago"from the standpoint of someone who has to review and integrate lots of branches from a large distributed team" I think this is a very telling point. I found git infuriating and inconsistent to an irresponsible degree, until I realized it wasn't built for me as a producer of code. It was built for people who have to integrate lots of code from lots of disparate producers. Once that lightbulb clicked a lot of things started to make more sense. I still find git infuriating as part of my daily development workflow, but at least I get it now. I still have a hard time recommending it for small teams that are doing on the fly integration, but for the big distributed team model, I could see it being the best choice.