# Re: [PATCH] Stop telling users we are 'defaulting to local storage area'.

5 messages from 2006-12-14 to 2006-12-19. Participants: Shawn Pearce, Shawn O. Pearce, Jakub Narebski, David Lang, Nicolas Pitre.
Thread: https://gitlist.dev/t/43402

## Shawn O. Pearce, 2006-12-14 23:09

Subject: [PATCH] Stop telling users we are 'defaulting to local storage area'.
Message-ID: <20061214230902.GA26506@spearce.org>
URL: https://gitlist.dev/e/20061214230902.GA26506%40spearce.org

```
Back in the old days of Git when people messed around with their
GIT_DIR environment variable more often it was nice to know whether
or not git-init-db created a .git directory or used GIT_DIR.

But now that we are making excuses in the documentation about why
this message gets printed by git-init-db we should just remove it
entirely.  It doesn't really help the user to understand what just
happened.  It also breaks from our normal behavior of not printing
anything if the command was successful.

Suggested by Andy Parkins in his Git 'niggles' list
(<200612132237.10051.andyparkins@gmail.com>).

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
 Documentation/core-tutorial.txt |   14 +++-----------
 Documentation/tutorial-2.txt    |    1 -
 Documentation/tutorial.txt      |    6 ------
 builtin-init-db.c               |    4 +---
 4 files changed, 4 insertions(+), 21 deletions(-)

diff --git a/Documentation/core-tutorial.txt b/Documentation/core-tutorial.txt
index 47505aa..f90c66c 100644
--- a/Documentation/core-tutorial.txt
+++ b/Documentation/core-tutorial.txt
@@ -54,17 +54,9 @@ $ cd git-tutorial
 $ git-init-db
 ------------------------------------------------
 
-to which git will reply
-
-----------------
-defaulting to local storage area
-----------------
-
-which is just git's way of saying that you haven't been doing anything
-strange, and that it will have created a local `.git` directory setup for
-your new project. You will now have a `.git` directory, and you can
-inspect that with `ls`. For your new empty project, it should show you
-three entries, among other things:
+You will now have a `.git` directory, and you can inspect that with
+`ls`. For your new empty project, it should show you three entries,
+among other things:
 
  - a file called `HEAD`, that has `ref: refs/heads/master` in it.
    This is similar to a symbolic link and points at
diff --git a/Documentation/tutorial-2.txt b/Documentation/tutorial-2.txt
index 6389de5..f7f2e1c 100644
--- a/Documentation/tutorial-2.txt
+++ b/Documentation/tutorial-2.txt
@@ -18,7 +18,6 @@ Let's start a new project and create a small amount of history:
 $ mkdir test-project
 $ cd test-project
 $ git init-db
-defaulting to local storage area
 $ echo 'hello world' > file.txt
 $ git add .
 $ git commit -a -m "initial commit"
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
index 02dede3..88ace3b 100644
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -35,12 +35,6 @@ $ cd project
 $ git init-db
 ------------------------------------------------
 
-Git will reply
-
-------------------------------------------------
-defaulting to local storage area
-------------------------------------------------
-
 You've now initialized the working directory--you may notice a new
 directory created, named ".git".  Tell git that you want it to track
 every file under the current directory with (notice the dot '.'
diff --git a/builtin-init-db.c b/builtin-init-db.c
index 235a0ee..405b9a1 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -274,10 +274,8 @@ int cmd_init_db(int argc, const char **argv, const char *prefix)
 	 * Set up the default .git directory contents
 	 */
 	git_dir = getenv(GIT_DIR_ENVIRONMENT);
-	if (!git_dir) {
+	if (!git_dir)
 		git_dir = DEFAULT_GIT_DIR_ENVIRONMENT;
-		fprintf(stderr, "defaulting to local storage area\n");
-	}
 	safe_create_dir(git_dir, 0);
 
 	/* Check to see if the repository version is right.
-- 

```

## Nicolas Pitre, 2006-12-15 02:18

Subject: Re: [PATCH] Stop telling users we are 'defaulting to local storage area'.
Message-ID: <Pine.LNX.4.64.0612142059301.18171@xanadu.home>
URL: https://gitlist.dev/e/Pine.LNX.4.64.0612142059301.18171%40xanadu.home
In-Reply-To: <20061214230902.GA26506@spearce.org>

```
On Thu, 14 Dec 2006, Shawn O. Pearce wrote:

[...]
> It also breaks from our normal behavior of not printing
> anything if the command was successful.

Before everybody starts believing  everybody agrees with this I'll have 
to throw a tile in the pond.

I really don't think this is a good rule.

NOte that I'm not against commands that are silent by default.  I really 
think that git-add should remain silent on success by default when 
successful.

But the rule of thumb should be about the importance of the action 
performed by the command.  git-add is a less important command than 
git-init-db or git-commit _conceptually_.  You can do multiple git-add 
in whatever order, even repeatedly, and it won't change the outcome.  
It is "conceptually lightweight".  But git-init-db is really important.  
Without it you just can't do anything. It should give the user the 
impression that something did actually happen, especially since this is 
the git comand any new git user is most likely to use first.  Saying 
back "git repository initialized" tells the user "OK you can start now".  
Saying nothing might just leave the user wondering if everything is 
actually fine.



```

