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

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

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

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

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

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

[Miles Bader]

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

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

[Dan Nicolaescu]

Miles Bader <miles@gnu.org> writes:

  > On Sun, Mar 15, 2009 at 11:53 PM, Dan Nicolaescu <dann@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!

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

[Miles Bader]

On Tue, Mar 17, 2009 at 10:00 AM, Dan Nicolaescu <dann@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.

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

[Dan Nicolaescu]

Miles Bader <miles@gnu.org> writes:

  > On Tue, Mar 17, 2009 at 10:00 AM, Dan Nicolaescu <dann@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@emacsbugs.donarmstrong.com 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.

bug#2676: marked as done (23.0.91; annoying/unnecessary vc-next-action conflict in vc-dir buffer)

[Emacs bug Tracking System]

[-- Attachment #1: Type: text/plain, Size: 901 bytes --]


Your message dated Wed, 18 Mar 2009 20:43:28 +0900
with message-id <fc339e4a0903180443k2d2539di2df31c82628bad08@mail.gmail.com>
and subject line close this bug...
has caused the Emacs bug report #2676,
regarding 23.0.91; annoying/unnecessary vc-next-action conflict in vc-dir buffer
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@emacsbugs.donarmstrong.com
immediately.)


-- 
2676: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=2676
Emacs Bug Tracking System
Contact owner@emacsbugs.donarmstrong.com with problems

[-- Attachment #2: Type: message/rfc822, Size: 6146 bytes --]

From: Miles Bader <miles@gnu.org>
To: emacs-pretest-bug@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
Message-ID: <87iqmbcx27.fsf@catnip.gol.com>

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



[-- Attachment #3: Type: message/rfc822, Size: 2241 bytes --]

From: Miles Bader <miles@gnu.org>
To: 2676-done@emacsbugs.donarmstrong.com
Subject: close this bug...
Date: Wed, 18 Mar 2009 20:43:28 +0900
Message-ID: <fc339e4a0903180443k2d2539di2df31c82628bad08@mail.gmail.com>