Is it normal to need that level of understanding of the inner machinery of a software to use it?
Given that we're still figuring out new ways to use rocks, maybe?
Commits are shapshots, not diffs
11–20 of 154 posts
Re: Commits are shapshots, not diffs
#12Is it normal to need that level of understanding of the inner machinery of a software to use it?
1. It is normal, as in, it's common.
2. Personally, I think this just shows how primitive our industry still is.
Re: Commits are shapshots, not diffs
#13I have never understood cherry-pick for this very reason. This helps, but I'm still confused. > The git cherry-pick command creates a new commit with an identical diff to whose parent is the current commit. How can two diffs ever be considered equivalent when they include a changed file that had different starting contents? Can they?
If I have a 100-line file and on 'main' it changes near the top, but in my 'topic' branch it changes near the bottom, then I can cherry-pick 'topic' onto 'main' and Git will resolve the diff correctly. The resulting diff or patch would only change in the line numbers for the context of the diff. This is of course a very simple example. You might hit a conflict in your "git cherry-pick" command which gives you an oppo…
I kind of intuitively get it, but that doesn't really seem well defined. I'm always a little bit spooked that `cherry-pick` will cleanly apply when it really shouldn't have. It's not clear to me under which circumstances it automatically resolves.
Re: Commits are shapshots, not diffs
#14I have never understood cherry-pick for this very reason. This helps, but I'm still confused. > The git cherry-pick command creates a new commit with an identical diff to whose parent is the current commit. How can two diffs ever be considered equivalent when they include a changed file that had different starting contents? Can they?
You're right that the commit produced by the cherry-pick operation won't be identical to the commit being cherry-picked. It's the diffs that are identical, not the final result. It's analogous to how the difference between 5 and 15 is equal to the difference between 105 and 115.
That doesn't help. The result of subtraction is defined to be a number.
The result of a diff is... a nebulously defined concept that somehow describes the changes. It's not clearly (to me) defined which parts of the files are considered to part of the diff and which parts are to be excluded.
Re: Commits are shapshots, not diffs
#15Git is the leakiest abstraction in the history of abstractions. Diffs are a "natural" object for version control yet got doesn't actually use them and as we can see in this article, multiple git commands leak this implementation detail.
I'd argue that diffs in the presence of renames aren't natural, and git handles them better than other version control systems.
That is, git is content-based and not named-based. Name-based systems explicitly track renames with metadata; git does not. git calculates renames dynamically based on content.
Re: Commits are shapshots, not diffs
#16Conceptually, a git commit is a snapshot. Simple as that. The user doesn't need to worry about how git manages its data internally. > I believe that Git becomes understandable if we peel back the curtain and look at how Git stores your repository data. This strikes me as misleading in the same way this StackOverflow answer [0] is misleading. In terms of how git stores data, commits are not always snapshots. Internall…
[deleted]
Re: Commits are shapshots, not diffs
#17Git is the leakiest abstraction in the history of abstractions. Diffs are a "natural" object for version control yet got doesn't actually use them and as we can see in this article, multiple git commands leak this implementation detail.
I'd argue that diffs in the presence of renames aren't natural, and git handles them better than other version control systems. That is, git is content-based and not named-based. Name-based systems explicitly track renames with metadata; git does not. git calculates renames dynamically based on content.
> I'd argue that diffs in the presence of renames aren't natural
That is true, at least for the text-based diff(1) formats, though obviously nothing precludes extending the format, or even using something else entirely (aside from the risk of not being compatible with diff(1), but then you could always present diff(1) compatible diffs externally and use something richer internally, for instance).
> git handles them better than other version control systems.
But that is not.
> That is, git is content-based and not named-based. Name-based systems explicitly track renames with metadata; git does not. git calculates renames dynamically based on content.
And as a result regularly fucks up tracking renames, or plain refuses to do it without nonsensical workarounds if you copied or moved a file and modified it in the same commit. It also makes browsing histories, blaming, or tracking merges through renames incredibly expensive.
Re: Commits are shapshots, not diffs
#18I have never understood cherry-pick for this very reason. This helps, but I'm still confused. > The git cherry-pick command creates a new commit with an identical diff to whose parent is the current commit. How can two diffs ever be considered equivalent when they include a changed file that had different starting contents? Can they?
> How can two diffs ever be considered equivalent when they include a changed file that had different starting contents? Can they?
In darcs, patches commute. It works nicely sometimes!
Re: Commits are shapshots, not diffs
#19I have never understood cherry-pick for this very reason. This helps, but I'm still confused. > The git cherry-pick command creates a new commit with an identical diff to whose parent is the current commit. How can two diffs ever be considered equivalent when they include a changed file that had different starting contents? Can they?
You're right that the commit produced by the cherry-pick operation won't be identical to the commit being cherry-picked. It's the diffs that are identical, not the final result. It's analogous to how the difference between 5 and 15 is equal to the difference between 105 and 115.
> It's analogous to how the difference between 5 and 15 is equal to the difference between 105 and 115.
Patches are torsors? :o
Re: Commits are shapshots, not diffs
#20This is why I'm really excited about the potential of Pijul. In pijul, commits are diffs, and you avoid all of the rebase/cherry-picking craziness of Git.
Still alpha software, so tons of roughs edges, but the potential is incredible. I think it'll be similar to the centralized -> distributed revolution that git ushered in.