GNU bug report logs -
#62940
29.0.60; vc: no easy way to get diff of all outgoing changes
Previous Next
Full log
Message #49 received at 62940 <at> debbugs.gnu.org (full text, mbox):
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.
This bug report was last modified 24 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.