[kadoban]

That sounds like too long to wait to commit, by my judgement. There's too much risk of loss of work, or at least annoyance getting it back via editor undo.

What about making smaller commits and going back and editing it later? You could either 'git reset --soft' to "undo" some commit(s) and then craft them how you like, or anything else. Seems like your git skills should easily be good enough to handle that.

By the way, you know about 'git add -p', right? That's a fancier way to do what I think you're doing with diff and apply, though yours may work better for you.

[u801e]

> There's too much risk of loss of work

Backups can be made independent of source control.

> What about making smaller commits and going back and editing it later?

In experience, it's actually more time consuming to restructure an existing set of commits (especially if they're making changes to the same files and same lines of code) compared to just making a new set of commits.

> By the way, you know about 'git add -p', right?

I am aware of it, but I'm not a fan of the menu based approach. When I stage code with git apply, I actually use vim's feature of visually highlighting the part of the diff I want to stage and filtering those lines through the git apply command. I can skip things like debug statements I've added to the code when staging. I can also unstage code by using the same command with the -R parameter.

I even commit within vim by reading the output of git status -v, writing my commit message and filtering that message through git commit with the -F parameter to have it read from standard input.

[kadoban]

> Backups can be made independent of source control.

They can be, but it's ~hard to do it in a way that lines up with saving all your work, and you miss out on conveniences like the reflog (eg what was the state of _this_ branch half an hour ago?) Zfs snapshots can do it if they're manual or ~minutes apart and automatic, but that's a pretty blunt tool for this IMO.

> In experience, it's actually more time consuming to restructure an existing set of commits [...]

That's fair, but you _can_ just do that. If you have the commits in the first place, you have the choice. 'git reset --soft master' for example is "I don't want those commits on this branch anymore, but I want the final changes to rework into new commit(s)". I'd say about half the time I nuke the commits, half the time I rework them or they were just good enough already.

Sounds like you have a workflow that works for you though, just throwing out ideas in case they help.

> I am aware of it, but I'm not a fan of the menu based approach.

Agreed, it's sometimes tedious. I'll look into the way you do it, seems like for larger ~features your way might be less annoying.

[pmoleri]

> Backups can be made independent of source control.

To be fair there's a middle ground. You can just commit as WIP and force push to save progress. Then undo that commit and start making the individual commits. Everyone's happy.