On Thu, Dec 15, 2016 at 08:14:58PM +, Larry Minton wrote:
> My question:
>
> Let's say I have a code change that I want to 'bake' for a while
> locally, just to make sure some edge case doesn't pop up while I am
> working on other things. Is there any practical way of doing that? I
> could c
On Tue, Sep 20, 2016 at 01:07:00PM +0200, Heiko Voigt wrote:
> On Tue, Sep 20, 2016 at 01:02:28PM +0200, Heiko Voigt wrote:
> > Hi,
> >
> > On Sun, Sep 18, 2016 at 05:50:28PM +0200, Jonas Thiel wrote:
> > > A while ago I have described my problem with Homebrew at the following
> > > GitHub channel
On Tue, Aug 16, 2016 at 06:20:30PM +0200, Ralf Thielow wrote:
> If option --help is passed to a Git command, we try to open
> the man page of that command. However, we do it even for commands
> we don't know. Make sure it is a Git command by using "help_unknown_cmd"
> which is even able to assume
On Mon, Aug 15, 2016 at 09:40:54PM +0100, Philip Oakley wrote:
> From: "Junio C Hamano"
> > "Philip Oakley" writes:
> >
> >> I'm still not sure this is enough. One of the problems back when I
> >> introduced the --guides option (65f9835 (builtin/help.c: add --guide
> >> option, 2013-04-02)) was t
llow this specification, while diff utilities generally use
"1" for the exit status we want to ignore.
Handle any value of 126 or greater as a special value indicating that
some form of fatal error occurred.
[1]
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#ta
On Mon, Aug 15, 2016 at 01:21:22PM -0700, Junio C Hamano wrote:
> "Tom Tanner (BLOOMBERG/ LONDON)" writes:
>
> > From: gits...@pobox.com
> > To: j...@keeping.me.uk
> > Cc: Tom Tanner (BLOOMBERG/ LONDON), dav...@gmail.com, git@vger.kernel.org
> > At: 08/14/
On Mon, Aug 15, 2016 at 08:30:03PM +0700, Duy Nguyen wrote:
> On Mon, Aug 15, 2016 at 7:37 PM, Philip Oakley wrote:
> > I appreciate there has been a lot of discussion, but it mainly appears to be
> > about an upstream / integration viewpoint.
> >
> > I'd hate it if there was a one size fits all s
On Sat, Aug 13, 2016 at 08:42:21PM -0700, David Aguilar wrote:
> This use case makes me wonder whether the sorting we do here is
> something that should be opened up a bit so that the it's not
> quite so set in stone.
>
> For example, an extension to the approach taken by this patch
> would be to
the exit status we want to ignore.
Handle 126 and 127 as special values, assuming that they always mean
that the command could not be executed.
[1]
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_08_02
Signed-off-by: John Keeping
---
On Sat, Aug 13, 2016 at 11:36:
On Fri, Aug 12, 2016 at 07:13:41AM -, Tom Tanner (BLOOMBERG/ LONDON) wrote:
> For instance, if you set your diff/mergetool to meld and you don't have it
> installed:
> > git difftool
>
> Viewing (1/1): 'blah'
> Launch 'meld' [Y/n]? y
> /home/ttanner/bin/meld[8]: /opt/swt/bin/meld: not found
>
On Sun, Aug 07, 2016 at 08:12:23AM +0300, Michael S. Tsirkin wrote:
> On Fri, Aug 05, 2016 at 08:39:58AM -0700, Junio C Hamano wrote:
> > * When you updated an existing topic, you tell a tool like "rebase
> >-i -p" to recreate "lit" branch on top of the mainline. This
> >would give you an
On Thu, Aug 04, 2016 at 10:03:39AM +0200, Lars Schneider wrote:
>
> >
> > * jk/push-force-with-lease-creation (2016-07-26) 3 commits
> > - push: allow pushing new branches with --force-with-lease
> > - push: add shorthand for --force-with-lease branch creation
> > - Documentation/git-push: fix pl
Changes in v3:
- Use hashclr() and oidclr() where appropriate instead of memset()
- Pull a test forward from patch 3 to patch 2
John Keeping (3):
Documentation/git-push: fix placeholder formatting
push: add shorthand for --force-with-lease branch creation
push: allow pushing new branches
Format the placeholder as monospace to match other occurrences in this
file and obey CodingGuidelines.
Signed-off-by: John Keeping
---
No changes in v3.
Documentation/git-push.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/git-push.txt b/Documentation/git
null SHA-1 as the expected value.
In fact, it is already possible to push new branches using the explicit
--force-with-lease=: syntax, so all we do here is make
this behaviour the default if no explicit "expect" value is specified.
Signed-off-by: John Keeping
---
Changes in v3:
-
: origin new-branch
Signed-off-by: John Keeping
---
Changes in v3:
- use hashclr()
- pull 'new branch already exists' test forward from patch 3 and use
explicit --force-with-lease syntax
Documentation/git-push.txt | 3 ++-
remote.c | 2 ++
t/t5533-push-cas.sh
On Tue, Jul 26, 2016 at 12:59:04PM -0700, Junio C Hamano wrote:
> John Keeping writes:
>
> >> > @@ -2294,6 +2294,8 @@ int parse_push_cas_option(struct push_cas_option
> >> > *cas, const char *arg, int unse
> >> > entry = add_cas_entry(cas, arg,
On Tue, Jul 26, 2016 at 12:30:05PM +0200, Jakub Narębski wrote:
> W dniu 2016-07-25 o 23:59, John Keeping pisze:
>
> > +test_expect_success 'new branch covered by force-with-lease (explicit)' '
> > + setup_srcdst_basic &&
> > + (
> > +
On Mon, Jul 25, 2016 at 03:22:48PM -0700, Junio C Hamano wrote:
> John Keeping writes:
>
> > Allow the empty string to stand in for the null SHA-1 when pushing a new
> > branch, like we do when deleting branches.
> >
> > This means that the following comman
Format the placeholder as monospace to match other occurrences in this
file and obey CodingGuidelines.
Signed-off-by: John Keeping
---
New in v2.
Documentation/git-push.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/git-push.txt b/Documentation/git
: origin new-branch
Signed-off-by: John Keeping
---
New in v2.
Documentation/git-push.txt | 3 ++-
remote.c | 2 ++
t/t5533-push-cas.sh| 12
3 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
On Mon, Jul 25, 2016 at 10:28:01AM -0700, Junio C Hamano wrote:
> John Keeping writes:
>
> > If there is no upstream information for a branch, it is likely that it
> > is newly created and can safely be pushed under the normal fast-forward
> > rules. Relax the --force-
null SHA-1 as the expected value.
In fact, it is already possible to push new branches using the explicit
--force-with-lease=: syntax, so all we do here is make
this behaviour the default if no explicit "expect" value is specified.
Signed-off-by: John Keeping
---
Changes in v2:
- The
null SHA-1 as the expected value.
In fact, it is already possible to push new branches using the explicit
--force-with-lease=: syntax, so all we do here is make
this behaviour the default if no explicit "expect" value is specified.
Signed-off-by: John Keeping
---
remote.c
uments should be
interpreted relative to the current directory not the root of the
working tree.
The Git::repository object passed into setup_dir_diff() is configured to
handle this correctly but we create a new Git::repository here without
setting the WorkingSubdir argument. By simply using t
On Wed, Jun 01, 2016 at 12:45:11PM -0700, Junio C Hamano wrote:
> John Keeping writes:
>
> > On Wed, Jun 01, 2016 at 03:07:59PM -0400, Jeff King wrote:
> >> On Wed, Jun 01, 2016 at 07:31:00PM +0100, John Keeping wrote:
> >>
> >> > > > rese
On Wed, Jun 01, 2016 at 03:07:59PM -0400, Jeff King wrote:
> On Wed, Jun 01, 2016 at 07:31:00PM +0100, John Keeping wrote:
>
> > > > reset_submodule_urls () {
> > > > - local root
> > > > - root=$(pwd) &&
&g
&
> > git config remote.origin.url "$root/submodule"
>
> Hmm. Isn't $root always just going to be $TRASH_DIRECTORY here? There's
> only one caller, which appears to pass an argument which is ignored (?).
>
> It's probably worth doing
I've noticed a slightly annoying behaviour of git-push's
--force-with-lease option around branch creation.
I'd like to be able to do:
git push --force-with-lease origin refs/heads/jk/*
to push out a load of topic branches safely in case I've switched client
machines and forgotten to pull
On Thu, Apr 21, 2016 at 01:30:04PM +0200, Olaf Hering wrote:
> To track the changes in hyperv related files I created some scripts
> years ago to automate the process of finding relevant commits in
> linux.git. Part of that process is to record the tag when a commit
> appeared in mainline. This wor
On Tue, Apr 12, 2016 at 03:53:12PM +0200, Nikola Fo wrote:
> On Tue, 2016-04-12 at 14:27 +0100, John Keeping wrote:
> > I think the case in these two is correct as-is. The "Y" is capitalised
> > because it is the default and will take effect if the user just press
On Tue, Apr 12, 2016 at 02:59:42PM +0200, Nikola Fo wrote:
> Every yes/no question in difftool/mergetool scripts has slightly
> different form, and none of them is consistent with the form git
> itself uses.
>
> Make the form of all the questions consistent with the form used
> by git, i.e. "Q
On Tue, Apr 12, 2016 at 08:25:39AM -0300, Rudinei Goi Roecker wrote:
> I'm having a problem with included configurations in ~/.gitconfig, when
> using this command:
>
> git config --global user.email
> It doesn't return anything, in commits it works as intended. The
> configuration looks like
On Tue, Mar 29, 2016 at 11:00:03PM +0100, John Keeping wrote:
> On Tue, Mar 29, 2016 at 05:21:43PM -0400, Jeff King wrote:
> > On Tue, Mar 29, 2016 at 09:52:08PM +0100, John Keeping wrote:
> >
> > > > Yeah, I think this is a bug. Presumably what is happening is that
On Tue, Mar 29, 2016 at 05:21:43PM -0400, Jeff King wrote:
> On Tue, Mar 29, 2016 at 09:52:08PM +0100, John Keeping wrote:
>
> > > Yeah, I think this is a bug. Presumably what is happening is that we are
> > > too eager to "cd $GIT_WORK_TREE" inside git-rev-p
On Tue, Mar 29, 2016 at 04:34:25PM -0400, Jeff King wrote:
> On Tue, Mar 29, 2016 at 06:42:44AM -0500, Elliott Cable wrote:
>
> > So, I find this behaviour a little strange; I can't determine if it's
> > a subtle bug, or intentionally undefined/‘fuzzy’ behaviour:
> >
> > $ cd a-repo/.git/
> >
On Tue, Mar 29, 2016 at 02:04:38PM -0400, Eric Sunshine wrote:
> On Tue, Mar 29, 2016 at 6:54 AM, John Keeping wrote:
> > On Tue, Mar 29, 2016 at 10:11:01AM +, Ray Zhang wrote:
> >> With `add`, detach HEAD in the new working tree. See "DETACHED HEAD"
> >
On Tue, Mar 29, 2016 at 06:53:35AM -0500, Elliott Cable wrote:
> On Tue, Mar 29, 2016 at 6:42 AM, Elliott Cable wrote:
> > So, I find this behaviour a little strange; I can't determine if it's
> > a subtle bug, or intentionally undefined/‘fuzzy’ behaviour ...
>
> Oh lord, it gets worse ...
>
> $
On Tue, Mar 29, 2016 at 10:11:01AM +, Ray Zhang wrote:
> By adding this option which defaults to true, we can use the
> corresponding --no-checkout to make some customizations before
> the checkout, like sparse checkout, etc.
>
> Helped-by: Eric Sunshine
> Helped-by: Junio C Hamano
> Reviewe
On Tue, Mar 29, 2016 at 05:32:31AM -0500, Elliott Cable wrote:
> So, `git help rev-parse` [mentions the following][rev-parse], as of
> 2.8.0:
>
> --git-dir
>Show $GIT_DIR if defined. Otherwise show the path to the .git
>directory. The path shown, when relative, is relative to t
On Thu, Mar 17, 2016 at 12:10:44PM -0700, Junio C Hamano wrote:
> Stefan Beller writes:
>
> > For now I would just go with 3 directories:
> >
> > non-git/ (or util, helpers, or anything that could be ripped out and be
> > useful
> > e.g. strbufs, argv-array run-command, lockfile
> > git/ (ma
't pair up the commit for
> squashing/fixing up with the original commit.
Huh? With the hook below you just run `git commit --fixup=...` as
normal and it appends a "[ci skip]" line to the bottom of the commit
message.
> Am 03.03.2016 14:21 schrieb "John Keeping" :
>
On Thu, Mar 03, 2016 at 01:47:00PM +0100, Martine Lenders wrote:
> I'm not sure if this was already requested somewhere (a quick - but
> admittedly not thorough - search did not reveal anything in that
> direction), but I really miss an option to configure the prefixes generated
> by `git commit (-
ybe procmon[1] will
show them?
[1] https://technet.microsoft.com/en-us/sysinternals/processmonitor.aspx
> -Original Message-
> From: John Keeping [mailto:j...@keeping.me.uk]
> Sent: Monday, February 29, 2016 4:35 AM
> To: Duy Nguyen
> Cc: Fred's Personal; Git Mailing
On Mon, Feb 29, 2016 at 08:20:46AM +0700, Duy Nguyen wrote:
> On Mon, Feb 29, 2016 at 12:48 AM, Fred's Personal
> wrote:
> > Duy,
> >
> > Thanks for advice, here is the result of executing the lines you suggested:
> >
> > user1@Host1 MINGW64 ~/gitrepository (master)
> > $ export GIT_TRACE=1
> >
>
--get does not fail if a key is multi-valued, it returns the last value
as described in its documentation. Clarify the description of --get-all
to avoid implying that --get does fail in this case.
Signed-off-by: John Keeping
---
Documentation/git-config.txt | 3 +--
1 file changed, 1 insertion
-by: John Keeping
---
Documentation/git-config.txt | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt
index 2a04e87..e9c755f 100644
--- a/Documentation/git-config.txt
+++ b/Documentation/git-config.txt
accepts a default value to return and so should not return an
error if the key is not found.
Also clarify this behaviour in the documentation.
Signed-off-by: John Keeping
---
Documentation/git-config.txt | 2 +-
builtin/config.c | 5 -
t/t1300-repo-config.sh | 3 +++
3 files
On Sun, Feb 28, 2016 at 10:45:57AM +, John Keeping wrote:
> It looks to me like a simple bug that --get-urlmatch doesn't return 1 if
> the key isn't found, but git-config(1) isn't entirely clear. The
> overall documentation on exit codes at the end of DESCRIPTION says
On Sun, Feb 28, 2016 at 10:45:57AM +, John Keeping wrote:
> On Sun, Feb 28, 2016 at 10:09:12AM +0530, Guilherme wrote:
> > My current woes are with multi-valued configuration values. More
> > specifically credential.helper
> >
> > The documentation of git config sa
On Sun, Feb 28, 2016 at 10:09:12AM +0530, Guilherme wrote:
> My current woes are with multi-valued configuration values. More
> specifically credential.helper
>
> The documentation of git config says that when a value is not matched
> it should return 1.
>
> To reproduce make sure that credential
On Fri, Feb 26, 2016 at 06:29:57PM -0500, Jeff King wrote:
> This reverts commit 68889b416d5b6a5cf7d280a428281d635fe9b292.
[snip]
> The original patch was not spurred by an actual bug report,
> but by an observation[1] that was essentially "eh, this
> looks unnecessarily restrictive". It _is_ restr
On Tue, Feb 23, 2016 at 03:01:43PM -0800, Junio C Hamano wrote:
> John Keeping writes:
>
> > My original sed version was:
> >
> > sed -ne "/^author /p" -e "/^summary /p"
> >
> > which I think will work on all platforms (we already us
On Wed, Feb 24, 2016 at 03:26:57AM -0500, Jeff King wrote:
> On Wed, Feb 24, 2016 at 08:47:00AM +0100, Johannes Schindelin wrote:
>
> > I cannot think of a way how to test this: all of the regression
> > tests run inside Git's own worktree, and we cannot even assume
> > that /tmp/ is o
On Tue, Feb 23, 2016 at 03:32:02AM +0100, Jason A. Donenfeld wrote:
> In case anyone else finds this useful, I wrote this:
>
> https://git.zx2c4.com/git-daemon-dummy/about/
>
> It's an epoll-based responder for git:// that simply returns an error
> telling users of a new URI. The purpose is to ph
On Sun, Feb 21, 2016 at 04:15:31PM -0500, Eric Sunshine wrote:
> On Sun, Feb 21, 2016 at 12:32 PM, John Keeping wrote:
> > GNU grep 2.23 detects the input used in this test as binary data so it
> > does not work for extracting lines from a file. We could add the "-a"
&g
On Sun, Feb 21, 2016 at 06:19:14PM -0500, Jeff King wrote:
> On Sun, Feb 21, 2016 at 04:01:27PM -0500, Eric Sunshine wrote:
>
> > On Sun, Feb 21, 2016 at 12:32 PM, John Keeping wrote:
> > > GNU grep 2.23 detects the input used in this test as binary data so it
> > >
ce it will always treat its input as text.
While touching these lines, modernize the test style to avoid hiding the
exit status of "git blame" and remove a space following a redirection
operator.
Signed-off-by: John Keeping
---
t/t8005-blame-i18n.sh | 16
1 file changed
ce it will always treat its input as text.
Signed-off-by: John Keeping
---
t/t9200-git-cvsexportcommit.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t9200-git-cvsexportcommit.sh b/t/t9200-git-cvsexportcommit.sh
index 812c9cd..0765d52 100755
--- a/t/t9200-git-cvsexportcommit.
On Fri, Feb 19, 2016 at 02:33:10PM -0500, Jeff King wrote:
> On Fri, Feb 19, 2016 at 07:23:11PM +0000, John Keeping wrote:
>
> > I suspect that any grep that lacks "-a" also lacks binary file handling
> > that will break these tests. I found a Solaris grep that doe
On Fri, Feb 19, 2016 at 09:38:17AM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > Yeah, I'd worry that "-a" is not portable. OTOH, BSD grep seems to have
> > it, so between that and GNU, I think most systems are covered. We could
> > do:
> >
> > test_lazy_prereq GREP_A '
> > echo fo
On Mon, Feb 08, 2016 at 10:28:58AM -0500, Jeff King wrote:
> On Mon, Feb 08, 2016 at 02:33:17PM +0000, John Keeping wrote:
>
> > I have just noticed that with DATE_STRFTIME, the timezone in the output
> > is likely to be incorrect.
> >
> > For all other tim
I have just noticed that with DATE_STRFTIME, the timezone in the output
is likely to be incorrect.
For all other time formats, we print the string ourselves and use the
correct timezone from the input, but with DATE_STRFTIME strftime(3) will
always use the system timezone.
--
To unsubscribe from t
It seems that binary file detection has changed in GNU grep 2.23 as a
result of commit 40ed879 (grep: fix bug with with invalid unibyte
sequence).
This causes a couple of test failures in t8005 and t9200 (the t9200 case
is less obvious so I'm only including t8005 here):
-- >8 --
$ ./t8005-blame-i
On Fri, Feb 05, 2016 at 01:29:26PM -0900, Britton Kerin wrote:
> On Fri, Feb 5, 2016 at 12:25 PM, Philip Oakley wrote:
> > From: "Britton Kerin"
> >>
> >> Someone suggested using color.branch.upstream, I tried like this and
> >> variants
> >>
> >> [color "branch"]
> >> local = red bold
> >> ups
On Thu, Feb 04, 2016 at 04:27:49PM +0100, Johannes Schindelin wrote:
> On Thu, 4 Feb 2016, John Keeping wrote:
>
> > On Thu, Feb 04, 2016 at 02:13:47PM +0100, Johannes Schindelin wrote:
> > > Whatever the outcome, the inconsistency must be fixed.
> >
> > I
On Thu, Feb 04, 2016 at 02:13:47PM +0100, Johannes Schindelin wrote:
> On Thu, 4 Feb 2016, John Keeping wrote:
>
> > Although I don't think the historic context is useful in deciding which
> > direction to go in the future.
>
> Being a maintainer, I find that argumen
On Thu, Feb 04, 2016 at 01:38:51PM +0100, Johannes Schindelin wrote:
> On Thu, 4 Feb 2016, John Keeping wrote:
>
> > Using spaces around operators also matches our C coding style.
>
> Well, by that reasoning you should go the whole nine yards and write
>
>
On Thu, Feb 04, 2016 at 01:01:39PM +0100, Johannes Schindelin wrote:
> I noticed through a nearby patch series that was submitted by Elia that
> some of the $((...)) expressions introduced in scripts that I introduced
> to Git's source code did not match the existing code's convention:
> previously
On Sun, Jan 31, 2016 at 02:37:59PM +0100, SZEDER Gábor wrote:
>
> Quoting John Keeping :
>
> > According to command-list.txt, verify-tag is an ancillary interrogator,
> > which means that it should be completed by "git verify-" in the
> > same way as veri
According to command-list.txt, verify-tag is an ancillary interrogator,
which means that it should be completed by "git verify-" in the
same way as verify-commit.
Remove it from the list of plumbing commands so that it is treated as
porcelain and completed.
Signed-off-by: Jo
This adds the --no-* variants where those are documented in
git-rebase(1).
Signed-off-by: John Keeping
---
contrib/completion/git-completion.bash | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git
On Fri, Dec 18, 2015 at 06:05:49PM +, John Keeping wrote:
> On Fri, Dec 18, 2015 at 11:43:16AM -0600, David A. Greene wrote:
> > John Keeping writes:
> >
> > > It seems that the problem is introduces by --preserve-merges (and
> > > -Xsubtree causes someth
On Fri, Dec 18, 2015 at 11:43:16AM -0600, David A. Greene wrote:
> John Keeping writes:
>
> > It seems that the problem is introduces by --preserve-merges (and
> > -Xsubtree causes something interesting to happen as well). I see the
> > following behaviour:
>
>
On Tue, Dec 15, 2015 at 09:17:30PM -0600, David A. Greene wrote:
> According to the rebase man page, rebase gathers commits as in "git log
> ..HEAD." However, that is not what happens in the tests
> below. Some of the commits disappear.
>
> The test basically does this:
>
> - Setup a master pro
On Thu, Dec 10, 2015 at 02:46:40PM -0800, Junio C Hamano wrote:
> * jk/send-email-ssl-errors (2015-11-24) 1 commit
> - send-email: enable SSL level 1 debug output
>
> Improve error reporting when SMTP TLS fails.
>
> Waiting for a reroll.
> ($gmane/281693)
It looks like this got lost in the n
On Fri, Dec 04, 2015 at 06:09:33PM +0100, demerphq wrote:
> On 4 December 2015 at 16:05, Andreas Krey wrote:
> > Hi all,
> >
> > our workflow is pretty rebase-free for diverse reasons yet.
> >
> > One obstacle now appearing is that rebases simply take
> > very long - once you might want to do a re
On Fri, Dec 04, 2015 at 04:05:46PM +0100, Andreas Krey wrote:
> our workflow is pretty rebase-free for diverse reasons yet.
>
> One obstacle now appearing is that rebases simply take
> very long - once you might want to do a rebase there are
> several hundred commits on the remote branch, and our
ee silence at level 0 and
only emit error messages at level 1, so let's enable it by default.
The modification of warnings is needed to avoid a warning about:
Name "IO::Socket::SSL::DEBUG" used only once: possible typo
Signed-off-by: John Keeping
---
Sorry about th
On Tue, Nov 24, 2015 at 06:35:36PM -0500, Jeff King wrote:
> On Tue, Nov 24, 2015 at 11:31:40PM +0000, John Keeping wrote:
>
> > If the CA path isn't found it's most likely to indicate a
> > misconfiguration, in which case accepting any certificate is unlikely to
&g
On Tue, Nov 24, 2015 at 08:07:23PM -0500, Jeff King wrote:
> * jk/send-email-ssl-errors (2015-11-24) 1 commit
> - send-email: enable SSL level 1 debug output
>
> Improve error reporting when SMTP TLS fails.
>
> Will merge to 'next'.
Can you hold off on this one? I think my last-minute change
ee silence at level 0 and
only emit error messages at level 1, so let's enable it by default.
Signed-off-by: John Keeping
---
This is the result of a previous discussion [0] but I decided to drop
the switch on --smtp-debug since level 1 only gives output on errors.
[0] http://marc.info/?l=g
If the CA path isn't found it's most likely to indicate a
misconfiguration, in which case accepting any certificate is unlikely to
be the correct thing to do.
Signed-off-by: John Keeping
---
Changes since v1:
- add missing path to error message
- remove trailing '.' on err
On Tue, Nov 24, 2015 at 05:28:21PM -0500, Jeff King wrote:
> On Tue, Nov 24, 2015 at 10:17:08PM +0000, John Keeping wrote:
>
> > I wonder if we should do this to help debug SSL issues:
> >
> > -- >8 --
> > diff --git a/git-send-email.perl b/git-send-email.perl
On Tue, Nov 24, 2015 at 05:23:30PM -0500, Jeff King wrote:
> On Tue, Nov 24, 2015 at 08:43:53AM +0000, John Keeping wrote:
>
> > On Mon, Nov 23, 2015 at 07:04:46PM -0500, Eric Sunshine wrote:
> > > On Tue, Nov 17, 2015 at 5:01 PM, John Keeping wrote:
> > > > Thes
On Tue, Nov 24, 2015 at 02:58:43PM -0500, Jeff King wrote:
> On Fri, Nov 20, 2015 at 07:46:51PM +0000, John Keeping wrote:
>
> > > For people who know their systems are broken and want to proceed anyway,
> > > what is the appropriate work-around? Obviously it invol
On Mon, Nov 23, 2015 at 07:04:46PM -0500, Eric Sunshine wrote:
> On Tue, Nov 17, 2015 at 5:01 PM, John Keeping wrote:
> > These configuration variables specify the paths to commands so we should
> > support tilde-expansion for files inside a user's home directory.
>
>
On Fri, Nov 20, 2015 at 06:18:48AM -0500, Jeff King wrote:
> On Tue, Nov 17, 2015 at 10:12:07PM +0000, John Keeping wrote:
>
> > If the CA path isn't found it's most likely to indicate a
> > misconfiguration, in which case accepting any certificate is unlikely to
&g
If the CA path isn't found it's most likely to indicate a
misconfiguration, in which case accepting any certificate is unlikely to
be the correct thing to do.
Signed-off-by: John Keeping
---
git-send-email.perl | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git
As it says in the name, the SSL certificate path is a path so treat it
as one and support tilde-expansion.
Signed-off-by: John Keeping
---
git-send-email.perl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index e907e0e..719c715
These configuration variables specify the paths to commands so we should
support tilde-expansion for files inside a user's home directory.
Signed-off-by: John Keeping
---
git-send-email.perl | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-send-email.perl b/git
These two patches enable tilde-expansion for a few more config variables
in git-send-email.
The first case is the one that surprised me when it didn't work, the
second two are the other ones that look like they should be handled as
paths.
John Keeping (2):
send-email: expand pa
On Mon, Nov 02, 2015 at 06:27:52AM +, Stenberg Jim (2) wrote:
> My problem:
> "Git merge-base --fork-point" acts unexpected when I refer to remote
> branches (typically "origin/".) With unexpected I mean that if I swap
> the position of the two references that the function takes as argument
> I
On Tue, Oct 27, 2015 at 06:54:16AM -0700, Victor Leschuk wrote:
> Hello John,
>
> >> This thought also crossed my mind, however we already pass grep_opt to
> >> start_threads() function, so I think passing it to wait_all() is not
> >> that ugly, and kind of symmetric. And I do not like the idea of
On Mon, Oct 26, 2015 at 10:25:41PM -0700, Victor Leschuk wrote:
> >> @@ -22,6 +22,7 @@ SYNOPSIS
> >> [--color[=] | --no-color]
> >> [--break] [--heading] [-p | --show-function]
> >> [-A ] [-B ] [-C ]
> >> +[--threads ]
>
> > Is this the best place for this option
On Mon, Oct 26, 2015 at 03:32:13PM +0300, Victor Leschuk wrote:
> Make number of git-grep worker threads a configuration parameter.
> According to several tests on systems with different number of CPU cores
> the hard-coded number of 8 threads is not optimal for all systems:
> tuning this parameter
On Thu, Oct 22, 2015 at 04:23:56PM +0300, Victor Leschuk wrote:
> Hello all, I suggest we make number of git-grep worker threads a configuration
> parameter. I have run several tests on systems with different number of CPU
> cores.
> It appeared that the hard-coded number 8 lowers performance on b
On Wed, Oct 14, 2015 at 09:37:05AM +0200, Matthieu Moy wrote:
> Xue Fuqiao writes:
>
> > Hi list,
> >
> > In https://git-scm.com/docs/user-manual.html , all links to the
> > glossary[1] are broken.
>
> Actually, the links themselves are fine, but the destimation is broken.
>
> The doc is suppos
On Tue, Oct 06, 2015 at 03:13:05PM +0200, Johannes Schindelin wrote:
> Hi Michael,
>
> On 2015-10-06 10:12, Michael J Gruber wrote:
> > "make -j3" just errored out on me, a follow-up "make" succeeded". This
> > looks like an interdependency issue, but I don't know how to track it:
> >
> > GEN
On Mon, Oct 05, 2015 at 10:13:00PM +0200, Jens Brejner wrote:
> I need to merge a branch, +100k changes. The vast majority of changes
> are insignificant, because they only represent a screen position in
> the editor, so these changes should never have been in git - but but
> MadCap Flare already p
1 - 100 of 893 matches
Mail list logo
