3 ms·

I've encountered similar difficulties around codebases with a lack of file hierarchy structure. But one major difficulty in fixing the issue is that moving a lo

by rudi-c 6y ago

I've encountered similar difficulties around codebases with a lack of file hierarchy structure. But one major difficulty in fixing the issue is that moving a lot of files around tends to trash `git blame`, which is often more valuable than knowing what folder to put a new file in. Is that something you've encountered?

ryanianian 6y ago
There are workarounds to get git to search harder or to commit things in a way that's helpful for large-scale file-shuffles, but to be honest I've rarely found this to be enough of a reason to not move things around. The end result is a much more productive and purposeful place for code to live and grow. This said, moving files and moving code within those files at the same time is a recipe for confusing yourself and git. Move files first, then content.
- deleted 6y ago
  [deleted]
- nitrogen 6y ago
  A few options to look at specifically: --follow, -M, and -C. Less related to refactoring I also find --first-parent and --merges useful
smallnamespace 6y ago
Try putting the refactoring commit in .git-blame-ignore-revs
- karlding 6y ago
  Note that .git-blame-ignore-revs is just a convention, git doesn't automatically use the file like how git treats the .gitignore file. You can add it to the repo configuration though, so you don't need to pass --ignore-revs-file every time, provided that you're running Git 2.3+[0]. $ git config blame.ignoreRevsFile .git-blame-ignore-revs This is extremely useful if, for example, your team decided to introduce new automated style changes, and didn't want to completely clobber the history for blame. By specifying the commit that introduced the style change, actual "interesting" changes should be correctly attributed and the style change commit is ignored in the blame output. [0] https://github.com/git/git/blob/master/Documentation/RelNotes/2.23.0.txt#L83-L84 https://github.com/git/git/blob/master/Documentation/RelNote...
Lammy 6y ago
Use Mercurial? :)
- john-radio 6y ago
  business-meeting-defenestration.png
- irishcoffee 6y ago
  This is the correct response. Using mercurial is like learning lisp after a c-like language. I don’t hate git, but I sure don’t like it either.
bcbrown 6y ago
On codebases that have had this sort of mass file-moving, one tactic I've used is keeping a link to the commit prior to the file-moving. Then I can check out that version, manually browse to the file's prior location, and use git blame. It's manual and tedious, but it works. Perhaps one mitigation could be to include a message describing something like this in the git commit for the mass-move.
- lainga 6y ago
  can you actually make a symlink to a commit in .git/ ? neat...
  - irishcoffee 6y ago
    You can in mercurial. Should you... different question.

by rudi-c 6y ago

ryanianian 6y ago

There are workarounds to get git to search harder or to commit things in a way that's helpful for large-scale file-shuffles, but to be honest I've rarely found this to be enough of a reason to not move things around. The end result is a much more productive and purposeful place for code to live and grow. This said, moving files and moving code within those files at the same time is a recipe for confusing yourself and git. Move files first, then content.

deleted 6y ago
[deleted]
nitrogen 6y ago
A few options to look at specifically: --follow, -M, and -C. Less related to refactoring I also find --first-parent and --merges useful

smallnamespace 6y ago

Try putting the refactoring commit in .git-blame-ignore-revs

karlding 6y ago
Note that .git-blame-ignore-revs is just a convention, git doesn't automatically use the file like how git treats the .gitignore file. You can add it to the repo configuration though, so you don't need to pass --ignore-revs-file every time, provided that you're running Git 2.3+[0]. $ git config blame.ignoreRevsFile .git-blame-ignore-revs This is extremely useful if, for example, your team decided to introduce new automated style changes, and didn't want to completely clobber the history for blame. By specifying the commit that introduced the style change, actual "interesting" changes should be correctly attributed and the style change commit is ignored in the blame output. [0] https://github.com/git/git/blob/master/Documentation/RelNotes/2.23.0.txt#L83-L84 https://github.com/git/git/blob/master/Documentation/RelNote...

Lammy 6y ago

Use Mercurial? :)

john-radio 6y ago
business-meeting-defenestration.png
irishcoffee 6y ago
This is the correct response. Using mercurial is like learning lisp after a c-like language. I don’t hate git, but I sure don’t like it either.

bcbrown 6y ago

On codebases that have had this sort of mass file-moving, one tactic I've used is keeping a link to the commit prior to the file-moving. Then I can check out that version, manually browse to the file's prior location, and use git blame. It's manual and tedious, but it works. Perhaps one mitigation could be to include a message describing something like this in the git commit for the mass-move.

lainga 6y ago
can you actually make a symlink to a commit in .git/ ? neat...
- irishcoffee 6y ago
  You can in mercurial. Should you... different question.