GNU bug report logs - #2676
23.0.91; annoying/unnecessary vc-next-action conflict in vc-dir buffer

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 2676 in the body.
You can then email your comments to 2676 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; annoying/unnecessary vc-next-action conflict in vc-dir buffer
Date: Sun, 15 Mar 2009 11:57:36 +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 a new file (not yet
registered with source-control), and a changed file (already
registered):

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

                            ./
        unregistered        newf4
        edited              ppling

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

   vc-dir-deduce-fileset: /tmp/zonk/ppling:edited clashes with /tmp/zonk/newf4:unregistered

While I guess I understand the reason for this, it's slightly annoying.

Given vc-next-action's "do-the-right-next-thing" functionality, it would
seem better in such a case to instead do a "register files only" step
(ignoring any changed-but-already-registered entries); subsequently, the
user could just hit "v" again to commit everything (the old changed file
and the files newly registered by the first "v").

I think this behavior would be a better match for vc-next-action's
behavior on single files.

Because registering/deregistering files is typically a local and
easily reversible operation, it would be "safe".

[Probably the "register files only" step should handle deletions too,
unregistering any deleted files.]

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:
C-p SPC n o t SPC e v e r y SPC u s e r SPC w i l l 
SPC r e a l i z e SPC t h a t <escape> h <escape> h 
k n <escape> h k n o w SPC a b o u t SPC t h a t SPC 
c o m m a n d SPC ( <backspace> ( o r SPC k n o w SPC 
t o SPC u s e SPC i t , SPC e s <escape> h C-a M-f 
M-f C-n C-e C-p C-e <backspace> ) . ] C-n C-a C-k C-k 
C-n C-n C-x b <return> C-x d <escape> < C-n C-n C-n 
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n 
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n 
SPC SPC SPC C-n C-a C-n C-u C-p C-u C-p C-u C-p C-u 
C-p C-u C-p C-e C-b SPC <backspace> , SPC a n <backspace> 
s SPC i t SPC o n l y SPC f <backspace> a f <escape> 
h <escape> h r e l a t e s SPC t o SPC t h e SPC f 
i n a l SPC c o m m i t . C-a M-f M-f M-d C-e C-c C-c 
C-n C-n C-n C-n C-n C-n C-n x C-x C-v p l SPC o i SPC 
<escape> h ? p p SPC <return> C-o C-o m n o r r r r 
r e C-x C-s C-x k <return> C-u C-p C-u C-p v C-x b 
* s e SPC b u SPC <escape> h * r <backspace> b u SPC 
<return> C-x b <return> <escape> x r e p o r SPC e 
m SPC <return>

Recent messages:
Appended to /home/miles/mail/out/20090315
Sending...done
xding [2 times]
Making completion list...
Saving file /tmp/zonk/ppling...
Wrote /tmp/zonk/ppling
xding [2 times]
vc-dir-deduce-fileset: /tmp/zonk/ppling:edited clashes with /tmp/zonk/newf4:unregistered
xding
Scanning for dabbrevs...100%

-- 
Fast, small, soon; pick any 2.

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

From: Dan Nicolaescu <dann <at> ics.uci.edu>
To: Miles Bader <miles <at> gnu.org>
Cc: 2676 <at> debbugs.gnu.org
Subject: Re: bug#2676: 23.0.91; annoying/unnecessary vc-next-action conflict in vc-dir buffer
Date: Sun, 15 Mar 2009 07:53:14 -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 a new file (not yet
  > registered with source-control), and a changed file (already
  > registered):
  > 
  >    VC backend : Git
  >    Working dir: /tmp/zonk/
  >    Branch     : master
  > 
  >                             ./
  >         unregistered        newf4
  >         edited              ppling
  > 
  > Then hitting "v" on the first line of the buffer gives the following
  > error:
  > 
  >    vc-dir-deduce-fileset: /tmp/zonk/ppling:edited clashes with /tmp/zonk/newf4:unregistered
  > 
  > While I guess I understand the reason for this, it's slightly annoying.
  > 
  > Given vc-next-action's "do-the-right-next-thing" functionality, it would
  > seem better in such a case to instead do a "register files only" step
  > (ignoring any changed-but-already-registered entries); subsequently, the
  > user could just hit "v" again to commit everything (the old changed file
  > and the files newly registered by the first "v").
  > 
  > I think this behavior would be a better match for vc-next-action's
  > behavior on single files.
  > 
  > Because registering/deregistering files is typically a local and
  > easily reversible operation, it would be "safe".
  > 
  > [Probably the "register files only" step should handle deletions too,
  > unregistering any deleted files.]

Not sure if such behavior is desirable.  It's not unusual to have log
files, debug output, and various other files that don't satisfy a
pattern in the current directory.  Registering such file and checking
them in by mistake does not seem such a good idea.

Note that it's quite easy to register all unregistered files: put the
cursor on one of them, press M, all of them will be selected, press v
and be done.

Also note that vc-dir is just enforcing the vc-next-action requirements
here, so you probably want to file your bug against that one.

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

From: Miles Bader <miles <at> gnu.org>
To: Dan Nicolaescu <dann <at> ics.uci.edu>
Cc: 2676 <at> debbugs.gnu.org
Subject: Re: bug#2676: 23.0.91; annoying/unnecessary vc-next-action conflict 
	in vc-dir buffer
