git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexandre Julliard <julliard@winehq.org>
To: Brent Goodrick <bgoodr@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Fix file mark handling and sort side-effects in git.el
Date: Sun, 15 Feb 2009 20:15:05 +0100	[thread overview]
Message-ID: <87k57rh5qe.fsf@wine.dyndns.org> (raw)
In-Reply-To: <e38bce640902151035s18e374e6j25e3887728722700@mail.gmail.com> (Brent Goodrick's message of "Sun, 15 Feb 2009 10:35:38 -0800")

Brent Goodrick <bgoodr@gmail.com> writes:

> Ok, now that makes sense to me. Part of the problem here is that there
> is no statement in the user manual about git.el's intent to hide the
> index. Perhaps something to the effect of "If you are new to using
> Emacs but not new to git, then you need to know that bla bla ...".
> Otherwise, I think users may get tripped up by this as I was. Was
> there a manual in the works for git.el or did I just miss it in recent
> checkins?

There's no manual, and I'm not going to write one, I suck at writing
documentation. If you would like to contribute one it would certainly be
welcome.

> However, the *git-status* buffer does properly reflect the two added
> files by their state being changed to "Added". Since you may have a
> ton of files that are being added, it probably doesn't make a whole
> lot of sense to dump a long message into the minibuffer with all of
> those names.  By the same token, it doesn't make sense to emit one
> message per file either. Instead, would you be willing to change that
> message to just state "Added n files" where "n" is the number of files
> added?

That's exactly what git-success-message already does. The only problem
is that the list isn't always preserved properly (and that's only a
cosmetic bug, the operations get carried out correctly).

-- 
Alexandre Julliard
julliard@winehq.org

  reply	other threads:[~2009-02-15 19:16 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-11  6:12 [PATCH] Fix file mark handling and sort side-effects in git.el Brent Goodrick
2009-02-11 10:56 ` Alexandre Julliard
     [not found]   ` <e38bce640902120738h7b9bb75o42e1524cbfd95169@mail.gmail.com>
2009-02-12 17:08     ` Brent Goodrick
2009-02-15 17:08       ` Alexandre Julliard
2009-02-15 18:35         ` Brent Goodrick
2009-02-15 19:15           ` Alexandre Julliard [this message]
2009-02-16  0:04             ` Brent Goodrick

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=87k57rh5qe.fsf@wine.dyndns.org \
    --to=julliard@winehq.org \
    --cc=bgoodr@gmail.com \
    --cc=git@vger.kernel.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.
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 NNTP newsgroup(s).