←back to thread

94 points vincent_s | 1 comments | | HN request time: 0s | source
Show context
donatj ◴[] No.40914710[source]
One of the bigger things I try to hammer in to a junior developers mind is to be conscious and thoughtful about their individual commits. To basically never just "git add ." whatever might just happen to be different in their work area, but to ALWAYS review the diff and make the commit a logical collection of changes.

With the lack of staging area it really seems like this encourages the exact opposite. Seems like a good way to get secrets as well as just general junk and clutter committed to your repo history.

If I am working on a big project, I will start to commit change sets as parts of the code solidify without committing other less solid changes. That seems pretty basic. I don't want half finished changes forever committed to history.

replies(6): >>40914953 #>>40915330 #>>40915843 #>>40916939 #>>40919543 #>>40920358 #
ramblerman ◴[] No.40920358[source]
> To basically never just "git add ." whatever might just happen to be different in their work area

> I will start to commit change sets as parts of the code solidify without committing other less solid changes

I feel like you are pushing your idiosyncratic way of working on others. It's great that you have a way that works for you, but it seems rather odd to me that you would ever be working on more than one thing in the same staging area.

I always git add -a . because I'm working on one specific thing, and my tests just passed.

replies(2): >>40923701 #>>40924873 #
thebruce87m ◴[] No.40924873[source]
You never fix an unrelated typo or add something useful to the README that you couldn’t find but needed?
replies(2): >>40928822 #>>40930383 #
1. hyperman1 ◴[] No.40928822{3}[source]
Since I started with lazygit, I do it a lot less. The tool makes it extremely easy to select what changed lines belong to which commit. And easy things are done more commonly than hard things.