Thanks a lot for this very informative answer. I will read a good Git book.
2014-12-13 18:17 GMT+01:00 Konstantin Khomoutov < flatw...@users.sourceforge.net>: > > On Fri, 12 Dec 2014 21:51:09 +0100 > "s.cel...@gmail.com" <s.cel...@gmail.com> wrote: > > > $ git version > > git version 2.2.0 > > > > type again > > $ git add -v foo.txt > > no message will display > > > > with verbose flag we could have a message similar to SVN > > > > svn: warning: W150002: 'foo.txt' is already under version control > > svn: E200009: Could not add all targets because some targets are > > already versioned > > svn: E200009: Illegal target for the requested operation > > > > I know Git is not SVN... > > > > but displaying "warning: 'foo.txt' is already under version control" > > will be a good reminder > > > > if I have 2 files foo.txt and bar.txt > > I first git add -v foo.txt > > then I need to git add -v bar.txt > > but I did a mistake and type again > > git add -v foo.txt > > git will give me an warning message > > so I could notice that I was wrong > > Oh, I'm afraid you have gross misunderstanding of how Git works > (compared to Subversion). In Subversion, "adding" a file means adding > it to version control -- that is, the file which was untracked becomes > tracked. You then use `svn commit` to commit all the changes which are > there in the work tree or `svn commit fileA fileB ...` to only commit > changes in fileA, fileB etc. Contrary to this, Git uses "staging" > approach to committing: when you run `git commit` (without the -a, -A > or -u command-line options), the commit is created from the so called > "staging area" (also known as "the index"); `git add fileA` adds -- > "stages" -- *changes* present in the file fileA so that they will be a > part of the commit created the next time `git commit` is run. > Adding a file under version control is just a byproduct of adding the > file's changes to the staging area. I mean, Git really does not have a > dedicated "add this file to version control" operation. This means > a warning message like that in Subversion simply cannot exist in Git > as it does not have a concept to which that warning applies. > > Now I can see why you don't see anything when attempting to `git add -v` > a file whose content did not change since the last `git add` had been > run for it: > > ~% git init /tmp/foo > Initialized empty Git repository in /tmp/foo/.git/ > ~% cd /tmp/foo > foo% touch foo.txt > foo% git add -v foo.txt > add 'foo.txt' > foo% echo bang >foo.txt > foo% git add -v foo.txt > add 'foo.txt' > foo% git add -v foo.txt > foo% > > As you can see, the `git add -v` command printed it "added" the file > two times out of three: the first time the file wasn't yet tracked, so > `git add` staged the file's contents (this obviously counts as a change > -- the size of the whole file), and the second time -- after the file's > contents changed. The third time it printed nothing since the file's > contents did not change, and hence the command did nothing. > > To recap, the meaning of `git add -v` mentioning the file in its output > means the file's contents had been staged. If you wonder why this > might be at all useful, consider `git add`-ing a bunch of files using > either a wildcard, like '*', or just '.' meaning the current directory > -- in this case `git add` would only print the names of the files > it incorporated changes from, skipping the rest: ignored files and > files which did not changed compared to the staging area. > > > I also would like to define git to display verbose message by default > > (without this -v flag) > > is there a config file for this ? > > No idea. Run `git help config` and try to search for the word > "verbose". In any case you can use a git alias, like > > git config --add alias.vadd 'add -v' > > and now you can do `git vadd file...`. > > But before you do that... > > I would strongly advise you to start with a good book on Git *before* > you will embark on using it in production: way too many people assume > that once they know some version control system, they know how version > control works. This is wrong. Git in many ways is radically different > from Subversion, and I'm not referring to to different meaning of the > same-named commands but rather differences in the underlying concepts > and approaches. Hence I advise you to save yourself from possible > future pain in the neck and learn the Git's concepts and approaches up > front. > -- 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. For more options, visit https://groups.google.com/d/optout.
