6 ms·

I do the same. Many people comment about commiting frequently but that doesn't work for me: delete code + commit => I don't see the code anymore and my brain ma

I do the same. Many people comment about commiting frequently but that doesn't work for me: delete code + commit => I don't see the code anymore and my brain magically forgets about it. I need the quick feedback loop: commented code + uncommented code (all in one screen) => new code is going to look like a mix of both. If I have to use git to see commented code then the feedback loop is broken.

CobsterLock 6y ago
I get this for tracking down a bug or working on speeding a block up. But why does the unused code need to be committed? Yes it helps you with your one problem but it clutters the document with extra information for others. So I guess I phrased my question a little accusatory, commented out code is a pet-peeve of mine, but I'm still genuinely interested why the two different blocks need to be committed. Or i guess more importantly, if they need to be pushed to the mainline for others to recieve
- zrobotics 6y ago
  Maybe I misread the parent, but I don't think it was stated that the commented out code is committed. FWIW, I also sometimes work this way; however I delete the commented out block when I'm finished. This is also a pet peeve of mine, the only time commented out blocks of code are acceptable is if the obvious way to write something introduces a bug or ignores an edge case. In that case, I also leave a note explaining not to refactor this section and explain why. But especially while refactoring or fixing certain issues, I really find it helpful to have the prior version still present to compare against. If I have to commit while that commented code is still present, invariably my last commit message is along the lines of "removed commented code" or "cleaned comments for function XYZ". Especially since for these cases I also typically end up writing a comment once finished anyway. If there was something tricky enough happening that I was comparing against older code, likely there is something confusing enough happening that whoever is in the file next could also use some additional explanation that can only really be written once finished.
londons_explore 6y ago
Commiting frequently also has a substantial cost of needing to think of a commit message. If you don't think of a commit message, you'll never be able to find this version again. If you think up a message every 2 minutes, you'll quickly find you spend more time thinking of commit messages than writing code. I wish there was some kind of auto generated commit message. Things like: "Added function xyz()" or "Adjusted constant FOO to 27" or "Made lots of changes in file a.c,, b.c and c.c". These could be auto generated, and then commits could happen in the background every time the code is compiled. It would be nice for git to have some kind of "commit of commits" which allows a hierarchical representation of commits. Ie. the "Add new printscreen feature" could have as subcommits "Create print renderer" and "Hook up print UI".
- samb1729 6y ago
  > I wish there was some kind of auto generated commit message. Things like: > "Added function xyz()" or "Adjusted constant FOO to 27" or "Made lots of changes in file a.c,, b.c and c.c". I would argue that these are not good commit messages as they do not add information not already provided by the diff itself. Commit messages should communicate the intended effect of a change that has been made, rather than being a lossy compression of a sequence of keystrokes.
  - londons_explore 6y ago
    In which case I want a lossy summary of the diff... And it would be great if a tool could generate those for me...
    - BatmanAoD 6y ago
      Try `git log -p <path(s)>`, which will show the sequence of diffs for only the specified set of files.
- FroshKiller 6y ago
  If you don't already know the commit message before you start writing the code, maybe you should wait to write the code.
francislavoie 6y ago
I use GitKraken (or insert your favourite git GUI) and I don't have this problem. If I ever have a "wtf did I do 10 minutes ago?" moment I can just look at GitKraken real quick and feel like a stenographer reading back notes. I typically have it open beside my IDE so I can keep an eye on the progress in the file tree view. I can drag-select a set of lines, right-click and stage them, when I'm basically locking those in, then keep going. It also auto-fetches every minute or so, so I have great visibility on what coworkers are doing in the commit graph. Lets me react to what they do pretty quickly, and I can implicitly review what they do and I can poke them if I notice something weird.
- scambier 6y ago
  I also use my git GUI to quickly review what changed before making the commit. That way not only I filter out irrelevant chunks/files, but I also compare the new lines to the old ones.

CobsterLock 6y ago

I get this for tracking down a bug or working on speeding a block up. But why does the unused code need to be committed? Yes it helps you with your one problem but it clutters the document with extra information for others. So I guess I phrased my question a little accusatory, commented out code is a pet-peeve of mine, but I'm still genuinely interested why the two different blocks need to be committed. Or i guess more importantly, if they need to be pushed to the mainline for others to recieve

zrobotics 6y ago
Maybe I misread the parent, but I don't think it was stated that the commented out code is committed. FWIW, I also sometimes work this way; however I delete the commented out block when I'm finished. This is also a pet peeve of mine, the only time commented out blocks of code are acceptable is if the obvious way to write something introduces a bug or ignores an edge case. In that case, I also leave a note explaining not to refactor this section and explain why. But especially while refactoring or fixing certain issues, I really find it helpful to have the prior version still present to compare against. If I have to commit while that commented code is still present, invariably my last commit message is along the lines of "removed commented code" or "cleaned comments for function XYZ". Especially since for these cases I also typically end up writing a comment once finished anyway. If there was something tricky enough happening that I was comparing against older code, likely there is something confusing enough happening that whoever is in the file next could also use some additional explanation that can only really be written once finished.

londons_explore 6y ago

Commiting frequently also has a substantial cost of needing to think of a commit message. If you don't think of a commit message, you'll never be able to find this version again. If you think up a message every 2 minutes, you'll quickly find you spend more time thinking of commit messages than writing code. I wish there was some kind of auto generated commit message. Things like: "Added function xyz()" or "Adjusted constant FOO to 27" or "Made lots of changes in file a.c,, b.c and c.c". These could be auto generated, and then commits could happen in the background every time the code is compiled. It would be nice for git to have some kind of "commit of commits" which allows a hierarchical representation of commits. Ie. the "Add new printscreen feature" could have as subcommits "Create print renderer" and "Hook up print UI".

samb1729 6y ago
> I wish there was some kind of auto generated commit message. Things like: > "Added function xyz()" or "Adjusted constant FOO to 27" or "Made lots of changes in file a.c,, b.c and c.c". I would argue that these are not good commit messages as they do not add information not already provided by the diff itself. Commit messages should communicate the intended effect of a change that has been made, rather than being a lossy compression of a sequence of keystrokes.
- londons_explore 6y ago
  In which case I want a lossy summary of the diff... And it would be great if a tool could generate those for me...
  - BatmanAoD 6y ago
    Try `git log -p <path(s)>`, which will show the sequence of diffs for only the specified set of files.
FroshKiller 6y ago
If you don't already know the commit message before you start writing the code, maybe you should wait to write the code.

francislavoie 6y ago

I use GitKraken (or insert your favourite git GUI) and I don't have this problem. If I ever have a "wtf did I do 10 minutes ago?" moment I can just look at GitKraken real quick and feel like a stenographer reading back notes. I typically have it open beside my IDE so I can keep an eye on the progress in the file tree view. I can drag-select a set of lines, right-click and stage them, when I'm basically locking those in, then keep going. It also auto-fetches every minute or so, so I have great visibility on what coworkers are doing in the commit graph. Lets me react to what they do pretty quickly, and I can implicitly review what they do and I can poke them if I notice something weird.

scambier 6y ago
I also use my git GUI to quickly review what changed before making the commit. That way not only I filter out irrelevant chunks/files, but I also compare the new lines to the old ones.