On Sat, Oct 12, 2013 at 02:04:45AM -0500, Felipe Contreras wrote:
> So that we can specify general modes of operation, specifically, add the
> 'next' mode, which makes Git pre v2.0 behave as Git v2.0.
>
> Signed-off-by: Felipe Contreras
> ---
I don't think that single option it's a good idea. Fr
On Mon, Oct 14, 2013 at 04:35:50PM -0500, Felipe Contreras wrote:
> Krzysztof Mazur wrote:
> > On Sat, Oct 12, 2013 at 02:04:45AM -0500, Felipe Contreras wrote:
> > > So that we can specify general modes of operation, specifically, add the
> > > 'next' mode, w
On Tue, Oct 15, 2013 at 07:32:39AM -0500, Felipe Contreras wrote:
> Krzysztof Mazur wrote:
> >
> > But with core.mode = next after upgrade you may experience incompatible
> > change without any warning.
>
> Yes, and that is actually what the user wants. I mean, why wou
On Tue, Oct 15, 2013 at 08:29:56AM -0500, Felipe Contreras wrote:
> Krzysztof Mazur wrote:
> > On Tue, Oct 15, 2013 at 07:32:39AM -0500, Felipe Contreras wrote:
> > > Krzysztof Mazur wrote:
> > > >
> > > > But with core.mode = next after upgrade you
On Tue, Oct 15, 2013 at 01:51:41PM -0500, Felipe Contreras wrote:
>
> I don't see what is the problem. We haven't had the need for push.default =
> simplewarning, have we? If you want the warning, you don't change anything, if
simplewarning makes no sense, because push.default=simple sets exact
b
On Tue, Oct 15, 2013 at 11:03:26PM -0500, Felipe Contreras wrote:
> > not some "next" behavior that may change in future.
>
> But I'm suggesting to add a core.addremove option as well, like you suggested,
> am I not?
Yes, I think we both agreed on adding core.addremove. I'm just not
convinced if
On Tue, Oct 15, 2013 at 10:55:07PM -0500, Felipe Contreras wrote:
> John Szakmeister wrote:
> >
> > I like the idea that we could kick git into a mode that applies the
> > behaviors we're talking about having in 2.0, but I'm concerned about
> > one aspect of it. Not having these behaviors until 2
On Wed, Nov 07, 2012 at 02:16:52PM -0500, Paul Fox wrote:
> the user's editor likely catches SIGINT (ctrl-C). but if the user
> spawns a command from the editor and uses ctrl-C to kill that command,
> the SIGINT will likely also kill git itself. (depending on the
> editor, this can leave the term
On Sat, Nov 10, 2012 at 10:55:13AM +0100, Angelo Borsotti wrote:
> Hi
>
> the man page of git-reset, synopsys, does not allow for an
> argumentless call, and the description does not tell either what is
> the meaning of it.
This issue was already reported by Bojan Petrović:
http://thread.gmane.or
On Sat, Nov 10, 2012 at 12:02:12PM -0800, Junio C Hamano wrote:
> Krzysztof Mazur writes:
>
> > Maybe we should just add that is an shortcut for
> > and fix places where paths and pathspec are mixed or is used as
> > .
>
> We should unify uses of and
On Sun, Nov 11, 2012 at 11:09:36AM -0200, Thiago Farina wrote:
> On Sun, Nov 11, 2012 at 10:14 AM, Felipe Contreras
> wrote:
> > Requiring everyone to use a web browser would limit the amount of ways
> > people can review patches.
> I don't see that as a limitation as I think everyone has access t
On Sun, Nov 11, 2012 at 11:31:00AM -0500, Jeff King wrote:
>
> Here's a series that I think should resolve the situation for everybody.
>
> [1/5]: launch_editor: refactor to use start/finish_command
>
> The cleanup I sent out a few minutes ago.
>
> [2/5]: launch_editor: ignore SIGINT while
On Sun, Nov 11, 2012 at 03:24:19PM -0500, Paul Fox wrote:
> krzysztof wrote:
> > Looks ok, but what about SIGQUIT? Some editors like GNU ed (0.4 and 1.6)
> > ignore SIGQUIT, and after SIGQUIT git dies, but editor is still running.
> > After pressing any key ed receives -EIO and prints "stdin: In
On Sun, Nov 18, 2012 at 11:55:09AM -0500, Drew Northup wrote:
>
> > So we should always use "" for exact path, and "" for
> > pathspecs patterns as defined in gitglossary. I think it's better
> > to avoid "" and always use "..." or "..."
>
> I suspect that the only reason why the differentiation
On Mon, Nov 19, 2012 at 11:57:47AM +0200, Felipe Balbi wrote:
> Hi guys,
>
> for whatever reason my git has started acting up with
> sta...@vger.kernel.org addresses. It doesn't manage to extract a valid
> adress from the string:
>
> Cc: # v3.4 v3.5 v3.6
>
> Removing the comment at the end of
ddress and Email::Valid
validates it correctly.
Signed-off-by: Krzysztof Mazur
---
git-send-email.perl | 4
1 file changed, 4 insertions(+)
diff --git a/git-send-email.perl b/git-send-email.perl
index 5a7c29d..9840d0a 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -924,6 +924
On Mon, Nov 19, 2012 at 04:00:09PM -0800, Junio C Hamano wrote:
> Krzysztof Mazur writes:
>
> > On Mon, Nov 19, 2012 at 11:27:45AM -0800, Junio C Hamano wrote:
> >> Given that the problematic line
> >>
> >>Stable Kernel Maintainance Track # vX.
On Mon, Nov 19, 2012 at 03:57:36PM -0800, Junio C Hamano wrote:
> Felipe Contreras writes:
>
> > On Mon, Nov 19, 2012 at 11:58 PM, Krzysztof Mazur
> > wrote:
> >
> >> --- a/git-send-email.perl
> >> +++ b/git-send-email.perl
> >> @@ -924,6 +924
On Tue, Nov 20, 2012 at 08:31:00AM +0100, Krzysztof Mazur wrote:
> On Mon, Nov 19, 2012 at 03:57:36PM -0800, Junio C Hamano wrote:
> > Felipe Contreras writes:
> >
> > > On Mon, Nov 19, 2012 at 11:58 PM, Krzysztof Mazur
> > > wrote:
> > >
> > &g
On Tue, Nov 20, 2012 at 11:28:39AM +0100, Felipe Contreras wrote:
> On Tue, Nov 20, 2012 at 8:56 AM, Krzysztof Mazur
> wrote:
>
> > --- a/git-send-email.perl
> > +++ b/git-send-email.perl
> > @@ -925,8 +925,11 @@ sub quote_subject {
> > sub sanitize_add
In the fallback check, when Email::Valid is not available, the
extract_valid_address() does not check for success of matching regex,
and $1, which can be undefined, is always returned. Now if match
fails an empty string is returned.
Signed-off-by: Krzysztof Mazur
---
This fixes following
On Tue, Nov 20, 2012 at 12:27:36PM -0800, Junio C Hamano wrote:
> Krzysztof Mazur writes:
>
> > In the fallback check, when Email::Valid is not available, the
> > extract_valid_address() does not check for success of matching regex,
> > and $1, which can be undefined, is
ze_address() everything after the email address is
removed, so the resulting line is correct email address and Email::Valid
validates it correctly.
To avoid unnecessary complexity this code assumes that in phrase before
email address '' never exists.
Signed-off-by: Krzysztof Mazur
---
On Tue, Nov 20, 2012 at 02:30:02PM -0800, Junio C Hamano wrote:
> Felipe Contreras writes:
>
> > On Tue, Nov 20, 2012 at 10:21 PM, Krzysztof Mazur
> > wrote:
> >
> >> --- a/git-send-email.perl
> >> +++ b/git-send-email.perl
> >> @@ -924,6 +924
On Tue, Nov 20, 2012 at 09:46:47PM -0500, Paul Fox wrote:
> junio c hamano wrote:
> > Here is a list of stalled topics I am having trouble deciding what
> > to do (the default is to dismiss them around feature freeze).
> ...
> > * pf/editor-ignore-sigint (2012-11-11) 5 commits
> >
> > Avoid
e email address.
Now in sanitize_address() everything after the email address is
removed, so the resulting line is correct email address and Email::Valid
validates it correctly.
Signed-off-by: Krzysztof Mazur
Tested-by: Felipe Balbi
---
git-send-email.perl | 4
1 file changed, 4 insertions
In some cases the user may want to send email with "Cc:" line with
email address we cannot extract. Now we allow user to extract
such email address for us.
Signed-off-by: Krzysztof Mazur
---
git-send-email.perl | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff -
We used to warn about invalid emails and just drop them. Such warnings
can be unnoticed by user or noticed after sending email when we are not
giving the "final sanity check [Y/n]?"
Now we quit by default.
Signed-off-by: Krzysztof Mazur
Suggested-by: Junio C Hamano
---
git-send-
.
Signed-off-by: Krzysztof Mazur
---
git-send-email.perl | 52 +++-
1 file changed, 39 insertions(+), 13 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 356f99d..5056fdc 100755
--- a/git-send-email.perl
+++ b/git-send
herwise.
Now if match fails undefined value is always returned to indicate error.
The same value is used by Email::Valid->address() in that case.
Previously 'foo@bar' address was rejected by Email::Valid and fallback,
but '' was rejected by Email::Valid, but accepted by fa
On Sat, Nov 24, 2012 at 09:44:51PM -0500, Eric S. Raymond wrote:
>
> We're behind the best-practices curve here. The major Linux
> distributions, which have to deal with almost the same set of
> tradeoffs we do, went to Python for pretty much all glue and
> administration scripts outside /etc a d
On Mon, Nov 26, 2012 at 10:40:00AM +0530, Sitaram Chamarty wrote:
> On Mon, Nov 26, 2012 at 4:17 AM, Eric S. Raymond wrote:
> > Krzysztof Mazur :
> >> What about embedded systems? git is also useful there. C and shell is
> >> everywhere, python is not.
> >
On Mon, Nov 26, 2012 at 09:08:34AM -0800, Junio C Hamano wrote:
> Krzysztof Mazur writes:
>
> > In some cases the user may want to send email with "Cc:" line with
> > email address we cannot extract. Now we allow user to extract
> > such email address for us
On Mon, Nov 26, 2012 at 02:58:58PM -0800, Junio C Hamano wrote:
> Krzysztof Mazur writes:
>
> >> Not having this new code inside "elsif (/^e/) { }" feels somewhat
> >> sloppy, even though it is not *too* bad. Also do we know this
> >
> > ok, I will
On Mon, Nov 26, 2012 at 03:50:30PM -0800, Junio C Hamano wrote:
> Krzysztof Mazur writes:
>
> > On Mon, Nov 26, 2012 at 02:58:58PM -0800, Junio C Hamano wrote:
> >> Krzysztof Mazur writes:
> >>
> >> >> Not having this new code inside "els
Looks good to me. I've tested this with ed (always ignores SIGINT
and SIGQUIT), vim (always ignores SIGINT, but dies after three
SIGQUIT) and "sleep" (dies after SIGINT and SIGQUIT) and git works now
as expected. Doing what editor does is probably the best thing to do.
Tested-by
On Thu, May 09, 2013 at 03:13:39AM +0200, Sven Strickroth wrote:
> With MSVC initializing a variable with "int a=a" causes a warning about
> using an uninitialized value.
>
> Signed-off-by: Sven Strickroth
> ---
> builtin/rev-list.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> di
The introduction email (--compose option) use UTF-8 as default encoding.
The current locale encoding is much better default value.
Signed-off-by: Krzysztof Mazur
---
git-send-email.perl | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/git-send-email.perl b/git
n email is missing.
Added compose-encoding command line option and sendemail.composeencoding
configuration option specify encoding of introduction email.
Signed-off-by: Krzysztof Mazur
---
Documentation/git-send-email.txt | 5 +
git-send-email.perl | 9 -
2 files c
On Tue, Oct 09, 2012 at 02:34:59PM -0700, Junio C Hamano wrote:
> Krzysztof Mazur writes:
>
> > The introduction email (--compose option) use UTF-8 as default encoding.
> > The current locale encoding is much better default value.
> >
>
> These two patches make
The commit "git-send-email: introduce compose-encoding" introduced
the compose-encoding option to specify the introduction email encoding
(--compose option), but the email Subject encoding was still hardcoded
to UTF-8.
Signed-off-by: Krzysztof Mazur
---
Patch against km/send-ema
The git-send-email always use RFC2047 subject quoting for files
with "broken" encoding - non-ASCII files without Content-Transfer-Encoding,
even for ASCII subjects. Now for ASCII subjects the RFC2047 quoting will be
skipped.
Signed-off-by: Krzysztof Mazur
---
git-send-email.perl |
On Wed, Oct 24, 2012 at 04:46:36AM -0400, Jeff King wrote:
> On Wed, Oct 24, 2012 at 10:03:35AM +0200, Krzysztof Mazur wrote:
>
> > The git-send-email always use RFC2047 subject quoting for files
> > with "broken" encoding - non-ASCII files without Content-Transfer-
2047_quoting() and we will have:
/=?/ || /[^[:ascii:]]/
and in the latter case:
!is_rfc2047_quoted($subject) && (/=\?/ || /^[:ascii:]]/)
This will also add quoting for any rfc2047 quoted subject or any
other rfc2047-like subject, as you suggested.
Krzysiek
--
>From a70c5385f9b4da69a8c
For raw subjects rfc2047 quoting is needed not only for non-ASCII characters,
but also for any possible rfc2047 in it.
Signed-off-by: Krzysztof Mazur
---
Oops, this ugly Subject was generated by git format-patch (both 1.8.0
and km/send-email-compose-encoding).
git-send-email.perl | 2 +-
1
On Thu, Oct 25, 2012 at 05:01:49AM -0400, Jeff King wrote:
>
> Hmm. What is this patch on top of? It looks like it is on top of your
> original patch, but when I tried it on top of that, it does not apply
> either, and the index lines in the patch do not mention a sha1 that I do
> not have.
Sorry
On Thu, Oct 25, 2012 at 06:08:54AM -0400, Jeff King wrote:
>
> Ah, never mind. I missed your earlier "use compose-encoding for
> Subject". I've queued it and all of the follow-ons onto the
> km/send-email-compose-encoding topic.
>
thanks, what about the problem with whitespaces in "quote_subject
x27;s "--" is an optional argument, however it was
documented as required.
Signed-off-by: Krzysztof Mazur
---
Documentation/git-reset.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
index 117e374..1f95292 10
On Sun, Oct 28, 2012 at 09:46:35AM -0400, Jeff King wrote:
> On Sun, Oct 28, 2012 at 02:39:49PM +0100, Andreas Schwab wrote:
>
> > Jeff King writes:
> >
> > > On Sun, Oct 28, 2012 at 09:36:10AM +0100, Krzysztof Mazur wrote:
> > >
> > >> DESCR
On Fri, Jan 25, 2013 at 07:28:54PM +0400, Alexey Shumkin wrote:
> "git format-patch --attach/--inline" generates multi-part messages.
> Every part of such messages can contain non-ASCII characters with its own
> "Content-Type" and "Content-Transfer-Encoding" headers.
> But git-send-mail script inte
50 matches
Mail list logo
