On Wed, Feb 13, 2013 at 10:55 PM, Junio C Hamano gits...@pobox.com wrote:
+ default:
+ return;
+ }
+ for (; first = last; first++)
This looks odd. If you use the usual last+1 convention between the
caller and callee, you do not have to do this, or call this function
XANi venit, vidit, dixit 14.02.2013 01:18:
Hi,
any functionality that depends on exact exit msg of program
can potentially fail because of that
ᛯ export |grep LANG
declare -x LANG=pl_PL.UTF-8
ᛯ ~/src/os/git/git log --format=%G? %h |head -2
0d19377
5b9d7f8
ᛯ unset LANG
ᛯ
Michael Haggerty mhag...@alum.mit.edu writes:
On 02/13/2013 03:56 PM, Matthieu Moy wrote:
Installation troubles:
I had an old python installation (Red Hat package, and I'm not root),
that did not include the email.utils package, so I couldn't use my
system's python. I found no indication
I just realized that many of my big repos are still on index v2 while
v4 should reduce its size significantly (3.8M - 2.9M for linux-2.6
and 25M - 14M for webkit, for example). I wanted to propose index v4
as the new default version, because I guess that not many people
outside git@vger are aware
On Sunday, February 10, 2013 at 08:26 EST,
demerphq demer...@gmail.com wrote:
Is windows stat really so slow?
Well, the problem is that there is no such thing as Windows stat :-)
I encountered this perception in windows Perl in the past, and I know
that on windows Perl stat *appears*
On Fri, Feb 8, 2013 at 10:10 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
For large repositories, many simple git commands like `git status`
take a while to respond. I understand that this is because of large
number of stat() calls to figure out which files were changed. I
overheard
The old Git version where it appeared is not useful only to historians,
not to normal users. Also, the text was mentioning only the per-repo
config file, so add a mention of ~/.gitconfig. Describing in details the
system-wide, XDG and all would be counter-productive here, so reword the
description
Currently, we look at the user facing output of gpg, which is LANG dependent as
well as insecure.
After this series, we look at the status output (--status-fd) which is designed
for that purpose. As an additional benefit, we can read off the key which was
used
for the signature, which is
Currently, verify_signed_buffer() only checks the return code of gpg,
and some callers implement additional unreliable checks for Good
signature in the gpg output meant for the user.
Use the status output instead and parse for a line beinning with
[GNUPG:] GOODSIG . This is the only reliable way
It's just so much betterer.
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net
---
log-tree.c | 25 +++--
1 file changed, 11 insertions(+), 14 deletions(-)
diff --git a/log-tree.c b/log-tree.c
index 5dc45c4..912fe08 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -508,20
Currently, verify_signed_buffer() returns the user facing output only.
Allow callers to request the status output also.
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net
---
builtin/fmt-merge-msg.c | 2 +-
builtin/verify-tag.c| 2 +-
gpg-interface.c | 11 +++
Currently, parse_signature_lines() parses the gpg output for strings
which depend on LANG so it fails to recognize good commit signatures
(and thus does not fill in %G? and the like) in most locales.
Make it parse the status lines from gpg instead, which are the proper
machine interface. This
Because we can.
No, really: In order to employ signed keys in an automated way it is
absolutely necessary to check which keys the signatures come from. Now
you can.
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net
---
Documentation/pretty-formats.txt | 1 +
pretty.c
Matthieu Moy venit, vidit, dixit 14.02.2013 16:36:
The old Git version where it appeared is not useful only to historians,
not to normal users. Also, the text was mentioning only the per-repo
I do not think you meant to not remove so many nots ;)
Besides, if history is uninteresting, then so
Michael J Gruber g...@drmicha.warpmail.net writes:
Matthieu Moy venit, vidit, dixit 14.02.2013 16:36:
The old Git version where it appeared is not useful only to historians,
not to normal users. Also, the text was mentioning only the per-repo
I do not think you meant to not remove so many
Ævar Arnfjörð Bjarmason ava...@gmail.com writes:
I looked into this a long while ago and remembered that rebase was
doing something like a git status for every commit that it made to
check the dirtyness.
This could be vastly improved by having an unsafe option to git-rebase
where it just
Mariusz Gronczewski xani...@gmail.com writes:
What is really missing is an ability to display used key ID without
hammering git log output with regexps, it would be much easier to
validate incoming commits if there was format option to just display
key ID instead of signer name. %GS isn't
Andrew Ardill andrew.ard...@gmail.com writes:
If that is the change we are going to make, and if you can guarantee
that nobody who is used to the historical behaviour will complain,
then I am fine with it, but I think the latter part of the condition
will not hold.
Does the impossibility of
Duy Nguyen pclo...@gmail.com writes:
On Wed, Feb 13, 2013 at 10:55 PM, Junio C Hamano gits...@pobox.com wrote:
+ default:
+ return;
+ }
+ for (; first = last; first++)
This looks odd. If you use the usual last+1 convention between the
caller and callee, you do not
Matthieu Moy matthieu@grenoble-inp.fr writes:
If the XDG config file ever become the default, then sure, it will have
to be promoted instead of ~/.gitconfig in git.txt (and I'll be all for
it when it's time, even though I can foresee a few flamewars ;-) ), but
I don't think we should do
Michael J Gruber g...@drmicha.warpmail.net writes:
Currently, verify_signed_buffer() only checks the return code of gpg,
and some callers implement additional unreliable checks for Good
signature in the gpg output meant for the user.
Use the status output instead and parse for a line
Junio C Hamano gits...@pobox.com writes:
But the exact location of per-user and per-repository configuration
files does not matter in this context and is best left to the
git-config documentation.
I'm OK with your version.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe
On Tue, Feb 12, 2013 at 02:33:42AM -0800, Brandon Casey wrote:
Teach append_signoff to detect whether a blank line exists at the position
that the signed-off-by line will be added, and refrain from adding an
additional one if one already exists. Or, add an additional line if one
is needed to
Matthieu Moy matthieu@grenoble-inp.fr writes:
Junio C Hamano gits...@pobox.com writes:
But the exact location of per-user and per-repository configuration
files does not matter in this context and is best left to the
git-config documentation.
I'm OK with your version.
I already queued
Junio C Hamano gits...@pobox.com writes:
W. Trevor King wk...@tremily.us writes:
On Sun, Feb 10, 2013 at 01:24:47PM -0800, Junio C Hamano wrote:
I would not be surprised if some readers felt as if then why not
update it instead of rejecting? were a valid question, without a
bit more
filter-branch --env-filter example that shows how to change the email address
in all commits by a certain developer.
---
Documentation/git-filter-branch.txt | 13 +
1 file changed, 13 insertions(+)
diff --git a/Documentation/git-filter-branch.txt
Tadeusz Andrzej Kadłubowski y...@hell.org.pl writes:
filter-branch --env-filter example that shows how to change the email address
in all commits by a certain developer.
---
Thanks. Sign-off?
Documentation/git-filter-branch.txt | 13 +
1 file changed, 13 insertions(+)
diff
On Thu, Feb 14, 2013 at 04:09:10PM -0500, Jeff King wrote:
I think the advice in the documentation about re-exporting is because
some versions of the bourne shell will not reliably pass the new version
of the variable when you do this:
VAR=old
export VAR
VAR=new
some_subprocess
Jeff King p...@peff.net writes:
I think it has always been the case that we export them after setting
them; just look at the preimage from 3c730fab, and you can see exports
there.
Yeah, I think the only difference is a broken commit case where sed
expression did not find what it was looking
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
A preview of the upcoming release 1.8.2-rc0 is expected to be tagged
late this week. At around that time, we may want to discard
long-stalled
Junio C Hamano gits...@pobox.com writes:
Andrew Ardill andrew.ard...@gmail.com writes:
If that is the change we are going to make, and if you can guarantee
that nobody who is used to the historical behaviour will complain,
then I am fine with it, but I think the latter part of the condition
Junio C Hamano gits...@pobox.com writes:
We should probably update the documentation/help for git add, but
that is entirely a separate topic.
The documentation update in 0fa2eb530fb7 (add: warn when -u or -A is
used without pathspec, 2013-01-28) says:
If no pathspec is given, the current
Junio C Hamano gits...@pobox.com writes:
warning: The behavior of 'git add --update (or -u)' with no path argument
from a
subdirectory of the tree will change in Git 2.0 and should not be used
anymore.
There is a logic gap between will change and should not be used
that is not
On 02/14/2013 01:55 PM, Matthieu Moy wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
On 02/13/2013 03:56 PM, Matthieu Moy wrote:
Installation troubles:
I had an old python installation (Red Hat package, and I'm not root),
that did not include the email.utils package, so I couldn't
34 matches
Mail list logo
