[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
logs).
> > 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.