I (as an older engineer) like to compare the 'staging area' (aka index / cache) to the old style 'outbox' one may have had on ones desk or in the corner of the office where we would place completed paper memos for collection later. It gave us chance to carefully collate groups of memos, or amend memo's completed a bit earlier before the secretary/mail-person came to collect and file the results.
It does take a bit to get to used to, especially if you had a 'file at a time' process that was copied from working on the drawings for the ark (yes almost all the configuration management processes are based on handling paper [kaolin & linen] drawings with india ink markings - unique masterpieces). Perfect and instant replication by computers is slowly changing that but people are generations behind! The think I like about Git is that I get control of what I store locally, and don't need permission/authority to store stuff in a version 'control' system. It's now validation & verification by hash id that counts , not controlled access to the repository. The design philosophy of Git is that everyone must be able to choose and make commits as they please, and that the object store will hold all the temporary artefacts, protected by hash values. So the object store has both the 'repository' and all those temporary artefacts. Neat and efficient. On Wednesday, October 13, 2021 at 10:32:27 AM UTC+1 Konstantin Khomoutov wrote: > On Tue, Oct 12, 2021 at 11:48:55PM -0700, Everett Simpson wrote: > > > I was curious, what is the design philosophy behind having the "add" > > command, as opposed to just committing everything in the repository? Is > > that so people can have private files on their end? Or because it allows > > you to keep track one by one, while you are working on a project, of > which > > files you want to push, because they are finished? > > I can provide certain insight from a programmer's standpoint. > > When you're working on implementing a feature or fixing a bug the files of > your project most of the time tend to end up in a situation where they > contain > multiple tangled, intertwined changes of which each would be implemented > separately - *if the developer would be able to look into a crystal ball > and > see the future.* The Git's feature of having the so-called "staging area" > which is a virtual space allowing you to construct a state you'd like to > commit allows to turn a usual mess of changes into a string of atomic > changes > following one another logically. > > Why is this needed? Because - as a very useful saying goes - «programs are > meant to be read by humans and only incidentally for computers to execute», > and the history of changes to a computer program kept in a version control > system merely adds another dimension to this approach: when another > developer > later has to understand why such and such bit of code had appeared in a > program they're tasked to modify, it's much better when they are able to > dig > up the change history to a minimal, logical, well-explained change, > surrounded > by the changes which have the same properties. > > Sure, `git add` is just an aid for creating good history of changes, and it > sometimes does not cut it alone - one then should apply, say, interactive > rebasing etc. > > Please note that what I presented is just describing one particular area > where > Git is used - though admittedly the most wide one, - and of course I might > well think of other applications where bypassing the staging area is just > the > most sensible thing to do. > > > Are there any alternatives to Git which only have a "push" command, and > > push all the files in the repo to the other branches? > > Sure. The most visible one is filesystem synchronization solutions such as > rsync, unison, rclone, SyncThing, various tools supplied by cloud storage > vendors such as DropBox, Google Disk etc. > > The idea is that when you do not care about what comes in a change set, > then > there might be no sense to have change sets in the first place, and just > have > "remote replicas" of your project. In other words, you might just not need > a > VC system to begin with. > > A to using a VC system the way you want, any would fit the bill, actually: > nothing prevents you from having a Git alias (or a no-brainer shell script) > which instructs Git to just put everything which is modified to the staging > area, commit and push. I mean, there's no need to have a specially-designed > system to get this behaviour: it's absolutely possible to dumb down a > flexible > system in any way you need. > > $ git add -A > $ git commit -m "Change at `date`" > $ git push origin HEAD > > is a way to have all the changes added, committed and pushed in three > commands > which ask no questions. Make a script of them and you're golden. > > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/829bb3e5-dd0b-4804-b671-10b2ee2a709fn%40googlegroups.com.
