3 ms·

Yeah, you can do this to make your commits cleaner, but I find it easier to just manually edit the file and then undo after you add the patch.

by impure 2y ago

recursive 2y ago
I've never felt the urge to commit half of a file, but if I did, surely I would just copy the whole file to scratch buffer somewhere, edit the real file to the first state I want, and then commit that. Some people say they have to re-learn regular expressions each time they use them. I think this is mostly because they don't use them much. For me, I have to re-learn fancy git stuff like hunk staging each time I use it. Because I never use it.
- PittleyDunkin 2y ago
  I use hunk editing quite a bit to organize long chains of commits into more logical order. This often involves merging and then re-splitting commits, but sometimes interactive rebasing is sufficient.
- mananaysiempre 2y ago
  I don’t know, I feel that having to go through each change individually before committing is useful discipline. Nothing to learn: just tell yourself to only ever use `git add -p` and the rest will come naturally. Your first edited hunk, in particular, will come the first time you want to stage your actual change without having to delete that debug print that you figure might still come in handy. (Also useful but admittedly situational are git checkout -p, git reset -p, and git stash -p; and editing hunks within those is a bit of a rarity.) I guess the difference might be that my workflow is less edit → stage → commit and more edit → (stage things I’m sure about → edit/debug things I’m not →)* commit. For example, “the staged version is what I have in the debugger, modulo debugging code” can be a useful invariant to maintain. (Now that I’m thinking about it, having the build system automatically save a snapshot of the source it used somewhere in the VCS—and stamp it in the executable—sounds tremendously useful. Surely somebody’s already built that?..)
  - recursive 2y ago
    I do review all my changes before committing. In my workflow, that's the same time I remove the debugging instrumentation. I can't imagine a scenario where there's debug code that I don't want to commit, but I still have a use for it after committing. If there's still a known bug I'm trying to solve in this area of code, I'll include that also. If this is a long-standing mystery, then the logging code probably needs to get committed anyway.
- self_awareness 2y ago
  I originally thought this was about editing AmigaOS executable files. Those contain HUNKs.
kelnos 2y ago
The article mentions this, but suggests that doing it that way is error-prone, and if you accidentally make changes after your undo, but before your redo, you can lose the changes you want to save. I do it your way often too, but I'm going to give hunk editing a try; assuming it isn't too difficult to get right, it feels safer and ultimately easier.

Yeah, you can do this to make your commits cleaner, but I find it easier to just manually edit the file and then undo after you add the patch.

by impure 2y ago

Yeah, you can do this to make your commits cleaner, but I find it easier to just manually edit the file and then undo after you add the patch.

recursive 2y ago

I've never felt the urge to commit half of a file, but if I did, surely I would just copy the whole file to scratch buffer somewhere, edit the real file to the first state I want, and then commit that. Some people say they have to re-learn regular expressions each time they use them. I think this is mostly because they don't use them much. For me, I have to re-learn fancy git stuff like hunk staging each time I use it. Because I never use it.

PittleyDunkin 2y ago
I use hunk editing quite a bit to organize long chains of commits into more logical order. This often involves merging and then re-splitting commits, but sometimes interactive rebasing is sufficient.
mananaysiempre 2y ago
I don’t know, I feel that having to go through each change individually before committing is useful discipline. Nothing to learn: just tell yourself to only ever use `git add -p` and the rest will come naturally. Your first edited hunk, in particular, will come the first time you want to stage your actual change without having to delete that debug print that you figure might still come in handy. (Also useful but admittedly situational are git checkout -p, git reset -p, and git stash -p; and editing hunks within those is a bit of a rarity.) I guess the difference might be that my workflow is less edit → stage → commit and more edit → (stage things I’m sure about → edit/debug things I’m not →)* commit. For example, “the staged version is what I have in the debugger, modulo debugging code” can be a useful invariant to maintain. (Now that I’m thinking about it, having the build system automatically save a snapshot of the source it used somewhere in the VCS—and stamp it in the executable—sounds tremendously useful. Surely somebody’s already built that?..)
- recursive 2y ago
  I do review all my changes before committing. In my workflow, that's the same time I remove the debugging instrumentation. I can't imagine a scenario where there's debug code that I don't want to commit, but I still have a use for it after committing. If there's still a known bug I'm trying to solve in this area of code, I'll include that also. If this is a long-standing mystery, then the logging code probably needs to get committed anyway.
self_awareness 2y ago
I originally thought this was about editing AmigaOS executable files. Those contain HUNKs.

kelnos 2y ago

The article mentions this, but suggests that doing it that way is error-prone, and if you accidentally make changes after your undo, but before your redo, you can lose the changes you want to save. I do it your way often too, but I'm going to give hunk editing a try; assuming it isn't too difficult to get right, it feels safer and ultimately easier.