529
Please let me squash a merge commit (thelemmy.club)
submitted 4 months ago by to c/programmer_humor@programming.dev
50 comments fedilink hide all child comments
 
you are viewing a single comment's thread
view the rest of the comments
[–] 4 points 4 months ago (2 children)

Huh. I have never in my 19 year career using git, ever wanted to copy a file and pretend all of the history of that file is also the history of the new file. I mean, I don't think I've ever even wanted to copy a file? Why are you copying a file?

Like, maybe I'm just too familiar with git to see the forest for the trees, but what the heck are you doing over there? 😅

And just in case it's useful, a tip is that you can use git blame -C to have the blame algorithm use a heuristic to try and find a "source" line if it was moved, including from another file, during a commit, and then continue following the history of that line, to try and get the real commit where this was written, not just the last time it was moved around.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 2 points 4 months ago (1 child)

    Why are you copying a file?

    I'm splitting a several thousand LOC file, which I don't have previous history in.

    Like, maybe I’m just too familiar with git to see the forest for the trees, but what the heck are you doing over there?

    Normally copying a file and committing transfers the authorship to you, because the copy just appears from nothing as a brand new file, never known to git. This would prevent browsing the per-line "who changed this last" history past the copy and obfuscate who wrote what and when.

    (why the downvote?)

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 4 months ago* (1 child)

    Interesting. Yeah, sounds like what git blame -C is for, so I've never made copies when splitting files, I've just moved lines between files naively. But I guess if one's tools are limited and doesn't have the ability to -C, then I guess I could respect the hack that is that solution?

    I mean, I'm 99% sure git doesn't store blame or authorship info in the pack files, even as a convenience cache, and just guesses by traversing the patch log with heuristics live when you run blame anyway, so the history mostly doesn't matter there, but the way you've done it does seem to have tricked the heuristics into doing what you want without relying on an option, so that's neat! It's an interesting hack, and I like interesting hacks 😛

    By the way, if there are down votes, they're not from me!

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 4 months ago* (last edited 4 months ago) (1 child)

    I'm not a copyright-lawyer, but I think there are implications on who has authored the code, so preserving this detail can be important. The fancy copy reduced my blame by +90% on the final result.

    git blame output can be affected by e.g. ignoring white-space changes.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 4 months ago

    Right, but what I'm saying is that git doesn't store authorship information or line-by-line history, no matter how it's done. Figuring out which line came from where is an algorithm the git blame command does every time you request it, and that algorithm can give different results depending on which options you give the blame command. And so what you've found here is a collection of commits that produces a situation the default blame algorithm can follow, without any optional flags, which is neat! Maybe not great for git history, but neat!

  • permalink
  • fedilink
  • source
  • parent
  • [–] 1 point 4 months ago

    I can come up with some contrived examples. Maybe someone screwed up the history and they're trying to repair it such that no one needs to worry about a rebase on their next pull? "compliance"/legal/cya reasons? I also wish to know!

  • permalink
  • fedilink
  • source
  • parent