7 ms·

git mv?

kadoban 4y ago
That's just a convenience command. Git doesn't actually record moves as anything different from a delete and an add. Many of the querying commands (eg `git log`) use heuristics to show moved files, but they end up wrong fairly often, especially if you don't mess with the parameter(s) of the heuristics.
- saxonww 4y ago
  In my experience they are correct all of the time for simple renames. It's when you move a file and make substantial edits that it gets confused. I think it's reasonable to argue that git shouldn't get confused in this scenario, but you could also do your renames in one commit and your changes in another.
  - Akronymus 4y ago
    Would it make sense to make one commit for the move and one for the changes?
    - bloak 4y ago
      Yes, in some cases, but it depends on your workflow. Some projects require each commit on the main branch to be fully working and pass all the tests.
    - jraph 4y ago
      I wish I didn't have to think about it and git supported file renaming properly so a unit of change that hasn't much sense when it is split can stay a unit, but without it yes, I think it makes sense to commit renames separately so history can be tracked more easily. I think git can be configured on how hard it tries to find renames from similarity between a deleted file and an added file.
    - tsimionescu 4y ago
      No, because you often have to make changes to the file to get it to compile after loving to a new location. It's much more annoying to review history with changes that can't possibly compile.
      - kadoban 4y ago
        This isn't necessarily an issue, depending on what you mean by "review". The one case I really run into is bisects, but even for that you can tell it to just skip commits that won't build.
    - kruador 4y ago
      No, it makes no difference. Git doesn't look at the full history when performing a merge, it just looks for similarity between the paths and files in the commits being merged, and the common base commit (which you can discover by running `git merge-base`). It doesn't keep any metadata about whether something was a move: as far as the actual data structures are concerned, you deleted file a/b/c and added file d/e/f, that have the same file content hash. You can find more information on how Git now does it at https://blog.palantir.com/optimizing-gits-merge-machinery-1-127ceb0ef2a1 https://blog.palantir.com/optimizing-gits-merge-machinery-1-... . I think this first started to be released in v2.31.0, and completed in v2.33.0. v2.34.0 switched the default merge strategy to the new 'ort' strategy mentioned in that blog.
      - avar 4y ago
        The "git log" "follow renames" logic isn't the same as conceptually related merge logic. I think there are unfortunately still cases where what the GP is suggesting improves the UX, i.e. I think some shortcuts are taken when following a file if the content doesn't change. IIRC this matters particularly for very large renames, at some point during revision walking we'll give up trying to match your A.txt to B.txt, but if they're the same...
  - shikoba 4y ago
    > It's when you move a file and make substantial edits that it gets confused. It's your POV that it's the same file. One could argue that it's a new file and the content of the old one embed in the file. That's the huge problem with git users, people cling desperately to the idea of changes, when git is just about snapshots.
    - tsimionescu 4y ago
      People "cling desperately" to the way they are actually working. That Git uses an alien model that happens to somewhat match what I'm doing doesn't mean I'm "desperately clinging" to the actual reality of what I'm doing (editing a file).
      - shikoba 4y ago
        So if someone creates a new file and integrate the content of the old file to reach the same folder state than yours, you think s/he does something different?
        tsimionescu 4y ago
        Yes? Editing a file is different from creating a new file with some code copied from somewhere else, obviously. They may reach the same end state, but that doesn't make them the same operation. It also happens that one is much, much more common in software development than the other, so it's a much better mental model of what SEs do.
        shikoba 4y ago
        > They may reach the same end state, but that doesn't make them the same operation. So you're clinging to your mental model. Thanks for proving my point.
        tsimionescu 4y ago
        This is how work is actually done, and my mental model matches how I and my colleagues and yours as well actually work. I could contort my mental model to make it match how Git works, but it is a contortion that some tool imposes on me. We work in computing, I would expect everyone's mental models to be computational, not equational - different algorithms with the same result are still different. QuickSort is not the same as Merge sort just because they have the same inputs and outputs.
dotancohen 4y ago
Internally just rms and adds. The "Rename" feature is just a UI feature displayed when the files have identical or near-identical content.

