bug#62940: 29.0.60; vc: no easy way to get diff of all outgoing changes

[Dmitry Gutov <dmitry@gutov.dev>]

Hi!

On 13/09/2024 23:54, Spencer Baugh wrote:
> This works great, but is a bit tricky to use because you need to type
> the upstream branch ref.  I think it would be good to provide that as an
> additional default in the prompt for the old revision.  The attached
> patch does that.  (and probably is enough to close this bug)C-u M-x vc-root-diff will prompt for the old revision to use for the
> diff.  It includes the current working revision as a default.

I like the idea. See comments below.

> Now it also includes the last pushed revision as a default, through a
> new pushed-revision vc backend function.* lisp/vc/vc-git.el (vc-git-pushed-revision): Add.
> (vc-git-log-outgoing): Use vc-git-pushed-revision.
> * lisp/vc/vc-hg.el (vc-hg-pushed-revision): Add.
> * lisp/vc/vc.el (vc-default-pushed-revision): Add new backend function
> with default implementation returning nil.

Am I too used to Git, or should this be called upstream-revision or 
origin-revision?

The user might have just recently cloned the repository and not pushed 
anything yet. Anyway, matter of taste.

(defun vc-hg-pushed-revision (_file &optional remote-location)
> +  "Return a revspec for the last commit not outgoing to REMOTE-LOCATION."
> +  (unless remote-location
> +    (setq remote-location ""))
> +  (format "last(. and not outgoing(%s))" remote-location))

Is the second argument even non-nil in the Hg implementation?

(defun vc-diff-build-argument-list-internal (&optional fileset)
>     "Build argument list for calling internal diff functions."
>     (let* ((vc-fileset (or fileset (vc-deduce-fileset t))) ;FIXME: why t?  --Stef
> @@ -2069,6 +2074,8 @@ vc-diff-build-argument-list-internal
>            (first (car files))
>            (rev1-default nil)
>            ) ;; (rev2-default nil)
> +    (when-let ((pushed-revision (vc-call-backend backend 'pushed-revision first)))
> +      (push pushed-revision rev1-default))

Maybe we would prefer to keep the current suggestion as the first 
default, and have the upstream as the second suggestion (on M-n)? For 
backward compatibility anyway. I'm not 100% sure - the upstream ref 
seems like a more useful default in a lot of cases (and harder to type 
out when you do want it), but it's also workflow-specific.