Hi, While in this case you have only added (almost) one character, it is rather a minimalistic case without any substantial content.
(one file, one character, perhaps EOL for commit 1; two extra characters for commit 2) In realistic cases there are usually multiple change hunks, often across a few files, though yes, the beautiful case is the one line solution. But to reach the possibility of such beautiful solutions one does need many thousands of lines of code (and comment) already added/committed. Ultimately, the core Git was designed for the maintenance activities of Linus Torvalds, who, it would seem, felt that this method was a necessity for his [the LInux way (TM)] of preparing and selecting code. He needed to pull apart larger patches into smaller, easier to understand steps, hence the need to selectively add portions to the commit sequence. Git is optimised for small commits, so that all the incremental patch merges become small and easy. Git avoids serial numbers. Git uses 'blockchain' verification of integrity. Unfortunately, Git's metal model is different" from classic expectations, as you have seen. This is totally the opposite of how change management used to be, where 'protecting the master' was the prime role of management, so they built up large backlogs of changes and had a 'merge hell' stage where they finally tested all the chan ges together and they commonly didn't work. This is a technique that has been inherited from classical engineering drawing practice (e.g. `prints` that were blue, made from *tracings *of rarely touched precious master drawings, with equipment 'fixed on site'). Previous software VCS inherited most of that engineering practice without appreciating how/why it was that was, and which of the old limitations were no longer valid. Linus just had the opportunity to slay the old dragon / cut the Gordian knot. On Saturday, November 23, 2019 at 8:43:10 AM UTC, UWE RICHARD OTTO BRAUER wrote: > > > > On 2019-11-21, at 12:44 AM, Uwe Brauer <o...@mat.ucm.es <javascript:>> > wrote: > > > > Maybe this idea will help you understand. > > > Git maintains a "potential next commit" at all times. This is called > the index, or staging area. > > > > > The "add" command is used to put something into the potential next > commit. > > Well in the previous response I understand that this makes sense, if > there is choice, because say several lines in a file have been changed > and I might want to pick only a few of them, but if there is only *one* > change? > > See my example script > > git init > echo 1 > 1 > git add 1 > git commit -m 1 > echo 1.1 > 1 > git add . > # git add . Is needed because two actions were done: add a file > # add a line to file. > git commit -m 1.1 > echo 1.2 > 1 > #git add . > # now I am puzzled there is only *one* change, adding a line to file, so > # there is nothing to chose, while if I had added several lines, there > # would be choice, so I don't understand git add . here > git commit -m 1.2 > echo 1.2.1 > 1 > #git add . > # Same doubt > git commit -m 1.2.1 > > > > Commit in turn just copies that potential next commit into a > long-term store. > -- 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/72ca14c9-e24a-487e-9c56-ea07b24faef6%40googlegroups.com.
