GNU bug report logs - #2675
23.0.91; unnecessary vc-next-action conflicts in vc-dir directory

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 2675 in the body.
You can then email your comments to 2675 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Miles Bader <miles <at> gnu.org>
To: emacs-pretest-bug <at> gnu.org
Subject: 23.0.91; unnecessary vc-next-action conflicts in vc-dir directory
Date: Sun, 15 Mar 2009 11:46:57 +0900

[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

Message #8 received at 2675 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Dan Nicolaescu <dann <at> ics.uci.edu>
To: Miles Bader <miles <at> gnu.org>
Cc: 2675 <at> debbugs.gnu.org
Subject: Re: bug#2675: 23.0.91; unnecessary vc-next-action conflicts in vc-dir directory
Date: Sun, 15 Mar 2009 02:20:50 -0700 (PDT)

Miles Bader <miles <at> 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.

Message #13 received at 2675 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Miles Bader <miles <at> gnu.org>
To: Dan Nicolaescu <dann <at> ics.uci.edu>
Cc: 2675 <at> debbugs.gnu.org
Subject: Re: bug#2675: 23.0.91; unnecessary vc-next-action conflicts in vc-dir 
	directory
Date: Sun, 15 Mar 2009 19:01:17 +0900

On Sun, Mar 15, 2009 at 6:20 PM, Dan Nicolaescu <dann <at> 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.

Message #16 received at 2675 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Dan Nicolaescu <dann <at> ics.uci.edu>
To: Miles Bader <miles <at> gnu.org>
Cc: 2675 <at> debbugs.gnu.org
Subject: Re: bug#2675: 23.0.91; unnecessary vc-next-action conflicts in vc-dir  directory
Date: Sun, 15 Mar 2009 08:07:53 -0700 (PDT)

Miles Bader <miles <at> gnu.org> writes:

  > On Sun, Mar 15, 2009 at 6:20 PM, Dan Nicolaescu <dann <at> 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.

Message #21 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Miles Bader <miles <at> gnu.org>
To: gnu-emacs-bug <at> moderators.individual.net
Subject: Re: bug#2675: 23.0.91; unnecessary vc-next-action conflicts in vc-dir  directory
Date: Mon, 16 Mar 2009 08:12:25 +0900

Dan Nicolaescu <dann <at> 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.

Message #26 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Miles Bader <miles <at> gnu.org>
Cc: 2675 <at> debbugs.gnu.org, emacs-pretest-bug <at> gnu.org
Subject: Re: bug#2675: 23.0.91; unnecessary vc-next-action conflicts in vc-dir directory
Date: Sun, 15 Mar 2009 20:50:09 -0400

> 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

Message #36 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Miles Bader <miles <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 2675 <at> debbugs.gnu.org, emacs-pretest-bug <at> gnu.org
Subject: Re: bug#2675: 23.0.91; unnecessary vc-next-action conflicts in vc-dir 
	directory
Date: Mon, 16 Mar 2009 10:12:31 +0900

On Mon, Mar 16, 2009 at 9:50 AM, Stefan Monnier
<monnier <at> 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.

Message #46 received at 2675 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Dan Nicolaescu <dann <at> ics.uci.edu>
To: Miles Bader <miles <at> gnu.org>
Cc: 2675 <at> debbugs.gnu.org
Subject: Re: bug#2675: 23.0.91; unnecessary vc-next-action conflicts in vc-dir  directory
Date: Mon, 16 Mar 2009 17:58:50 -0700 (PDT)

Miles Bader <miles <at> gnu.org> writes:

  > Dan Nicolaescu <dann <at> 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.

Message #49 received at 2675 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Dan Nicolaescu <dann <at> ics.uci.edu>
To: Miles Bader <miles <at> gnu.org>
Cc: 2675 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#2675: 23.0.91; unnecessary vc-next-action conflicts in vc-dir  directory
Date: Mon, 16 Mar 2009 18:08:42 -0700 (PDT)

Miles Bader <miles <at> gnu.org> writes:

  > On Mon, Mar 16, 2009 at 9:50 AM, Stefan Monnier
  > <monnier <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.