6 ms·

Except that in practice people tend not to perform steps 4, 5 and 7. They then commit non-working code and honestly believe that their commit is OK, because the

by egork8n 13y ago

Except that in practice people tend not to perform steps 4, 5 and 7. They then commit non-working code and honestly believe that their commit is OK, because they saw all tests pass.

Peaker 13y ago
I think the people well-versed enough in git to use "git add -p" to review their own changes, and commit them separately, are the same people that would correctly test their commits. At least from my small sample size of people, that is true.
- egork8n 13y ago
  This is definitely not true for the outsource companies here in the 3rd world. It gets even worse when you face people who have used SVN for years. Once they realize that they can commit non-working code on their feature branch as long as the result of the final merge into master is OK, they start to dump random work-in-progress stuff into git repo. As the result, blame and bisect are completely broken, but who cares, that's another developer who would feel the pain trying to make sense from the changeset history two years from now, not you.
  - saidajigumi 13y ago
    One way to mitigate that is to always squash-merge the suspect work. In some orgs, it's really hard to establish a culture of good "git hygiene". Typically CI is already branch-focused, and the merging process after CI/review/etc. is tailored to just throw out the "noise" from the incoming branches. This also handles issues such as staff who just don't get that long-lived, continually remerged (from master) branches are evil when viewing history using `git log --graph` or similar GUI views.
eridius 13y ago
So, what, if people aren't using the full power of Git, the response is to remove that power? That seems completely backwards. The response should be to educate people on proper development practices.
- egork8n 13y ago
  Sometimes it just feels like not removing the nuclear missile launch button from a cage with monkeys arguing that we should not remove the power of nuclear weapons just because monkeys are unable to understand the geopolitical situation.
  - X4 13y ago
    Full Ack! (awesome metaphor btw)
StefanKarpinski 13y ago
Nifty trick: use `git stash --keep-index save` to leave the staged changes around while stashing the unstaged ones. Then run your tests, muddle around and fix things as necessary, and commit. Then `git stash pop` and you have all your changes back. It seems obvious to me that this behavior should be the default for `git stash` but it isn't. Thank goodness for aliases.

by egork8n 13y ago

Except that in practice people tend not to perform steps 4, 5 and 7. They then commit non-working code and honestly believe that their commit is OK, because they saw all tests pass.

Peaker 13y ago

I think the people well-versed enough in git to use "git add -p" to review their own changes, and commit them separately, are the same people that would correctly test their commits. At least from my small sample size of people, that is true.

egork8n 13y ago
This is definitely not true for the outsource companies here in the 3rd world. It gets even worse when you face people who have used SVN for years. Once they realize that they can commit non-working code on their feature branch as long as the result of the final merge into master is OK, they start to dump random work-in-progress stuff into git repo. As the result, blame and bisect are completely broken, but who cares, that's another developer who would feel the pain trying to make sense from the changeset history two years from now, not you.
- saidajigumi 13y ago
  One way to mitigate that is to always squash-merge the suspect work. In some orgs, it's really hard to establish a culture of good "git hygiene". Typically CI is already branch-focused, and the merging process after CI/review/etc. is tailored to just throw out the "noise" from the incoming branches. This also handles issues such as staff who just don't get that long-lived, continually remerged (from master) branches are evil when viewing history using `git log --graph` or similar GUI views.

eridius 13y ago

So, what, if people aren't using the full power of Git, the response is to remove that power? That seems completely backwards. The response should be to educate people on proper development practices.

egork8n 13y ago
Sometimes it just feels like not removing the nuclear missile launch button from a cage with monkeys arguing that we should not remove the power of nuclear weapons just because monkeys are unable to understand the geopolitical situation.
- X4 13y ago
  Full Ack! (awesome metaphor btw)

StefanKarpinski 13y ago

Nifty trick: use `git stash --keep-index save` to leave the staged changes around while stashing the unstaged ones. Then run your tests, muddle around and fix things as necessary, and commit. Then `git stash pop` and you have all your changes back. It seems obvious to me that this behavior should be the default for `git stash` but it isn't. Thank goodness for aliases.