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/20211013093221.bfy2l6oqqsrbd7i7%40carbon.
