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 we
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.0 hits
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, which makes Git pre v2.0 behave as Git v2.0
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 would the user set
core.mode=next
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 may experience incompatible
change without any warning
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 felipe.contre...@gmail.com
---
I don't think that single
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 em...@cs-ware.de
---
builtin/rev-list.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
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 interprets a
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: Krzysztof Mazur krzys...@podlesie.net
Thanks
On Mon, Nov 26, 2012 at 03:50:30PM -0800, Junio C Hamano wrote:
Krzysztof Mazur krzys...@podlesie.net writes:
On Mon, Nov 26, 2012 at 02:58:58PM -0800, Junio C Hamano wrote:
Krzysztof Mazur krzys...@podlesie.net writes:
Not having this new code inside elsif (/^e/) { } feels somewhat
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 e...@thyrsus.com wrote:
Krzysztof Mazur krzys...@podlesie.net:
What about embedded systems? git is also useful there. C and shell is
everywhere, python is not.
Supposing
On Mon, Nov 26, 2012 at 09:08:34AM -0800, Junio C Hamano wrote:
Krzysztof Mazur krzys...@podlesie.net 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.
Signed-off
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
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 krzys...@podlesie.net
---
git-send-email.perl | 9 ++---
1 file changed, 6 insertions(+), 3 deletions
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 krzys...@podlesie.net
Suggested-by: Junio C Hamano gits
.
Signed-off-by: Krzysztof Mazur krzys...@podlesie.net
---
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
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 'foo@bar' was rejected by Email::Valid, but accepted by fallback.
Signed-off-by: Krzysztof Mazur
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 confusing
On Tue, Nov 20, 2012 at 11:28:39AM +0100, Felipe Contreras wrote:
On Tue, Nov 20, 2012 at 8:56 AM, Krzysztof Mazur krzys...@podlesie.net
wrote:
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -925,8 +925,11 @@ sub quote_subject {
sub sanitize_address {
my ($recipient
On Tue, Nov 20, 2012 at 12:27:36PM -0800, Junio C Hamano wrote:
Krzysztof Mazur krzys...@podlesie.net 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 always
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 'something' never exists.
Signed-off-by: Krzysztof Mazur krzys...@podlesie.net
---
git-send-email.perl
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: sta...@vger.kernel.org # v3.4 v3.5 v3.6
Removing the comment
::Valid
validates it correctly.
Signed-off-by: Krzysztof Mazur krzys...@podlesie.net
---
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
On Mon, Nov 19, 2012 at 04:00:09PM -0800, Junio C Hamano wrote:
Krzysztof Mazur krzys...@podlesie.net writes:
On Mon, Nov 19, 2012 at 11:27:45AM -0800, Junio C Hamano wrote:
Given that the problematic line
Stable Kernel Maintainance Track sta...@vger.kernel.org # vX.Y
On Mon, Nov 19, 2012 at 03:57:36PM -0800, Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
On Mon, Nov 19, 2012 at 11:58 PM, Krzysztof Mazur krzys...@podlesie.net
wrote:
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -924,6 +924,10 @@ sub
On Sun, Nov 18, 2012 at 11:55:09AM -0500, Drew Northup wrote:
So we should always use path for exact path, and pathspec for
pathspecs patterns as defined in gitglossary. I think it's better
to avoid paths and always use path... or pathspec...
I suspect that the only reason why the
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:
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ć:
On Sat, Nov 10, 2012 at 12:02:12PM -0800, Junio C Hamano wrote:
Krzysztof Mazur krzys...@podlesie.net writes:
Maybe we should just add that paths is an shortcut for pathspec
and fix places where paths and pathspec are mixed or path is used as
pathspec.
We should unify uses of paths
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
brackets are also missing in 'git reset' --mode [commit].
Bojan, do you want to add a Reported-by line with your name?
Krzysiek
-- 8 --
Subject: [PATCH] doc: git-reset: make --mode optional
The git-reset's --mode is an optional argument, however it was
documented as required.
Signed-off-by: Krzysztof
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 p...@peff.net writes:
On Sun, Oct 28, 2012 at 09:36:10AM +0100, Krzysztof Mazur wrote:
DESCRIPTION
---
@@ -43,7 +43,7 @@ This means
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 patch?
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 krzys...@podlesie.net
---
git-send
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-Encoding,
even for ASCII subjects
:]]/)
This will also add quoting for any rfc2047 quoted subject or any
other rfc2047-like subject, as you suggested.
Krzysiek
--
From a70c5385f9b4da69a8ce00a1448f87f63bbd500d Mon Sep 17 00:00:00 2001
From: Krzysztof Mazur krzys...@podlesie.net
Date: Wed, 24 Oct 2012 22:46:00 +0200
Subject: [PATCH] git-send-email
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 krzys...@podlesie.net
---
Oops, this ugly Subject was generated by git format-patch (both 1.8.0
and km/send-email-compose-encoding).
git-send
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 krzys...@podlesie.net
---
Patch against km/send
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 krzys...@podlesie.net
---
git-send-email.perl | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/git
is missing.
Added compose-encoding command line option and sendemail.composeencoding
configuration option specify encoding of introduction email.
Signed-off-by: Krzysztof Mazur krzys...@podlesie.net
---
Documentation/git-send-email.txt | 5 +
git-send-email.perl | 9 -
2 files
41 matches
Mail list logo
