There's no point in asking this over and over if the user already
properly configured his/her name and email.
Signed-off-by: Felipe Contreras
---
I got really tired of 'git send-email' always asking me from which address to
send mails... that's already configured.
git-send-email.perl | 11 +++
On Sun, Nov 11, 2012 at 6:12 PM, Ramkumar Ramachandra
wrote:
> Felipe Contreras wrote:
>> I got really tired of 'git send-email' always asking me from which address
>> to send mails... that's already configured.
>
> Use sendemail.from. The email sender doesn't necessarily have to be the
> autho
On Sun, Nov 11, 2012 at 06:06:50PM +0100, Felipe Contreras wrote:
> There's no point in asking this over and over if the user already
> properly configured his/her name and email.
>
> Signed-off-by: Felipe Contreras
> ---
>
> I got really tired of 'git send-email' always asking me from which ad
On Tue, Nov 13, 2012 at 12:35 AM, Jeff King wrote:
> On Sun, Nov 11, 2012 at 06:06:50PM +0100, Felipe Contreras wrote:
>
>> There's no point in asking this over and over if the user already
>> properly configured his/her name and email.
>>
>> Signed-off-by: Felipe Contreras
>> ---
>>
>> I got rea
On Tue, Nov 13, 2012 at 12:42:02AM +0100, Felipe Contreras wrote:
> > Why not use Git::ident_person() here? It saves some code, and would also
> > respect environment variables. Or better yet...
>
> I assume there was a reason why that code was asking for input;
> precisely because it would use t
On Mon, Nov 12, 2012 at 07:02:17PM -0500, Jeff King wrote:
> The one distinction that would make sense to me is pausing to ask when
> we use "implicit" methods to look up the ident, like concatenating the
> username with the hostname to get the email.
By the way, I suspect this is the answer to "
On Tue, Nov 13, 2012 at 1:02 AM, Jeff King wrote:
> On Tue, Nov 13, 2012 at 12:42:02AM +0100, Felipe Contreras wrote:
>
>> > Why not use Git::ident_person() here? It saves some code, and would also
>> > respect environment variables. Or better yet...
>>
>> I assume there was a reason why that code
Jeff King writes:
> On Mon, Nov 12, 2012 at 07:02:17PM -0500, Jeff King wrote:
>
>> The one distinction that would make sense to me is pausing to ask when
>> we use "implicit" methods to look up the ident, like concatenating the
>> username with the hostname to get the email.
>
> By the way, I su
On Tue, Nov 13, 2012 at 01:54:59AM +0100, Felipe Contreras wrote:
> > But we use the environment to default the field, so the distinction
> > doesn't make much sense to me. Plus, it has always been the case that
> > you can use git without setting user.*, but instead only using the
> > environmen
On Mon, Nov 12, 2012 at 10:27:27PM -0500, Jeff King wrote:
> On Tue, Nov 13, 2012 at 01:54:59AM +0100, Felipe Contreras wrote:
>
> > > But we use the environment to default the field, so the distinction
> > > doesn't make much sense to me. Plus, it has always been the case that
> > > you can use
On Tue, Nov 13, 2012 at 4:27 AM, Jeff King wrote:
> On Tue, Nov 13, 2012 at 01:54:59AM +0100, Felipe Contreras wrote:
>
>> > But we use the environment to default the field, so the distinction
>> > doesn't make much sense to me. Plus, it has always been the case that
>> > you can use git without
On Tue, Nov 13, 2012 at 04:55:25AM +0100, Felipe Contreras wrote:
> > No, it's not. Those broken names do not come from the environment, but
> > from our last-resort guess of the hostname.
>
> That depends how you define environment, but fine, the point is that
> it happens.
If you have a strawm
On Tue, Nov 13, 2012 at 5:01 AM, Jeff King wrote:
> On Tue, Nov 13, 2012 at 04:55:25AM +0100, Felipe Contreras wrote:
>
>> > No, it's not. Those broken names do not come from the environment, but
>> > from our last-resort guess of the hostname.
>>
>> That depends how you define environment, but fi
On Tue, Nov 13, 2012 at 7:42 AM, Felipe Contreras
wrote:
> 6) GIT_AUTHOR
>
> Who should the emails appear to be from? [Felipe Contreras 4th
> ]
>
> What about after my change?
>
> 6.1) GIT_AUTHOR without anything else
>
> fatal: empty ident name (for ) not allowed
> var GIT_COMMITTER_IDENT: comma
On Tue, Nov 13, 2012 at 07:42:58AM +0100, Felipe Contreras wrote:
> >> > No, it's not. Those broken names do not come from the environment, but
> >> > from our last-resort guess of the hostname.
> >>
> >> That depends how you define environment, but fine, the point is that
> >> it happens.
> >
> >
On Tue, Nov 13, 2012 at 8:47 AM, Jeff King wrote:
> But I still don't see how that has anything to do with what send-email
> does or should do. That is why I said "strawman" above. You seem to
> think I am saying that send-email should use the system that generated
> those broken names, when I am
Jeff King writes:
> On Tue, Nov 13, 2012 at 07:42:58AM +0100, Felipe Contreras wrote:
> ...
>> 5) GIT_COMMITTER
>>
>> Who should the emails appear to be from? [Felipe Contreras 2nd
>> ]
>>
>> Whoa, what happened there?
>>
>> Well:
>>
>> $sender = $repoauthor || $repocommitter || '';
>> ($
On Tue, Nov 13, 2012 at 10:06:26AM +0100, Felipe Contreras wrote:
> > Those people would also not be using a new version of git-send-email,
> > and it will always prompt. I thought we were talking about what
> > send-email should do in future versions. Namely, loosening that safety
> > valve (the
On Tue, Nov 13, 2012 at 08:13:04AM -0800, Junio C Hamano wrote:
> >> That's right, AUTHOR_IDENT would fall back to the default email and full
> >> name.
> >
> > Yeah, I find that somewhat questionable in the current behavior, and I'd
> > consider it a bug. Typically we prefer the committer ident
On Tue, Nov 13, 2012 at 12:35 AM, Jeff King wrote:
> On Sun, Nov 11, 2012 at 06:06:50PM +0100, Felipe Contreras wrote:
>
>> There's no point in asking this over and over if the user already
>> properly configured his/her name and email.
>>
>> Signed-off-by: Felipe Contreras
>> ---
>>
>> I got rea
Jeff King writes:
> On Tue, Nov 13, 2012 at 08:13:04AM -0800, Junio C Hamano wrote:
>
>> >> That's right, AUTHOR_IDENT would fall back to the default email and full
>> >> name.
>> >
>> > Yeah, I find that somewhat questionable in the current behavior, and I'd
>> > consider it a bug. Typically we
On Tue, Nov 13, 2012 at 5:48 PM, Jeff King wrote:
> On Tue, Nov 13, 2012 at 10:06:26AM +0100, Felipe Contreras wrote:
>> I think you are the one that is not understanding what I'm saying. But
>> I don't think it matters.
>>
>> This is what I'm saying; the current situation with 'git commit' is
>>
On Tue, Nov 13, 2012 at 09:35:18PM +0100, Felipe Contreras wrote:
> > Yes, dying would be a regression, in that you would have to configure
> > your name via the environment and re-run rather than type it at the
> > prompt. You raise a good point that for people who _could_ take the
> > implicit d
On Thu, Nov 15, 2012 at 1:07 AM, Jeff King wrote:
> On Tue, Nov 13, 2012 at 09:35:18PM +0100, Felipe Contreras wrote:
>
>> > Yes, dying would be a regression, in that you would have to configure
>> > your name via the environment and re-run rather than type it at the
>> > prompt. You raise a good
On Thu, Nov 15, 2012 at 02:41:50AM +0100, Felipe Contreras wrote:
> But that I meant that when I introduce a regression it's like I'm
> killing all that is good and sacred about git, and when you do it's
> everything but that.
The rhetoric in this statement is a good indication that there is
noth
On Thu, Nov 15, 2012 at 2:50 AM, Jeff King wrote:
> On Thu, Nov 15, 2012 at 02:41:50AM +0100, Felipe Contreras wrote:
>
>> But that I meant that when I introduce a regression it's like I'm
>> killing all that is good and sacred about git, and when you do it's
>> everything but that.
>
> The rhetor
26 matches
Mail list logo
