all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Dan Nicolaescu <dann@gnu.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: "Juri Linkov" <juri@jurta.org>,
	"Štěpán Němec" <stepnem@gmail.com>,
	emacs-devel@gnu.org
Subject: Re: support for git commit --amend/--signoff
Date: Thu, 24 Jun 2010 19:14:57 -0400	[thread overview]
Message-ID: <yxqsk4cauq6.fsf@fencepost.gnu.org> (raw)
In-Reply-To: <jwvaaqk8434.fsf-monnier+emacs@gnu.org> (Stefan Monnier's message of "Fri\, 25 Jun 2010 00\:25\:09 +0200")

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Can you please show how this is better than adding a single argument
>> to the vc-checkin method?  (For which the code already exists).
>
> It makes more of the state plainly visible to the user, editable with
> Emacs's usual commands, rather than hidden in variables that are much
> more difficult for the user to control.

How is it more difficult to control something that has an explicit
command attached to it?  (that you've stated that we need to have
anyway)

> I.e. it's more Emacsy by keeping things shallow.

That's not quite true for a lot of things we do in Emacs.

>>>>> Why not show it inside the buffer (e.g. in the header ;-) instead?
>>>> Because we want to insert the previous log when using --amend, so it's
>>>> better to use a command instead of a header.
>>> The question is not "a command vs a header" but "a variable vs
>>> a header".  In both cases we will want to provide a command (which will
>>> fetch the previous log, etc...).
>> So what happens if one deletes the Ammend: header?   Accidentally or not?
>
> It means the commit doesn't amend.  Same thing if you set your vars
> accidentally or if you call the toggle command accidentally, ...
>
> I really don't see it as a problem.  Even if it's done accidentally,
> it's obvious for the user what the behavior will be, since it's written
> in plain text.

Why deal with any potential complications that are not needed at all?

>> --amend and --signoff simply do not fit the header paradigm.  
>> Can we please admit that and move on?
>
> I really don't see it.

Are willing to implement your version and ask users if they prefer it?

I've implemented my version and have been using it for > 6 months,
it's much better to not have to deal with headers.





  reply	other threads:[~2010-06-24 23:14 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-11  6:19 support for git commit --amend/--signoff Dan Nicolaescu
2010-06-11  8:09 ` Juri Linkov
2010-06-11 13:23   ` Dan Nicolaescu
2010-06-11 14:18     ` Stefan Monnier
2010-06-11 16:14       ` Štěpán Němec
2010-06-11 20:26         ` Stefan Monnier
2010-06-12  2:19           ` Dan Nicolaescu
2010-06-12 19:59             ` Juri Linkov
2010-06-12 20:19             ` Stefan Monnier
2010-06-19  6:38               ` Dan Nicolaescu
2010-06-23  7:17                 ` Stefan Monnier
2010-06-23  7:45                   ` David Kastrup
2010-06-23  9:00                   ` Miles Bader
2010-06-23 18:55                     ` Dan Nicolaescu
2010-06-23 18:45                   ` Dan Nicolaescu
2010-06-23 22:04                     ` Stefan Monnier
2010-06-23 23:23                       ` Dan Nicolaescu
2010-06-24 21:03                         ` Stefan Monnier
2010-06-24 21:18                           ` Dan Nicolaescu
2010-06-24 22:25                             ` Stefan Monnier
2010-06-24 23:14                               ` Dan Nicolaescu [this message]
2010-06-25  1:16                                 ` Stefan Monnier
2010-06-25  2:27                                   ` Dan Nicolaescu
2010-06-25 11:44                                     ` Miles Bader
2010-06-26  5:09                                       ` Dan Nicolaescu
2010-07-01  0:01                                         ` Stefan Monnier
2010-06-26 10:11                                       ` David Kastrup
2010-06-28 21:04                                         ` Juri Linkov
2010-06-11 17:34       ` Dan Nicolaescu
2010-06-11 19:27       ` Juri Linkov
2010-06-11 20:16         ` Dan Nicolaescu
2010-06-11 20:38           ` Juri Linkov
2010-06-11 23:48             ` W Dan Meyer
2010-06-12 20:23               ` Juri Linkov
2010-06-12  2:21             ` Dan Nicolaescu
2010-06-11 23:44           ` Thien-Thi Nguyen
2010-06-12 20:15           ` Stefan Monnier
2010-06-11 20:35         ` Stefan Monnier

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=yxqsk4cauq6.fsf@fencepost.gnu.org \
    --to=dann@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=juri@jurta.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=stepnem@gmail.com \
    /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.