On 02/14/2013 01:55 PM, Matthieu Moy wrote:
> Michael Haggerty 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 m
Junio C Hamano 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 filled li
Junio C Hamano 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 is given, the current version of Git default
Junio C Hamano writes:
> Andrew Ardill 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
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 t
Jeff King 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 for, in whic
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_subpr
On Thu, Feb 14, 2013 at 12:29:36PM -0800, Junio C Hamano wrote:
> Quote the variable in double-quotes, like this:
>
> if [ "$GIT_AUTHOR_EMAIL" = j...@old.example.com ]
>
> Otherwise the comparison will break, if the e-mail part had a
> whitespace in it, or if it were empty, which is an exa
Tadeusz Andrzej Kadłubowski 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 --git a/D
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
b/Documentation/git-filter-branch.txt
Junio C Hamano writes:
> "W. Trevor King" 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 explanation.
>>>
>>>
Matthieu Moy writes:
> Junio C Hamano 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 your original with one s/not/now/;
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
Junio C Hamano 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 from this list:
Michael J Gruber 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 beinning with
> "[GNUPG:]
Matthieu Moy 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 that now.
We are giving a
Duy Nguyen writes:
> On Wed, Feb 13, 2013 at 10:55 PM, Junio C Hamano 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 thi
Andrew Ardill 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 asserting tha
Matthieu Moy writes:
> The old Git version where it appeared is not useful only to historians,
> not to normal users.
That statement cannot be generally true, unless the "old" is really
old and no longer relevant but 0.99.9 is sufficiently old so the
value of the part of the message you removed
Mariusz Gronczewski 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 really good solut
Ævar Arnfjörð Bjarmason 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 assumes that
Michael J Gruber 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 nots ;)
The first wa
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
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
---
Documentation/pretty-formats.txt | 1 +
pretty.c | 9 -
2 file
Currently, verify_signed_buffer() returns the user facing output only.
Allow callers to request the status output also.
Signed-off-by: Michael J Gruber
---
builtin/fmt-merge-msg.c | 2 +-
builtin/verify-tag.c| 2 +-
gpg-interface.c | 11 +++
gpg-interface.h | 2 +-
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 fixe
It's just so much betterer.
Signed-off-by: Michael J Gruber
---
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 +508,17 @@ static void sho
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 w
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 importan
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
On Fri, Feb 8, 2013 at 10:10 PM, Ramkumar Ramachandra
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 that Mercurial wa
On Sunday, February 10, 2013 at 08:26 EST,
demerphq 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* slow compared to
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
Michael Haggerty 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 about pyt
2013/2/14 Michael J Gruber :
> 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
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
On Sat, Feb 9, 2013 at 1:35 AM, Junio C Hamano wrote:
> We may want to refactor wt_status_print_state() and its callee a bit
> so that it and this part can share the logic without duplication and
> risk implementing subtly different decision. wt_status used to have
> clean separation between coll
On Wed, Feb 13, 2013 at 10:55 PM, Junio C Hamano 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
> wit
38 matches
Mail list logo
