4 ms·
As a user, I see absolutely no reason to know the internal workings of Git. It supposedly offers a service, which is tracking and recording changes to files. In
by zoomablemind 5y ago
As a user, I see absolutely no reason to know the internal workings of Git. It supposedly offers a service, which is tracking and recording changes to files. In a way, it's a very able SaveAs/Open command and also offering some way of altering the recorded history.
How it's done internally, as much as it's remarkable, is just an implementation detail. The fact that users are repeatedly being referred to docs/books, points to conceptual inconsistencies or mismatches in the intended application contexts.
As a user I operate with directories and files. Now version control also introduces a time-component, which is versions (and version of a version aka branch) and some kind of history/timeline/journal/log.
Why would a branch have a "head" and "base", isn't parent/child concept expressive already? Why "ref", if we've got "version" already? Why "stage", "index", "cache"? Why "cherry-pick" if we've got "patch"? Etc.
- shxdow 5y agoOne reason why you would want to know how Git internally works is to make a better use of it. The interface it exposes is relatively low level and as such suffers when uses don't understand how the software internally operates. If anything, used being repeatedly pointed to docs shows the lack of understanding of Git's inner workings.