## Shawn Pearce, 2006-12-15 02:25

Subject: Re: [PATCH] Stop telling users we are 'defaulting to local storage area'.
Message-ID: <20061215022543.GL26202@spearce.org>
URL: https://gitlist.dev/e/20061215022543.GL26202%40spearce.org
In-Reply-To: <Pine.LNX.4.64.0612142059301.18171@xanadu.home>

```
Nicolas Pitre <nico@cam.org> wrote:
> On Thu, 14 Dec 2006, Shawn O. Pearce wrote:
> > It also breaks from our normal behavior of not printing
> > anything if the command was successful.

> I really don't think this is a good rule.
> 
> NOte that I'm not against commands that are silent by default.  I really 
> think that git-add should remain silent on success by default when 
> successful.
> 
> But the rule of thumb should be about the importance of the action 
> performed by the command.
> But git-init-db is really important.  

A very reasonable argument, butchered for my evil quoting needs.  :-)

If we want to keep letting git-init-db output something, then
the output should be a lot more meaningful to the average English
speaking new Git user than "defaulting to local storage area".

E.g.:

  $ git init-db
  Initialized empty Git repository in .git/

would probably make a lot more sense to new and expert users alike.
I'm fine with the above form, I just think that the message we have
now could benefit from being sent to the land from which there is
no return, or be rewritten...

BTW, I almost also submitted a patch to remove the "Committing
initial tree ..." message in git-commit-tree, but thought twice about
it as committing an initial tree is sort of an important difference
from normal activity that we should highlight it somehow...

-- 

```

## Jakub Narebski, 2006-12-15 14:10

Subject: Re: [PATCH] Stop telling users we are 'defaulting to local storage area'.
Message-ID: <elua7a$v7q$1@sea.gmane.org>
URL: https://gitlist.dev/e/elua7a%24v7q%241%40sea.gmane.org
In-Reply-To: <20061214230902.GA26506@spearce.org>

```
Shawn O. Pearce wrote:

> Back in the old days of Git when people messed around with their
> GIT_DIR environment variable more often it was nice to know whether
> or not git-init-db created a .git directory or used GIT_DIR.
> 
> But now that we are making excuses in the documentation about why
> this message gets printed by git-init-db we should just remove it
> entirely.  It doesn't really help the user to understand what just
> happened.  It also breaks from our normal behavior of not printing
> anything if the command was successful.
> 
> Suggested by Andy Parkins in his Git 'niggles' list
> (<200612132237.10051.andyparkins@gmail.com>).

Perhaps we should print something _if_ GIT_DIR is set, then?

>        * Set up the default .git directory contents
>        */
>       git_dir = getenv(GIT_DIR_ENVIRONMENT);
> -     if (!git_dir) {
> +     if (!git_dir)
>               git_dir = DEFAULT_GIT_DIR_ENVIRONMENT;
> -             fprintf(stderr, "defaulting to local storage area\n");
> -     }
>       safe_create_dir(git_dir, 0);
>  

I'd rather leave block, even if it consist now of single statement.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git


```

## David Lang, 2006-12-19 19:48

Subject: Re: [PATCH] Stop telling users we are 'defaulting to local storagearea'.
Message-ID: <Pine.LNX.4.63.0612191147300.18007@qynat.qvtvafvgr.pbz>
URL: https://gitlist.dev/e/Pine.LNX.4.63.0612191147300.18007%40qynat.qvtvafvgr.pbz
In-Reply-To: <Pine.LNX.4.64.0612142059301.18171@xanadu.home>

```
On Thu, 14 Dec 2006, Nicolas Pitre wrote:

> On Thu, 14 Dec 2006, Shawn O. Pearce wrote:
>
> [...]
>> It also breaks from our normal behavior of not printing
>> anything if the command was successful.
>
> Before everybody starts believing  everybody agrees with this I'll have
> to throw a tile in the pond.
>
> I really don't think this is a good rule.
>
> NOte that I'm not against commands that are silent by default.  I really
> think that git-add should remain silent on success by default when
> successful.
>
> But the rule of thumb should be about the importance of the action
> performed by the command.  git-add is a less important command than
> git-init-db or git-commit _conceptually_.  You can do multiple git-add
> in whatever order, even repeatedly, and it won't change the outcome.
> It is "conceptually lightweight".  But git-init-db is really important.
> Without it you just can't do anything. It should give the user the
> impression that something did actually happen, especially since this is
> the git comand any new git user is most likely to use first.  Saying
> back "git repository initialized" tells the user "OK you can start now".
> Saying nothing might just leave the user wondering if everything is
> actually fine.

how about makeing it silent on sucess unless the output is a tty? that way you 
don't mess up scripts with the 'it worked' message and you still reassure the 
user that something actually happened.

David Lang

```
