4 ms·

5. Teaching `git add .` as default to add changes to the staging area is not ideal. Show adding specific files instead has less room for subsequent "oh shit" an

• ajross 2y ago
  True enough, but it does make for good practice with the index and splitting workflows later on when you need to clean it up. I think there's space for "git add ." as a didactic step. It maps cleanly to the most obvious way to understand a commit, as "here's what I've done". Bootstrapping from that to an understanding of "commits as communication with other developers" will naturally happen over time.
  • baobun 2y ago
    Is not very compatible with printlog-debugging. I'd rather encourage devs to prod around as they go if it benefits them, which causes grief for either them or reviewers in the end if they've internalized what you just said. Explicitly adding internalizes a personal review process as inherent part of the push process, instead of something you attempt to force on top later. It's better with a collaboration workflow that limits the span of time with expected discipline, imo.
    • recursive 2y ago
      You can have both. Make sure the whole diff is what you want it to be before invoking `add .`
      • baobun 2y ago
        Sure. I hear the pull-out method is also an effective contraceptive.
        • recursive 2y ago
          If it works for you, I'm not going to try to talk you out of it.
• zahlman 2y ago
  Learning about the `-p` option for `git add` was one of two things that revolutionized my Git usage. (The other was figuring out how to write effective commit messages.)
  • wodenokoto 2y ago
    This is the main reason to use a GUI imho.
    • baobun 2y ago
      Tig is a great one for the terminal fwiw. gitg for something simple, graphical and widely available.