threads / patch / 43402

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

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

## tl;dr

5 messages between Dec 14, 2006 and Dec 19, 2006. Diffs are folded; open one to read it.

replies: 4people: 4as markdown or json

Shawn O. Pearce· Dec 14, 2006, 23:09 UTC · lore

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

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(-)
Show changes to 4 files +4 −17

Documentation/core-tutorial.txt, Documentation/tutorial-2.txt, Documentation/tutorial.txt, builtin-init-db.c

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· Dec 15, 2006, 02:18 UTC · re: Shawn O. Pearce · lore
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· Dec 15, 2006, 02:25 UTC · re: Nicolas Pitre · lore
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.
Show 9 quoted lines
> 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...

David Lang· Dec 19, 2006, 19:48 UTC · re: Nicolas Pitre · lore

Re: [PATCH] Stop telling users we are 'defaulting to local storagearea'.

On Thu, 14 Dec 2006, Nicolas Pitre wrote:
Show 26 quoted lines
> 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
Jakub Narebski· Dec 15, 2006, 14:10 UTC · re: Shawn O. Pearce · lore
Shawn O. Pearce wrote:
Show 12 quoted lines
> 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?
Show 10 quoted lines
>        * 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

← back to recent threads