zbg commit bad practice

[V01D-NULL]

zbg commit ran a git add ..

This isn't really considered good practice because there can be temp, test or unfinshed files that need to manually be unstaged which can be quite tedious.

Solution: Implement a separate zbg add <files> command, allowing the commit command to function as just that.

[chshersh]

Thanks for your feedback!

As mentioned in the README, zbg is not a git replacement. I don't see what zbg add can add to git add (pun intended), so I don't see many benefits in having a separate command for this.

I do find myself occasionally in a need to add some files separately when I'm in the middle of a coding mess.
However, often I prefer to plan my work in advance. I also prefer investing in .gitignore (or .git/info/exclude if patching .gitignore is not possible), so committing accidental rubbish is not a problem.

I have big committing all the local changes for years and I haven't experienced any problems with that, so I don't see the need to change zbg commit at the moment.

[V01D-NULL]

Hi, thanks for the response!

often I prefer to plan my work in advance

You know how it is... debugger; and print statements in all files :D

It certainly isn't a problem of poor planning or not using a gitignore (which I am), I probably should've been more specific.

I used to git add . before that bit me a long time ago, ever since I've been git diff-ing my changes and stage them manually.

I don't think adding files not staged for a commit should be placed in the .gitignore (or temporary files for testing. I'd honestly forget about them and the file would grow a lot tbh), but each their own.

Who knows, I might fork it, speedrun learing ocaml and just implement that for myself. Love the looks of zbg🥇