10 ms·

Fixing a typo as you work on something else is not bad - that's called Boy Scouting[1] and it's totally acceptable to sprinkle small improvements/cleanups in a

Fixing a typo as you work on something else is not bad - that's called Boy Scouting[1] and it's totally acceptable to sprinkle small improvements/cleanups in a change. As for getting distracted and refactoring something else - you're context switching. When you do that, you can also context-switch your repo by stashing your current changes (git stash) while you work on that tangent. Or commit your current changes to their local branch (you're liberally using branches, right? Branches are cheap in Git) and switch to a new branch for refactoring. If you really want to write your commit first (which is a great idea, because you should know what changes you're planning to make before you start working on them!), then you can create an empty commit when you switch to your new feature branch: git commit --allow-empty Write your "plan" as the first commit in that branch. Then do your work, committing frequently, and when you're done and squashing your changes into a single commit for review you now have that first commit available and waiting. Most issues I see from people getting confused with their changes and using Git is not using enough branches for their work, not being practiced at branch manipulation, and not being disciplined and intentional about their changes. People aren't thinking about "how am I going to release this?" or "how can this be reviewed most efficiently?", and they get carried away with making a lot of changes at once instead of many small changes. My rule of thumb is that I'm only allowed to take one step off the path/plan, anything else gets put on a todo list to revisit later. Plan the work, then work the plan. [1] https://www.informit.com/articles/article.aspx?p=1235624&seqNum=6 https://www.informit.com/articles/article.aspx?p=1235624&seq...

barkingcat 6y ago
Why would something with such a good concept need to be tied to a gendered term? How about calling it "camp grounding"?
- computerphage 6y ago
  The Boy Scouts of America did a lot to promote Leave No Trace and helped it become a common practice.
- tremon 6y ago
  I suggest you take your complaint to the English language office. In Dutch, that organization would be called "padvinders" (lit. pathfinders, i.e. trackers) which shows that the concept itself isn't gendered.
- fastball 6y ago
  Because it's a Boy Scout rule?
- disgrunt 6y ago
  Your suggested term works, too. But why is it bad that a good concept has a gendered term?
- snakeboy 6y ago
  It's not appealing to any kind of gendered stereotyping though. It's a quote from the founder of "The Boy Scouts Association".
- MarkSweep 6y ago
  One definition of the term in question: https://biratkirat.medium.com/step-8-the-boy-scout-rule-robert-c-martin-uncle-bob-9ac839778385 https://biratkirat.medium.com/step-8-the-boy-scout-rule-robe...
- someperson 6y ago
  The non-gendered term for "Boy Scouts" is simply "Scouts" or "Scouting" [1]. So if you need a non-gendered name, just call it "Scouting". And the word 'scouting' already means "moving ahead of a group to gather information", which makes sense in the software engineering context too. [1] https://en.wikipedia.org/wiki/Scouting https://en.wikipedia.org/wiki/Scouting
derekp7 6y ago
My only issue is that if you fix something small and include that in an unrelated feature or bug fix commit, is if you have to do a "git revert" you are then reverting both items.
- tremon 6y ago
  That's why you don't squash before merging. If you merge the original commits (and make a separate commit for the minor fix), you can revert the problematic commit without affecting the rest of the feature.
  - hibbelig 6y ago
    But making a separate commit for the minor fix is onerous once your working copy has accumulated other changes. That's what the OP says -- you have to use "git add -p" and that is onerous.
bilalq 6y ago
> Fixing a typo as you work on something else is not bad - that's called Boy Scouting[1] and it's totally acceptable to sprinkle small improvements/cleanups in a change. Different people have different standards and opinions on what's acceptable. Personally, I'm in the camp of people that would hate to see an unrelated typo fix being included in the same commit as some other change. I strive for semantically meaningful commits, and prefer the people I work with to do the same. It's fine to make such fixes, but they should be in separate commits (though they can be in the same code review request). The pain point the author of the article mentioned is very real (needing to do `git add --patch`). > Write your "plan" as the first commit in that branch. Then do your work, committing frequently, and when you're done and squashing your changes into a single commit for review you now have that first commit available and waiting. There are often times when multiple end commits make sense. Squashing/rebasing down to essentials is fine, but that still may be more than just one commit on occasion.
- watwut 6y ago
  Most people however dont mind them at all and they practically do zero harm. However, forcing people to split it into two commits likely means it wont ever get done. Because who wants to go through previous commit files to check for typos in other peoples code. People wont, either they fix it as they are noticing them or not at all.
  - bilalq 6y ago
    >Most people however dont mind them at all and they practically do zero harm. They don't do zero harm though. The git blame history gets thrashed. If I see the last change one line 15 of a file is associated with a commit titled `Enable TCP connection reuse`, I'm going to wonder what a change to a line throwing an unrelated exception has to do with that. This means I'll waste time investigating a red herring. If I need to see the blame to find out who to ask about the feature, I also get garbage direction. The same preference for semantic commits applies to things like optimizations. Don't sneak in keep alive timeout changes in the same commit as `Add email notification support`. If a bug turns up on the email feature, I don't want to waste time potentially looking at the wrong thing. > However, forcing people to split it into two commits likely means it wont ever get done. That's not been my experience. They either get corrected at code review time on first release, or someone will make a semantically isolated commit for the fixes and include them in a future code review/pull request. > Because who wants to go through previous commit files to check for typos in other peoples code. People wont, either they fix it as they are noticing them or not at all. Not sure what point you're making here. You don't need to go through previous commits to see typos if they're still there in the current commit.
burntoutfire 6y ago
> you're liberally using branches, right? Branches are cheap in Git Branches may be cheap in Git, but they're expensive in typical modern software eng. process. For every branch, a PR must be opened, code must be reviewed, full test suite must be ran, the testers must ok that the change does not require extending the test suite, and only finally after the whole ordeal we're ok to merge. That's why I prefer my branches big and meaty.
- Zecc 6y ago
  > For every branch, a PR must be opened, code must be reviewed, full test suite must be ran, the testers must ok that the change does not require extending the test suite, and only finally after the whole ordeal we're ok to merge. Surely this isn't true for local branches on your machine? I hope you're not living under such a dystopia.
- bluefirebrand 6y ago
  But this process is small and fast when your branches are small and fast. Code reviews length takes exponentially longer and misses way more when branches are "big and meaty"
  - carlmr 6y ago
    It should be small and fast, but depending on where you work it isn't. And trying to get a big corp to adapt to you is like trying to boil the ocean.
- tolbish 6y ago
  Just create the branch locally for your incremental changes and then when you are done, connect the remote repository to initiate the PR.
nextlevelwizard 6y ago
Really depends on other changes. Say you change some variable name since whoever was there last forgot to rename something while they did refactoring. Couple days later someone fixes a bug that is related to this variable in some other way. Now you can't simply back port the bug fix commit into earlier release because it relies on a commit that introduces a feature that is not wanted/needed. Obviously fix is simple enough either edit the commit to also contain the variable change or make a tiny "dummy" commit that just contains the fix. Now whoever is making this decision is cursing you since you could have just made the dummy commit in the first place and prevented this extra work that went into figuring out when the bug fix commit alone wasn't working/compiling.
Communitivity 6y ago
I didn't know about the empty commit, that's useful. The approach I try to follow is below. The BLUF is I use a similar but more granular approach and agree with writing the commit before you do the work. First, I write the commit message capturing the intended design in a file and then try to create a skeleton of API level changes with method names and stubs from my design as my first commit. I use the file as my commit message for this. Next, as I work I commit freely locally with small commits but I don't push to remote. I do this rather than commit --amend so I can track and revert as needed if needed. I probably could just use --amend. Last, once I have it working I squash those commits into one commit and push to remote, then merge in changes from master if any and repush, and then start cycle over. I tend to do this at one level below the issue I am working, so I then still have multiple commits for an issue, one per sub-issue. I will sometimes leave these as is in the PR, or sometimes I will squash these into a single commit as well. Which I do depends on how active the branch I'm targeting with the PR is, how big the commits are, and the extent of the changes.
bluefirebrand 6y ago
> As for getting distracted and refactoring something else - you're context switching. Which absolutely should be a new branch and probably a different ticket.
WorldMaker 6y ago
In addition to empty commits or rebasing work in progress commits, git stash accepts -m/--message and you can write a "proper" commit message when stashing work in progress. Some client apps (I've seen VSCode do it) will even kindly move that message from the stash into their commit message writing box on popping the stash.

barkingcat 6y ago

Why would something with such a good concept need to be tied to a gendered term? How about calling it "camp grounding"?

computerphage 6y ago
The Boy Scouts of America did a lot to promote Leave No Trace and helped it become a common practice.
tremon 6y ago
I suggest you take your complaint to the English language office. In Dutch, that organization would be called "padvinders" (lit. pathfinders, i.e. trackers) which shows that the concept itself isn't gendered.
fastball 6y ago
Because it's a Boy Scout rule?
disgrunt 6y ago
Your suggested term works, too. But why is it bad that a good concept has a gendered term?
snakeboy 6y ago
It's not appealing to any kind of gendered stereotyping though. It's a quote from the founder of "The Boy Scouts Association".
MarkSweep 6y ago
One definition of the term in question: https://biratkirat.medium.com/step-8-the-boy-scout-rule-robert-c-martin-uncle-bob-9ac839778385 https://biratkirat.medium.com/step-8-the-boy-scout-rule-robe...
someperson 6y ago
The non-gendered term for "Boy Scouts" is simply "Scouts" or "Scouting" [1]. So if you need a non-gendered name, just call it "Scouting". And the word 'scouting' already means "moving ahead of a group to gather information", which makes sense in the software engineering context too. [1] https://en.wikipedia.org/wiki/Scouting https://en.wikipedia.org/wiki/Scouting

derekp7 6y ago

My only issue is that if you fix something small and include that in an unrelated feature or bug fix commit, is if you have to do a "git revert" you are then reverting both items.

tremon 6y ago
That's why you don't squash before merging. If you merge the original commits (and make a separate commit for the minor fix), you can revert the problematic commit without affecting the rest of the feature.
- hibbelig 6y ago
  But making a separate commit for the minor fix is onerous once your working copy has accumulated other changes. That's what the OP says -- you have to use "git add -p" and that is onerous.

bilalq 6y ago

> Fixing a typo as you work on something else is not bad - that's called Boy Scouting[1] and it's totally acceptable to sprinkle small improvements/cleanups in a change. Different people have different standards and opinions on what's acceptable. Personally, I'm in the camp of people that would hate to see an unrelated typo fix being included in the same commit as some other change. I strive for semantically meaningful commits, and prefer the people I work with to do the same. It's fine to make such fixes, but they should be in separate commits (though they can be in the same code review request). The pain point the author of the article mentioned is very real (needing to do `git add --patch`). > Write your "plan" as the first commit in that branch. Then do your work, committing frequently, and when you're done and squashing your changes into a single commit for review you now have that first commit available and waiting. There are often times when multiple end commits make sense. Squashing/rebasing down to essentials is fine, but that still may be more than just one commit on occasion.

watwut 6y ago
Most people however dont mind them at all and they practically do zero harm. However, forcing people to split it into two commits likely means it wont ever get done. Because who wants to go through previous commit files to check for typos in other peoples code. People wont, either they fix it as they are noticing them or not at all.
- bilalq 6y ago
  >Most people however dont mind them at all and they practically do zero harm. They don't do zero harm though. The git blame history gets thrashed. If I see the last change one line 15 of a file is associated with a commit titled `Enable TCP connection reuse`, I'm going to wonder what a change to a line throwing an unrelated exception has to do with that. This means I'll waste time investigating a red herring. If I need to see the blame to find out who to ask about the feature, I also get garbage direction. The same preference for semantic commits applies to things like optimizations. Don't sneak in keep alive timeout changes in the same commit as `Add email notification support`. If a bug turns up on the email feature, I don't want to waste time potentially looking at the wrong thing. > However, forcing people to split it into two commits likely means it wont ever get done. That's not been my experience. They either get corrected at code review time on first release, or someone will make a semantically isolated commit for the fixes and include them in a future code review/pull request. > Because who wants to go through previous commit files to check for typos in other peoples code. People wont, either they fix it as they are noticing them or not at all. Not sure what point you're making here. You don't need to go through previous commits to see typos if they're still there in the current commit.

burntoutfire 6y ago

> you're liberally using branches, right? Branches are cheap in Git Branches may be cheap in Git, but they're expensive in typical modern software eng. process. For every branch, a PR must be opened, code must be reviewed, full test suite must be ran, the testers must ok that the change does not require extending the test suite, and only finally after the whole ordeal we're ok to merge. That's why I prefer my branches big and meaty.

Zecc 6y ago
> For every branch, a PR must be opened, code must be reviewed, full test suite must be ran, the testers must ok that the change does not require extending the test suite, and only finally after the whole ordeal we're ok to merge. Surely this isn't true for local branches on your machine? I hope you're not living under such a dystopia.
bluefirebrand 6y ago
But this process is small and fast when your branches are small and fast. Code reviews length takes exponentially longer and misses way more when branches are "big and meaty"
- carlmr 6y ago
  It should be small and fast, but depending on where you work it isn't. And trying to get a big corp to adapt to you is like trying to boil the ocean.
tolbish 6y ago
Just create the branch locally for your incremental changes and then when you are done, connect the remote repository to initiate the PR.

nextlevelwizard 6y ago

Really depends on other changes. Say you change some variable name since whoever was there last forgot to rename something while they did refactoring. Couple days later someone fixes a bug that is related to this variable in some other way. Now you can't simply back port the bug fix commit into earlier release because it relies on a commit that introduces a feature that is not wanted/needed. Obviously fix is simple enough either edit the commit to also contain the variable change or make a tiny "dummy" commit that just contains the fix. Now whoever is making this decision is cursing you since you could have just made the dummy commit in the first place and prevented this extra work that went into figuring out when the bug fix commit alone wasn't working/compiling.

Communitivity 6y ago

I didn't know about the empty commit, that's useful. The approach I try to follow is below. The BLUF is I use a similar but more granular approach and agree with writing the commit before you do the work. First, I write the commit message capturing the intended design in a file and then try to create a skeleton of API level changes with method names and stubs from my design as my first commit. I use the file as my commit message for this. Next, as I work I commit freely locally with small commits but I don't push to remote. I do this rather than commit --amend so I can track and revert as needed if needed. I probably could just use --amend. Last, once I have it working I squash those commits into one commit and push to remote, then merge in changes from master if any and repush, and then start cycle over. I tend to do this at one level below the issue I am working, so I then still have multiple commits for an issue, one per sub-issue. I will sometimes leave these as is in the PR, or sometimes I will squash these into a single commit as well. Which I do depends on how active the branch I'm targeting with the PR is, how big the commits are, and the extent of the changes.

bluefirebrand 6y ago

> As for getting distracted and refactoring something else - you're context switching. Which absolutely should be a new branch and probably a different ticket.

WorldMaker 6y ago

In addition to empty commits or rebasing work in progress commits, git stash accepts -m/--message and you can write a "proper" commit message when stashing work in progress. Some client apps (I've seen VSCode do it) will even kindly move that message from the stash into their commit message writing box on popping the stash.