bug#2675: 23.0.91; unnecessary vc-next-action conflicts in vc-dir directory

bug#2675: 23.0.91; unnecessary vc-next-action conflicts in vc-dir directory

[Miles Bader]

[Note: I have Dan's patch for fixing whole-directory vc-dir commit in
Git applied, though I don't think it should affect the following, as it
relates to final commit.]

If I have a vc-dir buffer showing a tree with some "up-to-date" entries
from previously committed files, and also some entries for newly changed
files:

   VC backend : Git
   Working dir: /tmp/zonk/
   Branch     : master

                            ./
        up-to-date          newf2
        up-to-date          newf3
        unregistered        newf4
        up-to-date          ppling

Then hitting "v" on the first line of the buffer gives the following
error:

   vc-dir-deduce-fileset: /tmp/zonk/newf4:unregistered clashes with /tmp/zonk/newf2:up-to-date

This seems like a silly and pointless error -- it should probably simply
ignore any "up-to-date" entries when checking for conflicts.

[I know, I can use the "x" command to flush those up-to-date entries -- 
but I shouldn't have to, and not every user will know about that command
(or know to use it, given the slightly obscure error message).]

Thanks,

-Miles


If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
If you would like to further debug the crash, please read the file
/usr/local/share/emacs/23.0.91/etc/DEBUG for instructions.


In GNU Emacs 23.0.91.11 (x86_64-unknown-linux-gnu, GTK+ Version 2.15.5)
 of 2009-03-13 on catnip
Windowing system distributor `The X.Org Foundation', version 11.0.10599902
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ja_JP.UTF-8
  value of $XMODIFIERS: @im=SCIM
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t

Major mode: VC dir

Minor modes in effect:
  diff-auto-refine-mode: t
  shell-dirtrack-mode: t
  rcirc-track-minor-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
r a p C-x C-s C-x k <return> C-x C-v n e w f 2 <return> 
w h o o <return> C-x C-s C-x k <return> v C-n C-n C-n 
C-n C-n v C-c C-c C-u C-p C-u C-p v x C-x C-v n e w 
f 3 <return> o o o o <return> C-x C-s C-x k <return> 
C-a v C-n C-n C-n C-n C-n C-n C-u C-p C-u C-p v v v 
v v C-n C-n v C-n C-n C-n C-n v C-c C-c C-u C-p C-u 
C-p v c o m 2 <return> C-c C-c C-x b q SPC <return> 
h e y y <escape> > h e y y . . . <return> u p SPC n 
o w SPC C-a C-k C-\ i ' m SPC h e r e . . . SPC : - 
) <return> i SPC s a w SPC y o u r SPC m s g SPC o 
n SPC f a c e b o o k SPC s o SPC i SPC g u e s s SPC 
y o u SPC g o t SPC d i m s u m ! ! <return> y u m 
m m m m m m <return> <down-mouse-1> <mouse-1> C-c C-SPC 
C-x b C-g C-x b <return> C-x b z o SPC n SPC C-g C-x 
C-v M-p <escape> h <return> <escape> x v C-g C-x b 
* v c SPC - d i SPC r SPC SPC / SPC <return> C-n C-n 
C-n C-n C-x C-v n e w 4 <backspace> f 4 <return> p 
l o o <return> C-x C-s C-x k <return> C-p C-p C-p v 
<escape> x r e c o SPC <escape> h r e p o SPC r SPC 
e m SPC <return>

Recent messages:
Quit
xding
Quit
Making completion list... [3 times]
(New file)
Saving file /tmp/zonk/newf4...
Wrote /tmp/zonk/newf4
xding
vc-dir-deduce-fileset: /tmp/zonk/newf4:unregistered clashes with /tmp/zonk/newf2:up-to-date
Making completion list... [2 times]

-- 
`To alcohol!  The cause of, and solution to,
 all of life's problems' --Homer J. Simpson

bug#2675: 23.0.91; unnecessary vc-next-action conflicts in vc-dir directory

[Dan Nicolaescu]

