4 ms·

> I've seen this same resistance to deleting code in programmers working in repos that are completely under VCS, and it's flabbergasting I think a lot of devel

> I've seen this same resistance to deleting code in programmers working in repos that are completely under VCS, and it's flabbergasting I think a lot of developers only know the basics of git. They can check in changes, they can look at history with git log, and maybe they know how to use git blame. They often don't know how to filter git history. They often don't know about the git pickaxe, or about exclude patterns, and don't even think to question if you can do something like "git log -G'int.*foo\(' -- ':(exclude)directory'" to search for 'foo' in the git log, excluding some directory. They know how to "grep" within the existing code tree though, so they know if it's not deleted they can find it again with the right grep. If it's deleted, they might not know how to find it in git history. I sympathize with this to a degree actually. Code in the git log is invisible to a lot of tooling, so for example it won't show up in autocomplete if your text editor might have otherwise suggested it, it won't show up in your library documentation, etc. If you truly think the code will be used again, I think it's at least defensible to leave it in the tree so that it comes along for refactors, and ends up being found when it's needed. For cases like Knight capital, where it's obviously never going to be useful again, it's not defensible of course.

lolinder 3y ago
I can understand that argument for small, standalone functions. Where it really gets at me is when people insist on leaving whole use cases or subsystems in place, which seems to be what happened here. You don't want these to be visible to autocomplete, because they're outdated and would need major modification to be correct again. If you do need to resurrect them, they're trivial to find in the git history—just search for the commit named "remove foo"—and they should pass through code review as if they were brand new code, because a lot of stuff will have changed around them in the intervening time.
bhasi 3y ago
> git pickaxe, or about exclude patterns, and don't even think to question if you can do something like "git log -G'int.*foo\(' -- ':(exclude)directory'" to search for 'foo' in the git log, excluding some directory Learned something new today, thank you! Will find ways to use these in my daily workflow.
jve 3y ago
> and don't even think to question if you can do something like "git log -G'int.*foo\(' -- ':(exclude)directory'" I do question it, but I know the answer is hard (as you demonstrated), so I don't bother. And I'm now looking at git log docs - I fail to parse how the exclude works even looking at the docs - I don't find anything about `:(` contstruct which houses exclude keyword. But thanks for -G - that will be useful. > Code in the git log is invisible to a lot of tooling This is the issue. I expect when searching code to have a way to search older commits. But azure devops won't do it. There is no checkbox "Include all commits"
- deleted 3y ago
  [deleted]
- TheDong 3y ago
  > I fail to parse how the exclude works even looking at the docs Most git subcommands can take a pathspec, including git log. The documentation you want to read is the pathspec docs, see here: https://git-scm.com/docs/gitglossary#Documentation/gitglossary.txt-aiddefpathspecapathspec https://git-scm.com/docs/gitglossary#Documentation/gitglossa... You can see that it includes the exclude keyword, among others. Since it applies to almost every command (from 'git add -- <pathspec>' to 'git checkout -- <pathspec>'), it's not mentioned as clearly in individual commands.
  - planede 3y ago
    git log and all other commands' man page should really refer back to gitglossary here then. And they should either name their argument <pathspec>, or specify that the given argument (<path> or <file>) is a pathspec.

lolinder 3y ago

I can understand that argument for small, standalone functions. Where it really gets at me is when people insist on leaving whole use cases or subsystems in place, which seems to be what happened here. You don't want these to be visible to autocomplete, because they're outdated and would need major modification to be correct again. If you do need to resurrect them, they're trivial to find in the git history—just search for the commit named "remove foo"—and they should pass through code review as if they were brand new code, because a lot of stuff will have changed around them in the intervening time.

bhasi 3y ago

> git pickaxe, or about exclude patterns, and don't even think to question if you can do something like "git log -G'int.*foo\(' -- ':(exclude)directory'" to search for 'foo' in the git log, excluding some directory Learned something new today, thank you! Will find ways to use these in my daily workflow.

jve 3y ago

> and don't even think to question if you can do something like "git log -G'int.*foo\(' -- ':(exclude)directory'" I do question it, but I know the answer is hard (as you demonstrated), so I don't bother. And I'm now looking at git log docs - I fail to parse how the exclude works even looking at the docs - I don't find anything about `:(` contstruct which houses exclude keyword. But thanks for -G - that will be useful. > Code in the git log is invisible to a lot of tooling This is the issue. I expect when searching code to have a way to search older commits. But azure devops won't do it. There is no checkbox "Include all commits"

deleted 3y ago
[deleted]
TheDong 3y ago
> I fail to parse how the exclude works even looking at the docs Most git subcommands can take a pathspec, including git log. The documentation you want to read is the pathspec docs, see here: https://git-scm.com/docs/gitglossary#Documentation/gitglossary.txt-aiddefpathspecapathspec https://git-scm.com/docs/gitglossary#Documentation/gitglossa... You can see that it includes the exclude keyword, among others. Since it applies to almost every command (from 'git add -- <pathspec>' to 'git checkout -- <pathspec>'), it's not mentioned as clearly in individual commands.
- planede 3y ago
  git log and all other commands' man page should really refer back to gitglossary here then. And they should either name their argument <pathspec>, or specify that the given argument (<path> or <file>) is a pathspec.