git mv?

That's just a convenience command. Git doesn't actually record moves as anything different from a delete and an add. Many of the querying commands (eg `git log`) use heuristics to show moved files, but they end up wrong fairly often, especially if you don't mess with the parameter(s) of the heuristics.

saxonww 4y ago
In my experience they are correct all of the time for simple renames. It's when you move a file and make substantial edits that it gets confused. I think it's reasonable to argue that git shouldn't get confused in this scenario, but you could also do your renames in one commit and your changes in another.
- Akronymus 4y ago
  Would it make sense to make one commit for the move and one for the changes?
  - bloak 4y ago
    Yes, in some cases, but it depends on your workflow. Some projects require each commit on the main branch to be fully working and pass all the tests.
  - jraph 4y ago
    I wish I didn't have to think about it and git supported file renaming properly so a unit of change that hasn't much sense when it is split can stay a unit, but without it yes, I think it makes sense to commit renames separately so history can be tracked more easily. I think git can be configured on how hard it tries to find renames from similarity between a deleted file and an added file.
  - tsimionescu 4y ago
    No, because you often have to make changes to the file to get it to compile after loving to a new location. It's much more annoying to review history with changes that can't possibly compile.
    - kadoban 4y ago
      This isn't necessarily an issue, depending on what you mean by "review". The one case I really run into is bisects, but even for that you can tell it to just skip commits that won't build.
  - kruador 4y ago
    No, it makes no difference. Git doesn't look at the full history when performing a merge, it just looks for similarity between the paths and files in the commits being merged, and the common base commit (which you can discover by running `git merge-base`). It doesn't keep any metadata about whether something was a move: as far as the actual data structures are concerned, you deleted file a/b/c and added file d/e/f, that have the same file content hash. You can find more information on how Git now does it at https://blog.palantir.com/optimizing-gits-merge-machinery-1-127ceb0ef2a1 https://blog.palantir.com/optimizing-gits-merge-machinery-1-... . I think this first started to be released in v2.31.0, and completed in v2.33.0. v2.34.0 switched the default merge strategy to the new 'ort' strategy mentioned in that blog.
    - avar 4y ago
      The "git log" "follow renames" logic isn't the same as conceptually related merge logic. I think there are unfortunately still cases where what the GP is suggesting improves the UX, i.e. I think some shortcuts are taken when following a file if the content doesn't change. IIRC this matters particularly for very large renames, at some point during revision walking we'll give up trying to match your A.txt to B.txt, but if they're the same...
- shikoba 4y ago
  > It's when you move a file and make substantial edits that it gets confused. It's your POV that it's the same file. One could argue that it's a new file and the content of the old one embed in the file. That's the huge problem with git users, people cling desperately to the idea of changes, when git is just about snapshots.
  - tsimionescu 4y ago
    People "cling desperately" to the way they are actually working. That Git uses an alien model that happens to somewhat match what I'm doing doesn't mean I'm "desperately clinging" to the actual reality of what I'm doing (editing a file).
    - shikoba 4y ago
      So if someone creates a new file and integrate the content of the old file to reach the same folder state than yours, you think s/he does something different?
      - tsimionescu 4y ago
        Yes? Editing a file is different from creating a new file with some code copied from somewhere else, obviously. They may reach the same end state, but that doesn't make them the same operation. It also happens that one is much, much more common in software development than the other, so it's a much better mental model of what SEs do.
        shikoba 4y ago
        > They may reach the same end state, but that doesn't make them the same operation. So you're clinging to your mental model. Thanks for proving my point.
        tsimionescu 4y ago
        This is how work is actually done, and my mental model matches how I and my colleagues and yours as well actually work. I could contort my mental model to make it match how Git works, but it is a contortion that some tool imposes on me. We work in computing, I would expect everyone's mental models to be computational, not equational - different algorithms with the same result are still different. QuickSort is not the same as Merge sort just because they have the same inputs and outputs.

dotancohen 4y ago

Internally just rms and adds. The "Rename" feature is just a UI feature displayed when the files have identical or near-identical content.