Miles Bader <miles@gnu.org> writes:

  > [Note: I have Dan's patch for fixing whole-directory vc-dir commit in
  > Git applied, though I don't think it should affect the following, as it
  > relates to final commit.]
  > 
  > If I have a vc-dir buffer showing a tree with some "up-to-date" entries
  > from previously committed files, and also some entries for newly changed
  > files:
  > 
  >    VC backend : Git
  >    Working dir: /tmp/zonk/
  >    Branch     : master
  > 
  >                             ./
  >         up-to-date          newf2
  >         up-to-date          newf3
  >         unregistered        newf4
  >         up-to-date          ppling
  > 
  > Then hitting "v" on the first line of the buffer gives the following
  > error:
  > 
  >    vc-dir-deduce-fileset: /tmp/zonk/newf4:unregistered clashes with /tmp/zonk/newf2:up-to-date
  > 
  > This seems like a silly and pointless error -- it should probably simply
  > ignore any "up-to-date" entries when checking for conflicts.

If you look at vc-next-action, you'll see that it's possible to do
things to files in the 'up-to-date state, and it's not the same as what
it's done to unregistered files.

vc-next-action wants to treat all the files the same, that's the reason
for this check.

bug#2675: 23.0.91; unnecessary vc-next-action conflicts in vc-dir directory

[Miles Bader]

On Sun, Mar 15, 2009 at 6:20 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote:
>  >    vc-dir-deduce-fileset: /tmp/zonk/newf4:unregistered clashes with /tmp/zonk/newf2:up-to-date
>  >
>  > This seems like a silly and pointless error -- it should probably simply
>  > ignore any "up-to-date" entries when checking for conflicts.
>
> If you look at vc-next-action, you'll see that it's possible to do
> things to files in the 'up-to-date state, and it's not the same as what
> it's done to unregistered files.
>
> vc-next-action wants to treat all the files the same, that's the reason
> for this check.

