bug#25737: 25.1.91; vc-git-log-{incoming,outgoing} fixes

[Dmitry Gutov <dgutov@yandex.ru>]

On 15.02.2017 14:38, Tom Tromey wrote:
> 
> Yesterday I discovered the useful vc-log-outgoing command.  It isn't
> conveniently bound in vc-dir mode, so I added a binding.  But then I
> discovered a couple of bugs in the git back end; and then later
> discovered that the same bugs affect vc-git-log-incoming.

Thanks.

> First, vc-git-log-incoming and vc-git-log-outgoing can be called with a
> nil value for remote-location.  In this case nothing shows up in the
> log.  Changing the code to treat nil the same as the empty string makes
> the commands show the data I would expect.

Do you know when they get called with ""?

Should we maybe just change the callers to always use one or the other 
value?

> Next, these commands move point to the end of the new buffer.  However,
> that is weird, because then the buffer is shrunk to fit; for me this
> ends up making it look like I have just a single outgoing patch, even
> when I have several.

Any ideas why that happens? I can see point ending up at eob when the 
call is synchronous, but that doesn't affect the shrinking behavior much 
(e.g. I have 13 lines, the window shrinks correctly but hides the first 
line because the cursor is after the last line, and it has to be visible).

I've only tested this in vc-log-incoming, however.

> Changing these functions to pass 'async to
> vc-git-command fixes this.

I don't mind, but it would be great to know the underlying reasons for 
the problems. And we have a somewhat similar bug with vc-print-root-log, 
too (point jumps to the end when the log is small enough or something).

> Finally, vc-git-log-view-mode only sets truncate-lines in some
> situations; I have changed it to also set it for log-outgoing and
> log-incoming, which makes the output of these commands more closely
> resemble the output of vc-print-log.

Sounds good.