Hi,
I was pulling in some changes in the morning to find:
Auto packing the repository for optimum performance. You may also
run "git gc" manually. See "git help gc" for more information.
Being my usual impatient self, I opened another prompt and started
merging changes. After the checkout, it
Junio C Hamano wrote:
> Having said all that, the patch texts all look OK, so I'll queue
> them with updated log messages. It was the usual me reacting to
> unjustified value judgement made in log messages and cover letters.
Thanks. I'll look at how the log messages are different in the queued
v
,
convert the *_quote_print functions and callers to *_quote_buf.
[rr: commit message, minor modifications]
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Ramkumar Ramachandra
---
builtin/for-each-ref.c | 13 +
quote.c| 44
) for the purpose of printing argv for $GIT_TRACE. Today, we
achieve this using trace_argv_printf() -> sq_quote_argv() ->
sq_quote_buf(), which ultimately fills in a strbuf.
Signed-off-by: Ramkumar Ramachandra
Signed-off-by: Nguyễn Thái Ngọc Duy
---
quote.c | 17 -
quote.h
Currently, there is exactly one caller of sq_quote_print(), namely
cmd_tar_tree(). In the interest of removing sq_quote_print() and
simplification, replace it with an equivalent call to sq_quote_argv().
No functional changes intended.
Signed-off-by: Ramkumar Ramachandra
Signed-off-by: Nguyễn
Hi,
While going through the for-each-ref-pretty series that Duy and I were
developing, I noticed that this cleanup was independent and good
as-it-is.
So here it is.
Nguyễn Thái Ngọc Duy (1):
for-each-ref, quote: convert *_quote_print -> *_quote_buf
Ramkumar Ramachandra (2):
tar-t
Junio C Hamano wrote:
> Ramkumar Ramachandra writes:
>> Junio C Hamano wrote:
>>> That's a bit strange---the patch text looks like the "how about
>>> this" patch Duy posted earlier. Shouldn't it be From: Duy with
>>> S-o-b: by two of
Junio C Hamano wrote:
> That's a bit strange---the patch text looks like the "how about
> this" patch Duy posted earlier. Shouldn't it be From: Duy with
> S-o-b: by two of you instead?
Feel free to amend as you see fit, as always.
> For editors that are not broken, this could be an annoying
> re
Ralf Thielow wrote:
> diff --git a/git-rebase.sh b/git-rebase.sh
> index 0039ecf..8d7659a 100755
> --- a/git-rebase.sh
> +++ b/git-rebase.sh
> @@ -159,7 +159,7 @@ finish_rebase () {
> die "$(eval_gettext "Cannot store \$stash_sha1")"
> gettext 'Applyi
Ondřej Bílka wrote:
> diff --git a/builtin/log.c b/builtin/log.c
> index 2625f98..01b49b3 100644
> --- a/builtin/log.c
> +++ b/builtin/log.c
> @@ -304,7 +304,7 @@ static void setup_early_output(struct rev_info *rev)
> * tenth of a second, don't even bother doing the
> * early-outp
Co-authored-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Ramkumar Ramachandra
---
Urgent candidate for maint. I wrote to emacs-devel, but nobody seems
to be interested; the sources are horrendously unmaintainable, and
the project should die soon.
editor.c | 2 +-
1 file changed, 1 insertion(+)
Duy Nguyen wrote:
> How about something like this as a workaround for emacs?
Even if we do manage to patch Emacs now, we still need to support
older versions: so yeah, this is an urgent candidate for maint. I'm
waiting for the word from Emacs-Devel before writing out a commit
message.
--
To unsub
Duy Nguyen wrote:
> In the no-submodules symlink test case, the path given to the editor
> is .git/COMMIT_EDITMSG, no following ".." back in the symlink target.
Thanks, and sorry about the stupidity. I just patched
builtin/commit.c to check this.
> This bug can be reproduced without git involved
Duy Nguyen wrote:
> I think instead of letting the kernel walk the path, emacs does it by
> itself.
If this were true, shouldn't we be able to reproduce the behavior with
my no-submodules symlink testcase? How can it resolve symlinks in one
case, and not in the other case?
--
To unsubscribe from
Jiang Xin wrote:
> I change the EDITOR(GIT_EDITOR) environment in your test script
> as follows:
>
> GIT_EDITOR="echo PWD: $(pwd); echo REALPATH: $(pwd -P); echo" \
> git commit --amend
See, what stumps be about this is the no-submodule case:
#!/bin/sh
mygit=~/src/git/git
cd /tmp
Duy Nguyen wrote:
> I was involved with this code (the gitdir setup code, not submodule)
> and am interested to know what's going on too. Could you produce a
> small script to reproduce it?
Here's your reduced testcase. Just point mygit to a HEAD build.
#!/bin/sh
mygit=~/src/git/git
cd /tm
Duy Nguyen wrote:
> 044bbbc (Make git_dir a path relative to work_tree in
> setup_work_tree() - 2008-06-19)
Okay, so it does seem to be a significant optimization. Frankly,
e02ca72 only improves the relative_path() algorithm, and it's not
really doing anything Wrong: it's has just uncovered a pre
Fredrik Gustafsson wrote:
> When I hear submodules
The only reason this bug has something to do with submodules is
because of the relative path in the gitfile (although I'm yet to
corner the exact issue). Otherwise, it doesn't exercise any new code
in submodule.c/ git-submodule.sh.
--
To unsubscr
Ramkumar Ramachandra wrote:
> e02ca72 (path.c: refactor relative_path(), not only strip prefix,
> 2013-06-25) is the offender.
The problem is the callsite in setup.c:setup_work_tree(). When
relative_path() is called with
"/home/artagnon/dotfiles/.git/modules/.elisp/flx" and
Ramkumar Ramachandra wrote:
> *scratches head*
Just took a much-needed shower and came back. It was trivial to find.
$ git log v1.8.3.4.. -- path.c
e02ca72 (path.c: refactor relative_path(), not only strip prefix,
2013-06-25) is the offender.
--
To unsubscribe from this list: send the l
Hi,
I noticed a regression in the latest master, and I've been trying to
debug it for 30 minutes now. I'm still clueless about the root cause,
but I'll list whatever I found so far:
I suddenly noticed that I wasn't able to commit to a certain
repository with submodules anymore. This was because
Jonathan Nieder wrote:
>> Your patch is just swapping out "git reset" for "cherry-pick --abort",
>> so I think that is a good improvement in the meantime.
>
> Um, wasn't the idea of the original message that you can run "git
> reset" and then "git cherry-pick --continue"?
No, and I don't know wher
Jeff King wrote:
> builtin/commit.c | 25 ++---
> 1 file changed, 22 insertions(+), 3 deletions(-)
Overall, highly inelegant. The single-commit pick has been special
cased only because we needed to preserve backward compatibility: I
would hate for the detail to be user-visibl
Jeff King wrote:
> Ah. I don't mind improving the message in the meantime, but it sounds
> like this is a deficiency in sequenced cherry-pick that needs addressed
> eventually.
I'm especially irked by how slow rebase--am is, and want to replace it.
--
To unsubscribe from this list: send the line "
Jeff King wrote:
> Hmm. I don't think I've run across this message myself, so perhaps I do
> not understand the situation.
It's very simple.
# on branch master
$ git checkout -b test
$ git cherry-pick master
$ ls .git/sequencer
# missing
In the pseudo multi-pick case (I say "pseudo" be
case of a ranged pick, as a 'git
reset' will fail to remove $GIT_DIR/sequencer, failing a subsequent
cherry-pick or revert. Change the advice to:
git cherry-pick --abort
Signed-off-by: Ramkumar Ramachandra
---
Another candidate for maint?
I'd also really like to squelch this
uniformly, just like config.txt does.
Signed-off-by: Ramkumar Ramachandra
---
Candidate for maint?
Documentation/git-config.txt | 26 ++
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt
index 34b0894
Junio C Hamano wrote:
> * mv/merge-ff-tristate (2013-07-02) 1 commit
> (merged to 'next' on 2013-07-09 at c32b95d)
> + merge: handle --ff/--no-ff/--ff-only as a tri-state option
Sorry I didn't notice sooner, but I was confused by the second test
title this added:
test_expect_success 'option --
Ondřej Bílka wrote:
> diff --git a/builtin/checkout.c b/builtin/checkout.c
> index 7fe0bff..9f29bb2 100644
> --- a/builtin/checkout.c
> +++ b/builtin/checkout.c
> @@ -1137,7 +1137,7 @@ int cmd_checkout(int argc, const char **argv, const
> char *prefix)
> * 3) git checkout []
>
Ondřej Bílka wrote:
> http://marc.theaimsgroup.com/?l=git&m=112927316408690&w=2
Just run a sed 's|http://marc.theaimsgroup.com|http://marc.info|', and
submit the resulting patch.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
Benoit Sigoure wrote:
> diff --git a/compat/unsetenv.c b/compat/unsetenv.c
> index 4ea1856..addf3dc 100644
> --- a/compat/unsetenv.c
> +++ b/compat/unsetenv.c
> @@ -1,5 +1,10 @@
> #include "../git-compat-util.h"
>
> +#ifdef __APPLE__
> +// On OS X libc headers don't define this symbol.
> +extern c
Junio C Hamano wrote:
> That limits the context we could use "-" and we cannot consistently
> use it everywhere. I find _that_ ugly from the "design cleanliness"
> point of view.
Right, noted.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@v
Junio C Hamano wrote:
> git branch -t "$branchname" "origin/$branchname"
A couple of notes here:
1. I use git branch -u personally. Why the -t variant?
2. Don't we auto-track? (or is that only on checkout)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the bod
Junio C Hamano wrote:
> You would at least need "xargs -n 1" for the produced command line
> to make any sense, and it is wasteful to actually check out each
> and every branch to the working tree only to create it.
Right. xargs -n 1, git branch, and refname:short.
--
To unsubscribe from this lis
Junio C Hamano wrote:
> Did you know that the general way to spell the branch previously you
> were on is "@{-1}" and "checkout -" is an ugly special case that is
> possible only because "checkout" does not happen to take a "-" as a
> valid argument that means something else (like the more usual "r
Andreas Schwab wrote:
> Ramkumar Ramachandra writes:
>
>> # er, what was the branch name again?
>> $ git checkout -
>
> You could take a look in the reflog.
Yeah, or use the @{-N} revision to do that for me. My scripted
version is essentially:
test "true&qu
Damn it: checkout doesn't get executed at all because the $mb = $onto
condition fails; I was looking in the wrong place. It's format-patch
and am that are slowing things down terribly. Has anyone looked into
stripping out the dependency? Why is cherry-pick deficient?
My current workaround is to
Ramkumar Ramachandra wrote:
> diff --git a/git-rebase.sh b/git-rebase.sh
> index 0039ecf..7405d9a 100755
> --- a/git-rebase.sh
> +++ b/git-rebase.sh
Er, sorry. I think it suffices to check that $branch_name equals
HEAD, for this optimization.
--
To unsubscribe from this list: s
Ramkumar Ramachandra wrote:
> Sebastian Staudt wrote:
>> Isn't this what you want?
>>
>> $ git rebase master um-build
>
> Ha, yes. Sorry about the stupidity.
Hm, I'm not entirely sure how to optimize the codepath to eliminate
the checkout. It seems to be a
Sebastian Staudt wrote:
> Isn't this what you want?
>
> $ git rebase master um-build
Ha, yes. Sorry about the stupidity.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordom
Hi,
Many of my ideas turn out to be really stupid, and I need to throw
away my feature branch. So, I find myself doing this often:
# on branch menuconfig-jk
$ git checkout master
$ git branch -D
# er, what was the branch name again?
$ git checkout -
# Ah
$ git checkout master
$ g
Hi,
I'm often work on small topic branches, and find myself doing this quite often:
# on branch master
$ git checkout um-build
$ git rebase master
This is horribly inefficient; the first operation takes a _really_
long time to complete, since master updates itself very often and I
have to
Allan Acheampong wrote:
> I could write a script with for each in but thats way too much hassle
$ git for-each-ref --format="%(refname)" refs/remotes/origin/ | sed
's/refs\/remotes\/origin\///;/HEAD\|master/d' | xargs git checkout -b
(completely untested ofcourse)
Do you see what the problem i
Junio C Hamano wrote:
> Ramkumar, as you will still be the primary author of the resulting
> commit, I tentatively added a line for your sign-off even though you
> haven't signed off _this_ version yet, so that I would not forget.
> If this version looks good, please tell us you would.
Yeah, it se
brian m. carlson wrote:
> I didn't stick the require in the eval because git-send-email will fail
> in this case anyway if you don't have it, since Net::SMTP::SSL requires
> it. Let me know if you want a patch for this on top of the existing two
> in this series and I'll provide one.
Yeah, that'd
Torsten Bögershausen wrote:
> /usr/bin/perl -MIO::Socket::SSL -e 'print "$IO::Socket::SSL::VERSION\n";'
> 1.22
This is ancient! (I have 1.84). Is it not possible to do an
ssl-verify-peer in older versions (is it exported as something else)?
The older versions don't display the warning anyway, an
Jeff King wrote:
> git rev-list --objects HEAD |
> git cat-file --batch-check='%(objectsize) %(text)'
If anything, I would have expected %(rest), not %(text). This atom is
specific to commands that accept input via stdin (i.e. not log, f-e-r,
branch, or anything else I can think of).
Also, t
Jeff King wrote:
> +If `--batch` or `--batch-check` is given, `cat-file` will read objects
> +from stdin, one per line, and print information about them.
> +
> +You can specify the information shown for each object by using a custom
> +``. The `` is copied literally to stdout for each
> +object, wi
Jeff King wrote:
> That does O(n log n) offset comparisons, and profiling shows
> that we spend most of our time in cmp_offset. However, since
> we are sorting on a simple off_t, we can use numeric sorts
> that perform better. A radix sort can run in O(k*n), where k
> is the number of "digits" in o
Junio C Hamano wrote:
> $ git describe $(git rev-parse v1.8.3)
> v1.8.3
> $ git describe --contains $(git rev-parse v1.8.3)
> v1.8.3^0
This is a correct observation, and I've already submitted the correct
fix: "name-rev: strip trailing ^0 in when --name-only".
> $ git describe
database access, then it will fill all atoms that need odb.
Which is not a bad thing. We don't want to access odb once at sorting
phase and again at display phase.
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Ramkumar Ramachandra
---
builtin/for-each-ref.c | 49 ++
am)'. This is important because verify_format populates
used_atom, which get_value() and populate_value() later rely on.
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Ramkumar Ramachandra
---
builtin/for-each-ref.c | 15 +--
pretty.c | 4
2 files changed, 13
might like to define their own builtins in
the future.
Signed-off-by: Ramkumar Ramachandra
Signed-off-by: Nguyễn Thái Ngọc Duy
---
commit.h | 1 +
pretty.c | 25 +
2 files changed, 26 insertions(+)
diff --git a/commit.h b/commit.h
index ced7100..331a2db 100644
--- a
is automatically stripped and
ignored. Separator semantics are not configurable (yet).
2. No built-in formats are available. The ones specified in
pretty-formats (oneline, short etc) don't make sense when displaying
refs anyway.
Signed-off-by: Ramkumar Ramachandra
g format in for-each-ref:
%C(green)%(refname:short)%C(reset)%(upstream:trackshort)
to display refs with terse tracking information.
Note that :track and :trackshort only work with upstream, and error out
when used with anything else.
Signed-off-by: Ramkumar Ramachandra
Signed-off-by: Nguyễn Thái Ngọc Duy
--
rs, not ones coming from pretty.c). They calculate
the best width for the %(fieldname), ignoring ansi escape sequences if
any.
[rr: documentation]
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Ramkumar Ramachandra
---
Documentation/git-for-each-ref.txt | 7 +++
builtin/fo
)%(refname:short)%C(reset)
to display a red asterisk next to the current ref.
Signed-off-by: Ramkumar Ramachandra
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/git-for-each-ref.txt | 4
builtin/for-each-ref.c | 13 +++--
2 files changed, 15 insertions(+)
,
convert the *_quote_print functions and callers to *_quote_buf.
[rr: commit message, minor modifications]
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Ramkumar Ramachandra
---
builtin/for-each-ref.c | 13 +
quote.c| 44
calls show_ref() in
a loop to avoid cluttering up cmd_for_each_ref() with the task of
initializing/freeing the strbuf.
[rr: commit message]
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Ramkumar Ramachandra
---
builtin/for-each-ref.c | 55 --
1
) for the purpose of printing argv for $GIT_TRACE. Today, we
achieve this using trace_argv_printf() -> sq_quote_argv() ->
sq_quote_buf(), which ultimately fills in a strbuf.
Signed-off-by: Ramkumar Ramachandra
Signed-off-by: Nguyễn Thái Ngọc Duy
---
quote.c | 17 -
quote.h
ormat code, they are advised to migrate to --pretty.
[rr: documentation]
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Ramkumar Ramachandra
---
Documentation/git-for-each-ref.txt | 23 ++-
builtin/for-each-ref.c | 72 +-
t/t6300-for-each-ref
the substitution). The callback should return
the length of the original string parsed, and optionally set
placeholder_subst.
[rr: commit message, minor modifications]
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Ramkumar Ramachandra
---
commit.h | 8
pretty.c |
help of format().
Signed-off-by: Ramkumar Ramachandra
Signed-off-by: Nguyễn Thái Ngọc Duy
---
pretty.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/pretty.c b/pretty.c
index 095e5ba..0063f2d 100644
--- a/pretty.c
+++ b/pretty.c
@@ -1061,7 +1061,8 @@ stati
Currently, there is exactly one caller of sq_quote_print(), namely
cmd_tar_tree(). In the interest of removing sq_quote_print() and
simplification, replace it with an equivalent call to sq_quote_argv().
No functional changes intended.
Signed-off-by: Ramkumar Ramachandra
Signed-off-by: Nguyễn
) and %<(*)
for-each-ref: improve responsiveness of %(upstream:track)
Ramkumar Ramachandra (7):
tar-tree: remove dependency on sq_quote_print()
quote: remove sq_quote_print()
pretty: limit recursion in format_commit_one()
for-each-ref: introduce %(HEAD) marker
for-each-ref: introduce %(up
y
are not handled.
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Ramkumar Ramachandra
---
pretty.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/pretty.c b/pretty.c
index 0063f2d..816aa32 100644
--- a/pretty.c
+++ b/pretty.c
@@ -1156,6 +1156,9 @@ s
Duy Nguyen wrote:
> - We might overlook something. The best way to avoid missing is
> finish and verify it.
> - A promise to do things later could happen really late, or never
> happens. As you are sastisfied with the functionality you have less
> motivation to clean the code. Meanwhile the maint
Junio C Hamano wrote:
> +1; I find red on many terminal emulators to be too dark to tell,
> especially in a small font, from black myself.
It's a matter of taste anyway. I hope everyone's not going colorblind
from writing too much C89 and Bourne shell ;)
Eduardo R. D'Avila wrote:
> I think color
Duy Nguyen wrote:
> The short/long naming is the least I worry about. We could add long
> names to pretty specifiers. The thing about the last attempt is, you
> add some extra things on top elsewhere, but format_commit_item code
> may need to be aware of those changes, which are not obvious when
>
Junio C Hamano wrote:
>> would get name-rev to print output in the same format as describe,
>>
>> $ git describe --contains --all v1.8.3~1
>> tags/v1.8.3~1
>>
>> would not strip the leading "tags/".
>
> If you _know_ v1.8.3 does not appear outside "tags/", this does look
> inconsistent, but I d
Junio C Hamano wrote:
> With this on top of the other patches in this series, you would get:
>
> $ git describe --contains $(git rev-parse v1.8.3 v1.8.3^0)
> v1.8.3
> v1.8.3
>
> while you can still differentiate tags and the commits they point at
> with:
>
> $ git name-rev --refs=ta
Junio C Hamano wrote:
> But I do not think "name-rev" is limited
> to commits, in the sense that you would see this:
>
> $ git rev-parse v1.8.3 v1.8.3^0 | git name-rev --stdin
> 8af06057d0c31a24e8737ae846ac2e116e8bafb9
> edca4152560522a431a51fc0a06147fc680b5b18 (tags/v1.8.3^0)
>
> The s
Junio C Hamano wrote:
> "git name-rev" is supposed to convert 40-hex object names into
> strings that name the same objects based on refs, that can be fed to
> "git rev-parse" to get the same object names back, so
>
> $ git rev-parse v1.8.3 v1.8.3^0 | git name-rev --stdin
> 8af06057d0c31a24
Duy Nguyen wrote:
> Ram, are you still interested in the awesome branch series?
Yep, but it got stalled due to lack of reviewer-interest :/
I'm a bit under the weather at the moment, but it's good to see that
you're back: let's finish this soon.
>>> Perhaps we need
>>>
>>> git cat-file --batch
When GIT_PS1_SHOWCOLORHINTS is turned on, there is no need to put a
detached HEAD within parenthesis: the color can be used to discriminate
the detached HEAD.
Signed-off-by: Ramkumar Ramachandra
---
For cuteness :)
contrib/completion/git-prompt.sh | 5 -
t/t9903-bash-prompt.sh
re pleasant and consistent. Obviously, hacking around
this problem in the prompt script is the Wrong thing to do.
Thanks.
Ramkumar Ramachandra (3):
name-rev: fix assumption about --name-only usage
name-rev: strip trailing ^0 in when --name-only
name-rev doc: rewrite --stdin paragraph
Do
not suffer from this defect). Fix this.
Signed-off-by: Ramkumar Ramachandra
---
builtin/name-rev.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/builtin/name-rev.c b/builtin/name-rev.c
index 37207a9..8ba5d72 100644
--- a/builtin/name-rev.c
+++ b/builtin/name-rev.c
scribe --contains @~1
v1.8.3~1
$ git describe --contains --all @~1
foom~1
In other words, --contains implies --tags in name-rev, which gives
precedence to tags; --all cancels that effect thereby giving precedence
to branches in the case of a tie.
Signed-off-by: Ramkumar Ramachandra
---
D
Signed-off-by: Ramkumar Ramachandra
---
Documentation/git-name-rev.txt | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-name-rev.txt b/Documentation/git-name-rev.txt
index 7cde4b3..94bded8 100644
--- a/Documentation/git-name-rev.txt
+++ b/Documentation
brian m. carlson wrote:
> You've covered the STARTTLS case, but not the SSL one right above it.
> Someone using smtps on port 465 will still see the warning. You can
> pass SSL_verify_mode to Net::SMTP::SSL->new just like you pass it to
> start_SSL.
Thanks. On a related note, how do I find out a
Eric Sunshine wrote:
>> + $smtp_ssl_cert_path |=
>> "/etc/ssl/certs";
>
> You're going to want to use logical ||= here. Bitwise |= on a string
> does not do what you expect[1]:
>
> my $s = '/usr/local/etc/ssl/certs';
> $s |= '/etc/ssl/certs';
> print $s,
Hi,
Since nobody stepped up to write it, I wrote [2/2] myself. It will be
tested when I send out this series.
Thanks.
Ramkumar Ramachandra (2):
send-email: squelch warning from Net::SMTP::SSL
send-email: introduce sendemail.smtpsslcertpath
Documentation/config.txt | 3
ation.
***
Fix this by explicitly specifying SSL_verify_mode => SSL_VERIFY_NONE in
Net::SMTP::SSL->start_SSL().
Helped-by: brian m. carlson
Signed-off-by: Ramkumar Ramachandra
---
git-send-email.perl | 4 +++-
1 file changed, 3 insertions(+),
Use the ca-certificates in /etc/ssl/certs by default (that's where most
distributions put it). SSL_VERIFY_NONE is now the fallback mode.
Signed-off-by: Ramkumar Ramachandra
---
Documentation/config.txt | 3 +++
Documentation/git-send-email.txt | 4
git-send-email
John Keeping wrote:
> I don't think this is really "fix", it's more plastering over the
> problem.
It defaulted to SSL_VERIFY_NONE before Net::SMTP::SSL was updated, and
the behavior hasn't changed now. The new version simply asks us to be
explicit about SSL_VERIFY_NONE, so we are aware about it.
ation.
***
Fix this by explicitly specifying SSL_verify_mode => SSL_VERIFY_NONE in
Net::SMTP::SSL->start_SSL().
Helped-by: brian m. carlson
Signed-off-by: Ramkumar Ramachandra
---
git-send-email.perl | 4 +++-
1 file changed, 3 insertions(+),
brian m. carlson wrote:
> diff --git a/git-send-email.perl b/git-send-email.perl
> index bd13cc8..ca86a13 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -1199,9 +1199,11 @@ X-Mailer: git-send-email $gitversion
> else {
> require Net::SMTP
Ramkumar Ramachandra wrote:
>>> New-style class. I wonder why you suddenly switched.
>>
>> ? All of the classes are new-style classes.
>
> When you say class Foo:, aren't you declaring an old-style class by
> default in python2? New-style classes are those th
Junio C Hamano wrote:
> For --short and --symbolic-full-name, I have a feeling that we
> should make "describe" a front-end for these.
> [...]
All very good. If and when someone does write that functionality (I
personally find the task boring), we can remove this completer. Until
such a time, th
Junio C Hamano wrote:
> It is not "nobody is working on", but "it has already been used to
> help the transision and served its purpose, and is no longer is very
> useful for follow-up work because the majority of remaining matches
> it finds are false positives."
Please amend the commit message a
Michael Haggerty wrote:
> On 07/02/2013 09:23 PM, Ramkumar Ramachandra wrote:
>> git_multimail.py wrote:
>>> #! /usr/bin/env python2
>>
>> Do all distributions ship it as python2 now?
>
> No, but nor is "python" always Python version 2.x (I beli
John Keeping wrote:
> I have to say that I don't think this is a particularly useful review,
> you seem to have skipped huge portions of the code and spent a lot of
> time making us read your thought process rather than providing
> constructive feedback. What feedback there is mostly seems to be
>
Hi,
I figured that we should quickly read through git-multimail and give
it an on-list review. Hopefully, it'll educate the list about what
this is, and help improve the script itself.
Sources: https://github.com/mhagger/git-multimail
git_multimail.py wrote:
> #! /usr/bin/env python2
Do all di
Sedat Dilek wrote:
> Sometimes I need to bisect a previous Linux-Next version.
>
> What I am doing is to have the latest Linux-v3.x.y(-rcX) as stable base.
>
> $ git checkout upstream
> $ git checkout -b Linux-v3.10-rc7 v3.10-rc7
>
> Afterwards I checkout the latest Linux-Next remote repository wit
Alois Mahdal wrote:
> This [has been reported][1] to this list about half a year ago
> but with no response so I'm not even sure if it's been
> acknowledged as bug.
Yes, this is a bug. However, it is not at all easy to fix; so I would
recommend that you contribute a documentation patch/ failing
Sedat Dilek wrote:
> for my Linux-kernel build-script I am searching for a reliable check
> of getting the ***latest*** version.
$ git describe HEAD
If you want a sorted list of tags,
$ git for-each-ref --sort=taggerdate --format="%(refname:short)" refs/tags
Are you looking for something el
Signed-off-by: Ramkumar Ramachandra
---
Documentation/git-check-ignore.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/git-check-ignore.txt
b/Documentation/git-check-ignore.txt
index 8e1f7ab..d2df487 100644
--- a/Documentation/git-check-ignore.txt
+++ b
SZEDER Gábor wrote:
> The code is OK, the rest of the function is pretty straightforward,
> but I think this line would warrant a sentence in the log message,
Okay.
Complete untracked pathspecs (--others), and overlay HEAD tree on
index (--with-tree=HEAD) to complete pathspecs that have been re
SZEDER Gábor wrote:
> -test_expect_success 'ls-files --delete' '
> +test_expect_success 'ls-files --deleted' '
> setup_absent &&
> test -z "$(git ls-files -d)"
While at it, change this to --deleted?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a
SZEDER Gábor wrote:
> Either way, why these five options? 'git rev-parse' has a lot more
> options than that.
We have to start somewhere, so I put in the options that I personally use.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.ker
201 - 300 of 1623 matches
Mail list logo
