* bug#2676: 23.0.91; annoying/unnecessary vc-next-action conflict in vc-dir buffer @ 2009-03-15 2:57 ` Miles Bader 2009-03-15 14:53 ` Dan Nicolaescu 2009-03-18 11:50 ` bug#2676: marked as done (23.0.91; annoying/unnecessary vc-next-action conflict in vc-dir buffer) Emacs bug Tracking System 0 siblings, 2 replies; 7+ messages in thread From: Miles Bader @ 2009-03-15 2:57 UTC (permalink / raw) To: emacs-pretest-bug [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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#2676: 23.0.91; annoying/unnecessary vc-next-action conflict in vc-dir buffer 2009-03-15 2:57 ` bug#2676: 23.0.91; annoying/unnecessary vc-next-action conflict in vc-dir buffer Miles Bader @ 2009-03-15 14:53 ` Dan Nicolaescu 2009-03-16 0:30 ` Miles Bader 2009-03-18 11:50 ` bug#2676: marked as done (23.0.91; annoying/unnecessary vc-next-action conflict in vc-dir buffer) Emacs bug Tracking System 1 sibling, 1 reply; 7+ messages in thread From: Dan Nicolaescu @ 2009-03-15 14:53 UTC (permalink / raw) To: Miles Bader; +Cc: 2676 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#2676: 23.0.91; annoying/unnecessary vc-next-action conflict in vc-dir buffer 2009-03-15 14:53 ` Dan Nicolaescu @ 2009-03-16 0:30 ` Miles Bader 2009-03-17 1:00 ` Dan Nicolaescu 0 siblings, 1 reply; 7+ messages in thread From: Miles Bader @ 2009-03-16 0:30 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: 2676 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#2676: 23.0.91; annoying/unnecessary vc-next-action conflict in vc-dir buffer 2009-03-16 0:30 ` Miles Bader @ 2009-03-17 1:00 ` Dan Nicolaescu 2009-03-17 1:10 ` Miles Bader 0 siblings, 1 reply; 7+ messages in thread From: Dan Nicolaescu @ 2009-03-17 1:00 UTC (permalink / raw) To: Miles Bader; +Cc: 2676 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! ^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#2676: 23.0.91; annoying/unnecessary vc-next-action conflict in vc-dir buffer 2009-03-17 1:00 ` Dan Nicolaescu @ 2009-03-17 1:10 ` Miles Bader 2009-03-17 2:07 ` Dan Nicolaescu 0 siblings, 1 reply; 7+ messages in thread From: Miles Bader @ 2009-03-17 1:10 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: 2676 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#2676: 23.0.91; annoying/unnecessary vc-next-action conflict in vc-dir buffer 2009-03-17 1:10 ` Miles Bader @ 2009-03-17 2:07 ` Dan Nicolaescu 0 siblings, 0 replies; 7+ messages in thread From: Dan Nicolaescu @ 2009-03-17 2:07 UTC (permalink / raw) To: Miles Bader; +Cc: 2676 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#2676: marked as done (23.0.91; annoying/unnecessary vc-next-action conflict in vc-dir buffer) 2009-03-15 2:57 ` bug#2676: 23.0.91; annoying/unnecessary vc-next-action conflict in vc-dir buffer Miles Bader 2009-03-15 14:53 ` Dan Nicolaescu @ 2009-03-18 11:50 ` Emacs bug Tracking System 1 sibling, 0 replies; 7+ messages in thread From: Emacs bug Tracking System @ 2009-03-18 11:50 UTC (permalink / raw) To: Miles Bader [-- 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> ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2009-03-18 11:50 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <fc339e4a0903180443k2d2539di2df31c82628bad08@mail.gmail.com>
2009-03-15 2:57 ` bug#2676: 23.0.91; annoying/unnecessary vc-next-action conflict in vc-dir buffer Miles Bader
2009-03-15 14:53 ` Dan Nicolaescu
2009-03-16 0:30 ` Miles Bader
2009-03-17 1:00 ` Dan Nicolaescu
2009-03-17 1:10 ` Miles Bader
2009-03-17 2:07 ` Dan Nicolaescu
2009-03-18 11:50 ` bug#2676: marked as done (23.0.91; annoying/unnecessary vc-next-action conflict in vc-dir buffer) Emacs bug Tracking System
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).