[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: VC command for showing outgoing changes

From: Dan Nicolaescu
Subject: Re: VC command for showing outgoing changes
Date: Tue, 13 Oct 2009 14:15:31 -0700 (PDT)

Stefan Monnier <address@hidden> writes:

  > > It would be nice to have a VC command for showing the outgoing changes
  > > for distributed VC systems (i.e. the log of the changes that will be
  > > pushed when you do a VC push).
  > > Let's call this method vc-outgoing (name suggestions are welcome).
  > I think before that we should have support for a `push' backend operation.

You mean as a precondition of doing vc-outgoing?
I'd like to avoid tangling the two.  vc-outgoing should be easy, and similar to
what we already do for `print-log', I am not so sure about `push'.
I think vc-outgoing can be useful even without a push operation, just
for showing the log and examining diffs.

  > > vc-outgoing cannot quite use that because most commands that are defined
  > > for log-view-mode do not make sense (annotate, next/previous file, show
  > > version).
  > The next/previous file seem to make just as much (or as little) sense
  > for this as for log-view.  Also, why don't annotate and show-version
  > make sense?

These are tree level operations, annotate and show-version work on
files.  (Especially annotate, it's code really really wants a file)
And yes, show-version and annotate do not really make much sense for
anything that is not a single file log (directory logs, or multiple file

  > > One thing we can do is to create a log-view-base-mode and have
  > > log-view-mode and log-view-outgoing-mode derive from this mode, and have
  > > log-view-mode and log-view-outgoing-mode define their own commands and
  > > key bindings.
  > Since each backend typically creates its own vc-<foo>-log-view-mode,
  > that tend to lead to the need for "multiple inheritance" in
  > define-derived-mode.  Given the lack of support for such a monster right
  > now, we should probably stick to something simpler, e.g. add
  > a log-view-outgoing binary var, behaving kind of like a minor-mode and
  > controlling availability of some extra bindings.

I am not so sure there's a need for multiple inheritance, backends could
create vc-<foo>-log-view-mode and vc-<foo>-outgoing-mode derived from
log-view-mode and log-view-outgoing-mode, respectively.  
It might not be too complicated to try to (at least partially) implement
both your and my proposals and see which ones looks cleaner.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]