4 ms·

Git is a distributed version control system. You can do whatever you like locally and it won't "pollute" anything. Just don't merge that stuff into shared branc

Git is a distributed version control system. You can do whatever you like locally and it won't "pollute" anything. Just don't merge that stuff into shared branches. I automatically commit every time my editor (emacs) saves a file and I've been doing this for years (magit-wip). Nobody should be afraid of doing this!

thanksgiving 1y ago
Exactly this. I can make a hundred commits that are one file per commit and I can later go back and git reset --soft HEAD~100 and that will cleanly leave it as the hundred commits never happened.
throwaway-18 1y ago
Honest question - What DO you merge into shared branches? And, when your local needs to "catch up", don't you have to pull in those shared commits which conflict with your magit-wip commits because they touch the same code, but are different commit hashes?
- Crespyl 1y ago
  Feature branches that have been cleaned up and peer-reviewed/CI-tested, at least in the last few places I worked. Every so often this still means that devs working on a feature will need to rebase back on the latest version of the shared branch, but if your code is reasonably modular and your project management doesn't have people overlapping too much this shouldn't be terribly painful.
- globular-toast 1y ago
  The magit-wip commits go on a separate branch and ideally I'm never even aware of them. They just disappear eventually. They exist purely in case of a disaster à la the article. I make "real" commits as I go and use a combination of `git commit --amend` and fixup commits (via git-autofixup) and `rebase --autosquash`. I periodically (daily, at least) fetch upstream and rebase on to my target branch. I find if you keep on top of things you won't end up with some enormous conflict that you can't remember how to resolve.

4 ms·

Git is a distributed version control system. You can do whatever you like locally and it won't "pollute" anything. Just don't merge that stuff into shared branc

by globular-toast 1y ago

thanksgiving 1y ago
Exactly this. I can make a hundred commits that are one file per commit and I can later go back and git reset --soft HEAD~100 and that will cleanly leave it as the hundred commits never happened.
throwaway-18 1y ago
Honest question - What DO you merge into shared branches? And, when your local needs to "catch up", don't you have to pull in those shared commits which conflict with your magit-wip commits because they touch the same code, but are different commit hashes?
- Crespyl 1y ago
  Feature branches that have been cleaned up and peer-reviewed/CI-tested, at least in the last few places I worked. Every so often this still means that devs working on a feature will need to rebase back on the latest version of the shared branch, but if your code is reasonably modular and your project management doesn't have people overlapping too much this shouldn't be terribly painful.
- globular-toast 1y ago
  The magit-wip commits go on a separate branch and ideally I'm never even aware of them. They just disappear eventually. They exist purely in case of a disaster à la the article. I make "real" commits as I go and use a combination of `git commit --amend` and fixup commits (via git-autofixup) and `rebase --autosquash`. I periodically (daily, at least) fetch upstream and rebase on to my target branch. I find if you keep on top of things you won't end up with some enormous conflict that you can't remember how to resolve.