AFAICS, that's only true in certain circumstances, which
vc-next-action could check for:  (1) it's a locking system, or (2) the
user specified a prefix arg (I guess meaning "move to another rev".

In the default case, I think it's simply being annoyingly pedantic.

-miles

-- 
Do not taunt Happy Fun Ball.

bug#2675: 23.0.91; unnecessary vc-next-action conflicts in vc-dir directory

[Dan Nicolaescu]

Miles Bader <miles@gnu.org> writes:

  > On Sun, Mar 15, 2009 at 6:20 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote:
  > >  >    vc-dir-deduce-fileset: /tmp/zonk/newf4:unregistered clashes with /tmp/zonk/newf2:up-to-date
  > >  >
  > >  > This seems like a silly and pointless error -- it should probably simply
  > >  > ignore any "up-to-date" entries when checking for conflicts.
  > >
  > > If you look at vc-next-action, you'll see that it's possible to do
  > > things to files in the 'up-to-date state, and it's not the same as what
  > > it's done to unregistered files.
  > >
  > > vc-next-action wants to treat all the files the same, that's the reason
  > > for this check.
  > 
  > AFAICS, that's only true in certain circumstances, which
  > vc-next-action could check for:  (1) it's a locking system, or (2) the
  > user specified a prefix arg (I guess meaning "move to another rev".
  > 
  > In the default case, I think it's simply being annoyingly pedantic.

Personally, I  disagree with that.
Anyway, vc-dir is the wrong tree to bark at, you want to have
vc-next-action + vc-compatible-state changed and this issue will
disappear.

bug#2675: 23.0.91; unnecessary vc-next-action conflicts in vc-dir directory

[Miles Bader]

Dan Nicolaescu <dann@ics.uci.edu> writes:
> Personally, I  disagree with that.
> Anyway, vc-dir is the wrong tree to bark at, you want to have
> vc-next-action + vc-compatible-state changed and this issue will
> disappear.

FWIW, I just did `report-emacs-bug', I didn't intend to register this as
a vc-dir bug in particular (or anything else, though vc-next-action is
the command invoked).  Is there a protocol for filing bugs against
specific parts of emacs?

-Miles

-- 
Bigot, n. One who is obstinately and zealously attached to an opinion that
you do not entertain.

bug#2675: 23.0.91; unnecessary vc-next-action conflicts in vc-dir directory

[Stefan Monnier]

> Then hitting "v" on the first line of the buffer gives the following error:

From where I stand, the problem is the use of `v' in vc-dir.  While the
concept of "next-action" might make sense for single files, it's not
nearly as useful for vc-dir, especially since vc-dir has a lot of free
key-bindings, so it can easily use separate bindings for
commit/checkout/merge/...


        Stefan

bug#2675: 23.0.91; unnecessary vc-next-action conflicts in vc-dir directory

[Miles Bader]

On Mon, Mar 16, 2009 at 9:50 AM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>> Then hitting "v" on the first line of the buffer gives the following error:
>
> From where I stand, the problem is the use of `v' in vc-dir.  While the
> concept of "next-action" might make sense for single files, it's not
> nearly as useful for vc-dir, especially since vc-dir has a lot of free
> key-bindings, so it can easily use separate bindings for
> commit/checkout/merge/...

Yeah, good point; the concept of "next-action" has always kind of
bothered me, even in the old single-file case...
Even if it's sometimes a handy shortcut, I think in many cases I'd
prefer a firmer notion of what my command was going to do...

How about "c" for commit in *vc-dir*?

Of course, there needs to be a vc-commit command first... !

[I'd also suggest "a" as an alias for "register", as "i" seems obscure.]

[Offhand, I think they'd be good bindings for the global keymap too,
but it contains so much weird cruft bound to apparently arbitrary
letters, it's probably too late to make any sense of that...]

-Miles

-- 
Do not taunt Happy Fun Ball.

bug#2675: 23.0.91; unnecessary vc-next-action conflicts in vc-dir directory

[Dan Nicolaescu]

Miles Bader <miles@gnu.org> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > > Personally, I  disagree with that.
  > > Anyway, vc-dir is the wrong tree to bark at, you want to have
  > > vc-next-action + vc-compatible-state changed and this issue will
  > > disappear.
  > 
  > FWIW, I just did `report-emacs-bug', I didn't intend to register this as
  > a vc-dir bug in particular (or anything else, though vc-next-action is
  > the command invoked).  Is there a protocol for filing bugs against
  > specific parts of emacs?

No idea.  Somehow vc-dir managed to get itself a bug category (not very
useful given that it's so small, a vc category would be more useful,
but...).
But the interesting thing is that I don't remember at the moment any bug
in that category that is/was a vc-dir bug, most were vc bugs, or various
vc-backend bugs.

bug#2675: 23.0.91; unnecessary vc-next-action conflicts in vc-dir directory

[Dan Nicolaescu]

Miles Bader <miles@gnu.org> writes:

  > On Mon, Mar 16, 2009 at 9:50 AM, Stefan Monnier
  > <monnier@iro.umontreal.ca> wrote:
  > >> Then hitting "v" on the first line of the buffer gives the following error:
  > >
  > > From where I stand, the problem is the use of `v' in vc-dir.  While the
  > > concept of "next-action" might make sense for single files, it's not
  > > nearly as useful for vc-dir, especially since vc-dir has a lot of free
  > > key-bindings, so it can easily use separate bindings for
  > > commit/checkout/merge/...
  > 
  > Yeah, good point; the concept of "next-action" has always kind of
  > bothered me, even in the old single-file case...
  > Even if it's sometimes a handy shortcut, I think in many cases I'd
  > prefer a firmer notion of what my command was going to do...

I actually like vc-next-action, it does what I want most of the time...

  > How about "c" for commit in *vc-dir*?
  > 
  > Of course, there needs to be a vc-commit command first... !

Add the vc-commit command, and I'll add the vc-dir binding for it :-)

  > [I'd also suggest "a" as an alias for "register", as "i" seems obscure.]

"i" comes from "C-x v i" -- in general the VC commands in vc-dir use the
bindings from the C-x v map.

  > [Offhand, I think they'd be good bindings for the global keymap too,
  > but it contains so much weird cruft bound to apparently arbitrary
  > letters, it's probably too late to make any sense of that...]

Probably too late for the 23.1 release, but if you want to open the
discussion after the release, maybe there won't be too much pushback for
getting rid of things like C-x v h