Date: Mon, 16 Mar 2009 09:30:36 +0900

On Sun, Mar 15, 2009 at 11:53 PM, Dan Nicolaescu <dann <at> ics.uci.edu> wrote:
> Not sure if such behavior is desirable.  It's not unusual to have log
> files, debug output, and various other files that don't satisfy a
> pattern in the current directory.  Registering such file and checking
> them in by mistake does not seem such a good idea.

Hmm, you're right, that might cause problems.

Your advice about using "M" was useful, it would be cool if vc-dir
could give such advice... :-)

-Miles

-- 
Do not taunt Happy Fun Ball.

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

From: Dan Nicolaescu <dann <at> ics.uci.edu>
To: Miles Bader <miles <at> gnu.org>
Cc: 2676 <at> debbugs.gnu.org
Subject: Re: bug#2676: 23.0.91; annoying/unnecessary vc-next-action conflict  in vc-dir buffer
Date: Mon, 16 Mar 2009 18:00:14 -0700 (PDT)

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

  > On Sun, Mar 15, 2009 at 11:53 PM, Dan Nicolaescu <dann <at> ics.uci.edu> wrote:
  > > Not sure if such behavior is desirable.  It's not unusual to have log
  > > files, debug output, and various other files that don't satisfy a
  > > pattern in the current directory.  Registering such file and checking
  > > them in by mistake does not seem such a good idea.
  > 
  > Hmm, you're right, that might cause problems.

In that case you can close this bug, right?

  > Your advice about using "M" was useful, it would be cool if vc-dir
  > could give such advice... :-)

[METALIC VOICE]: This is vc-dir speaking follow everything I say!

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

From: Miles Bader <miles <at> gnu.org>
To: Dan Nicolaescu <dann <at> ics.uci.edu>
Cc: 2676 <at> debbugs.gnu.org
Subject: Re: bug#2676: 23.0.91; annoying/unnecessary vc-next-action conflict 
	in vc-dir buffer
Date: Tue, 17 Mar 2009 10:10:18 +0900

On Tue, Mar 17, 2009 at 10:00 AM, Dan Nicolaescu <dann <at> ics.uci.edu> wrote:
>  > Hmm, you're right, that might cause problems.
>
> In that case you can close this bug, right?

Can I close bugs...?

>  > Your advice about using "M" was useful, it would be cool if vc-dir
>  > could give such advice... :-)
>
> [METALIC VOICE]: This is vc-dir speaking follow everything I say!

Seriously...  if you've ever used git much, in some situations it
gives user-oriented advice like "if you want to do foo, you might want
to use comand x y z ...", and it's often a _really_ useful hint, even
if you've used git for a while (and the location of such advice is
tastefully chosen so that it's not annoying for experienced users).

One can figure out what the current vc-next-action conflict error
messages mean with a bit of thought, but they seem sort of
user-hostile, almost designed to cause one's eyes to glaze over...

-Miles

-- 
Do not taunt Happy Fun Ball.

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

From: Dan Nicolaescu <dann <at> ics.uci.edu>
To: Miles Bader <miles <at> gnu.org>
Cc: 2676 <at> debbugs.gnu.org
Subject: Re: bug#2676: 23.0.91; annoying/unnecessary vc-next-action conflict  in vc-dir buffer
Date: Mon, 16 Mar 2009 19:07:49 -0700 (PDT)

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

  > On Tue, Mar 17, 2009 at 10:00 AM, Dan Nicolaescu <dann <at> ics.uci.edu> wrote:
  > >  > Hmm, you're right, that might cause problems.
  > >
  > > In that case you can close this bug, right?
  > 
  > Can I close bugs...?

Send an email to 2676-done <at> debbugs.gnu.org and it will be
closed.
For doing more than that see emacs/admin/notes/bugtracker


  > >  > Your advice about using "M" was useful, it would be cool if vc-dir
  > >  > could give such advice... :-)
  > >
  > > [METALIC VOICE]: This is vc-dir speaking follow everything I say!
  > 
  > Seriously...  if you've ever used git much, in some situations it
  > gives user-oriented advice like "if you want to do foo, you might want
  > to use comand x y z ...", and it's often a _really_ useful hint, even
  > if you've used git for a while (and the location of such advice is
  > tastefully chosen so that it's not annoying for experienced users).

  > One can figure out what the current vc-next-action conflict error
  > messages mean with a bit of thought, but they seem sort of
  > user-hostile, almost designed to cause one's eyes to glaze over...

I take responsibility for the error thrown by `vc-dir-deduce-fileset'.
How about saying something like:

VC operations when applied to multiple files require files to be in
similar VC states.
%s in state %s clashes with %s in state %s

If you have suggestions for this and other messages, they shouldn't be
too hard to improve.

In general some facility that shows tips for various modes would be
useful to have in emacs.

Message #33 received at 2676-done <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Miles Bader <miles <at> gnu.org>
To: 2676-done <at> debbugs.gnu.org
Subject: close this bug...
Date: Wed, 18 Mar 2009 20:43:28 +0900

Previous Next

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