Re: A tour of git: the basics (and notes on some unfriendly messages)

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Sep 29, 2007, 00:49 UTC
Message-ID: <Pine.LNX.4.64.0709290144310.28395@racer.site>
In-Reply-To: <20070929000056.GZ3099@spearce.org>

Hi,

On Fri, 28 Sep 2007, Shawn O. Pearce wrote:

> On Cygwin we have man, so `git help init` (or `git init --help`) work 
> just fine to display the manual entry.  No idea about the MSYS port.

We open the html pages. That is, we don't yet, since we do not generate the html pages just yet; asciidoc is a Python program, and Python is not available as an MSys program as far as I know (and asciidoc insists on finding files in a Unix-like file structure, so we _do_ need an MSys Python).

... but all this would be easier if we succeeded in having a minimal asciidoc lookalike in git.git...

Show 17 quoted lines

> >   * The output from a git-clone operating locally is really confusing:
> > 
> > 	$ git clone hello hello-clone
> > 	Initialized empty Git repository in /tmp/hello-clone/.git/
> > 	0 blocks
> > 
> >     Empty? Didn't I just clone it? What does "0 blocks" mean?
> 
> Yea.  That's because we realized its on the local disk and used
> `cpio` with hardlinks to copy the files.  So cpio says it copied
> 0 blocks as it actually just hardlinked everything for you.  No
> data was actually copied.
> 
> git-gui's new clone UI uses fancy progress meters here and tries
> to shield the user from "plumbing and UNIX tools" spitting out
> seemingly nonsense messages.  We probably should try harder in
> git-clone to do the same here.

AFAICT git-clone is a prime candidate for builtinification, after which issues like this should be easy to address.

Show 11 quoted lines

> >   * git-log by default displays "Date" that is the author date, but
> >     also only uses committer date for options such as --since. This is
> >     confusing.
> 
> I've never thought about that.  But when you say it I think its very 
> obvious that it could be confusing to a new user.  Maybe we should show 
> the committer line and its date if it doesn't match the author 
> name/date.  Usually I don't care who committed a change in git.git (its 
> a very small handful of people that Junio pulls from directly) but at 
> day-job committer name is usually just as interesting as the author name 
> *when they aren't the same*.

--pretty=fuller

Ciao, Dscho