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.

Reply via email to