Re: Git pull confusing output

From: Stefan Beller <sbeller@google.com>
Date: Nov 28, 2018, 20:27 UTC
Message-ID: <CAGZ79kbORHfkZOYXrCrHgKX_66M8=3jppn9_SU5fuB6_CfAMag@mail.gmail.com>
In-Reply-To: <xmqq36rlsofp.fsf@gitster-ct.c.googlers.com>

On Tue, Nov 27, 2018 at 10:31 PM Junio C Hamano <gitster@pobox.com> wrote:

Show 21 quoted lines

>
> Will <william.duclot@gmail.com> writes:
>
> > I’m far from being a guru, but I consider myself a competent Git
> > user. Yet, here’s my understanding of the output of one the most-used
> > commands, `git push`:
> >> Counting objects: 6, done.
> > No idea what an “object” is. Apparently there’s 6 of them
> > here. What does “counting” them means? Should I care?
>
> You vaguely recall that the last time you pushed you saw ~400
> objects counted there, so you get the feeling how active you were
> since then.
>
> It is up to you if you are interested in such a feel of the level of
> activity.  "git fetch" (hence "git pull") would also give you a
> similar "feel", e.g. "the last fetch was ~1200 objects and today's
> is mere ~200, so it seems it is a relatively slow day".
>
> As to "what is an object?", there are plenty of Git tutorials and
> books to learn the basics from.  Again, it is up to you if you care.

While this is very interesting to the experienced git user, the approximation of activity by object count is very coarse to say at least.

As It approximates changes in the DAG object count and nothing about the deltas (which as we learn comes later and it comes with a progress meter in bytes), it only provides the basics.

>
> I think we have "--quiet" option for those who do not care.

I think some users are not focused as much on the version control as much as they are focused on another problem that is solved with the content inside the repo.

Which means they only care about 'actionable' output, such as
* errors
* information provided by remote
  (e.g. links to click to start a code review)
* too long waiting time
  (so they can abort and inspect the problem)

I would suggest we come up with a mode that is "not quiet", but cuts down to only the basic actionable items [and make that the default eventually].

Now these actionable items depend on the workflow used, for which I think an email based maintainers workflow is not the norm. The vast majority of people uses git-push to upload their change to a code review system instead. And for such a workflow the size (as proxied by object/delta count) is not as important as the target ref that you push to or potentially the diffstat output of a potential merge to a target branch.

TLDR: I still think making git-push a bit more quiet is
beneficial to the user base at large.

Stefan