3 ms·

That sounds quite complicated to me. Why not just have your patches in their own branches?

Hackbraten 5y ago
I’d say that highly depends on your habits and how your brain works. Some people prefer to focus on one topic at a time, have their current branch open, and choose not to give in to opportunistic edits if unrelated to the task at hand. Others prefer to work their way through a piece of code for example from top to bottom, making opportunistic edits along the way, even if unrelated to the task. Not having to switch branches can be convenient in that case. I’m 100% in the latter team. Near the end of a coding session, my `git diff` often shows three or four completely unrelated sets of changes. Some might call that a rather unproductive and annoying way to work. But I really love it that way. My brain just _craves_ to fix that typo or convert that tab to spaces right away, even when I’m supposed to fix a bug right now. I love dealing with those things right away so I get them out of my mind and don’t have to put them on a mental stack — even if that means a little more chaos later when it’s time to bin my edits into different commits. Arguably, I _could_ switch branches for such edits. But frankly, I’m used to opportunistic editing, and sticking with that approach feels just super convenient.
- xyzzy_plugh 5y ago
  This is me. Commits closer to upstream (older in the branch) are usually more stable, easier to merge, probably already out for review. The newest commits at the tip of the branch are the crazy WIP changes I'm considering, and not ready for prime-time.
- deleted 5y ago
  [deleted]
- secondcoming 5y ago
  Convenient for you, but not for anyone else who has to review your work
  - Hackbraten 5y ago
    Before I even push anything, I squash and re-order my commits, then cherry-pick into appropriate branches. I just don’t switch branches while coding.

I’d say that highly depends on your habits and how your brain works. Some people prefer to focus on one topic at a time, have their current branch open, and choose not to give in to opportunistic edits if unrelated to the task at hand. Others prefer to work their way through a piece of code for example from top to bottom, making opportunistic edits along the way, even if unrelated to the task. Not having to switch branches can be convenient in that case. I’m 100% in the latter team. Near the end of a coding session, my `git diff` often shows three or four completely unrelated sets of changes. Some might call that a rather unproductive and annoying way to work. But I really love it that way. My brain just _craves_ to fix that typo or convert that tab to spaces right away, even when I’m supposed to fix a bug right now. I love dealing with those things right away so I get them out of my mind and don’t have to put them on a mental stack — even if that means a little more chaos later when it’s time to bin my edits into different commits. Arguably, I _could_ switch branches for such edits. But frankly, I’m used to opportunistic editing, and sticking with that approach feels just super convenient.

xyzzy_plugh 5y ago
This is me. Commits closer to upstream (older in the branch) are usually more stable, easier to merge, probably already out for review. The newest commits at the tip of the branch are the crazy WIP changes I'm considering, and not ready for prime-time.
deleted 5y ago
[deleted]
secondcoming 5y ago
Convenient for you, but not for anyone else who has to review your work
- Hackbraten 5y ago
  Before I even push anything, I squash and re-order my commits, then cherry-pick into appropriate branches. I just don’t switch branches while coding.