Looking at a file, and then looking the commit which last modified a specific line in that file is a trivial operation in git that I do on a regular basis.
On the largest repos I've worked with `git blame` takes a second or two: long enough to be annoying and make me wish it was a bit faster, but still fast enough for interactive use and well short of the threshold where I would be tempted to context switch after invoking the command. On most repos it's perceptively instant.
I suspect on a HDD `git blame` would be unbearably slow on anything but the smallest of repositories, but it has been many years since I last worked with source code stored on a HDD.
That's true, I'm not the op, but changesets get in a way when using git for SCM, where the typical workflow is to merge between two branches on the level of subdirectories.
In my company people simply use checkout to apply changes from another branch, but that doesn't handle well for example file removals. It also creates a completely different commit so the branches diverge more and more, making things like rebase more time consuming.
It is a huge pain, which would not exist if we would use SVN as a backed for example.
I agree that that's not well supported, because it kind of goes against the grain of git thinking about project versions rather than file or directory versions.
What you should probably do in this case is use git merge nevertheless, but reset all changes outside of the directory of interest before committing the merge. This way, you get the history of the merge in the DAG, which will make git's merge resolution work.
Unfortunately, I'm not aware of a built-in way of doing this.
