Re: [RFC/PATCH] git-fetch: mega-terse fetch output
- From
Sam Ravnborg <sam@ravnborg.org>
- Date
- Oct 19, 2007, 17:26 UTC
- Message-ID
- <20071019172610.GE30825@uranus.ravnborg.org>
- In-Reply-To
- <alpine.LFD.0.9999.0710191211210.19446@xanadu.home>
On Fri, Oct 19, 2007 at 12:12:41PM -0400, Nicolas Pitre wrote:
Show 24 quoted lines
> On Fri, 19 Oct 2007, Steven Grimm wrote: > > > On 19/10/2007, Jeff King <peff@peff.net> wrote: > > > This makes the fetch output much more terse. It is likely to > > > be very controversial. Here's an example of the new output: > > > > > > Indexing objects: 100% (1061/1061), done. > > > Resolving deltas: 100% (638/638), done. > > > > Those two lines are actually my beef with the fetch output. As a newbie, I had > > no idea what "Indexing objects" actually meant. We have this thing called "the > > index" in git so I would expect "Indexing objects" to have something to do > > with that, but it doesn't seem to. > > > > How about something more descriptive of the high-level operation that's going > > on, along the lines of: > > > > Gathering changes from remote: 100% (1061/1061), done. > > Applying changes locally: 100% (638/638), done. > > This is even more wrong. > > Agreed, indexing objects might not be the best description. It probably > will become "receiving objects" along with a bandwitth meter.
The term 'objects' here always confuses me. What is often my first thing to check the number of individual commits being added after a git pull. Wether a commit touches one or several files is less important (to my way of using git).
Sam