all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Dan Nicolaescu <dann@ics.uci.edu>
To: Miles Bader <miles@gnu.org>
Cc: 2676@emacsbugs.donarmstrong.com
Subject: 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)	[thread overview]
Message-ID: <200903151453.n2FErEpe017505@godzilla.ics.uci.edu> (raw)
In-Reply-To: <87iqmbcx27.fsf@catnip.gol.com> (Miles Bader's message of "Sun, 15 Mar 2009 11:57:36 +0900")

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.







  reply	other threads:[~2009-03-15 14:53 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200903151453.n2FErEpe017505@godzilla.ics.uci.edu \
    --to=dann@ics.uci.edu \
    --cc=2676@emacsbugs.donarmstrong.com \
    --cc=miles@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.