Re: Is there a way to have local changes in a branch 'bake' while working in different branches?

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

Re: Re: Homebrew and Git

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

Re: [PATCH v3] help: make option --help open man pages only for Git commands

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

Re: [PATCH v2] help: make option --help open man pages only for Git commands

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:

[PATCH v2] difftool: always honor fatal error exit codes

fication, 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#tag_18_08_0

Re: [PATCH] difftool: always honor "command not found" exit code

ger.kernel.org > > At: 08/14/16 04:21:18 > > > > John Keeping <j...@keeping.me.uk> writes: > > ... > >> POSIX specifies 127 as the exit status for "command not found" and 126 > >> for "command found but is not executable" [1] and at

Re: storing cover letter of a patch series?

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

Re: git-mergetool reverse file ordering

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

[PATCH] difftool: always honor "command not found" exit code

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 <j...@keeping.me.uk> --- On Sat, Aug 13,

Re: git difftool and git mergetool aren't returning errors when the tool has issues

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

Re: storing cover letter of a patch series?

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

Re: What's cooking in git.git (Aug 2016, #01; Tue, 2)

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

[PATCH v3 0/3] push: allow pushing new branches with --force-with-lease

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

[PATCH v3 1/3] Documentation/git-push: fix placeholder formatting

Format the placeholder as monospace to match other occurrences in this file and obey CodingGuidelines. Signed-off-by: John Keeping <j...@keeping.me.uk> --- No changes in v3. Documentation/git-push.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/git-pu

[PATCH v3 3/3] push: allow pushing new branches with --force-with-lease

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 <j...@keeping.me.uk> -

[PATCH v3 2/3] push: add shorthand for --force-with-lease branch creation

: origin new-branch Signed-off-by: John Keeping <j...@keeping.me.uk> --- 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-

Re: [PATCH v2 2/3] push: add shorthand for --force-with-lease branch creation

On Tue, Jul 26, 2016 at 12:59:04PM -0700, Junio C Hamano wrote: > John Keeping <j...@keeping.me.uk> writes: > > >> > @@ -2294,6 +2294,8 @@ int parse_push_cas_option(struct push_cas_option > >> > *cas, const char *arg, int unse > >> >

Re: [PATCH v2 2/3] push: add shorthand for --force-with-lease branch creation

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 && > > + ( > > + cd ds

Re: [PATCH v2 2/3] push: add shorthand for --force-with-lease branch creation

On Mon, Jul 25, 2016 at 03:22:48PM -0700, Junio C Hamano wrote: > John Keeping <j...@keeping.me.uk> 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

[PATCH v2 0/3] push: allow pushing new branches with --force-with-lease

On Mon, Jul 25, 2016 at 10:28:01AM -0700, Junio C Hamano wrote: > John Keeping <j...@keeping.me.uk> 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 >

[PATCH v2 1/3] Documentation/git-push: fix placeholder formatting

Format the placeholder as monospace to match other occurrences in this file and obey CodingGuidelines. Signed-off-by: John Keeping <j...@keeping.me.uk> --- New in v2. Documentation/git-push.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/git-push

[PATCH v2 2/3] push: add shorthand for --force-with-lease branch creation

: origin new-branch Signed-off-by: John Keeping <j...@keeping.me.uk> --- 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

[PATCH v2 3/3] push: allow pushing new branches with --force-with-lease

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 <j...@keeping.me.uk> -

[PATCH] push: allow pushing new branches with --force-with-lease

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 <j...@keeping.me.uk&g

[PATCH] difftool: fix argument handling in subdirs

erpreted 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 the existing r

Re: [BUG] git-submodule has bash-ism?

On Wed, Jun 01, 2016 at 12:45:11PM -0700, Junio C Hamano wrote: > John Keeping <j...@keeping.me.uk> 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: > >&g

Re: [BUG] git-submodule has bash-ism?

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

Re: [BUG] git-submodule has bash-ism?

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 the minimal thing now and leav

Force-with-lease and new branches

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

Re: history damage in linux.git

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

Re: [PATCH] difftool/mergetool: make the form of yes/no questions consistent

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

Re: [PATCH] difftool/mergetool: make the form of yes/no questions consistent

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.

Re: Git config not working correctly with included configurations

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

Re: `git rev-parse --is-inside-work-tree` and $GIT_WORK_TREE

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 th

Re: `git rev-parse --is-inside-work-tree` and $GIT_WORK_TREE

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

Re: `git rev-parse --is-inside-work-tree` and $GIT_WORK_TREE

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/ >

Re: [PATCH v5] worktree: add: introduce --checkout option

On Tue, Mar 29, 2016 at 02:04:38PM -0400, Eric Sunshine wrote: > On Tue, Mar 29, 2016 at 6:54 AM, John Keeping <j...@keeping.me.uk> wrote: > > On Tue, Mar 29, 2016 at 10:11:01AM +, Ray Zhang wrote: > >> With `add`, detach HEAD in the new working

Re: `git rev-parse --is-inside-work-tree` and $GIT_WORK_TREE

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

Re: [PATCH v5] worktree: add: introduce --checkout option

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:

Re: `git rev-parse --git-dir` relative to current working directory?

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

Re: [RFC] Code reorgnization

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,

Re: Feature request: Configurable prefixes for git commit --fixup and --squash

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" <j...@keepin

Re: Feature request: Configurable prefixes for git commit --fixup and --squash

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

Re: Trouble Cloning Git remote repository

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 List > Subje

Re: Trouble Cloning Git remote repository

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) > >

[PATCH 3/3] Documentation/git-config: fix --get-all description

--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 <j...@keeping.me.uk> --- Documentation/git-config.txt | 3 +--

[PATCH 2/3] Documentation/git-config: use bulleted list for exit codes

-by: John Keeping <j...@keeping.me.uk> --- 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/Documen

[PATCH 0/3] Re: git config --get-urlmatch does not set exit code 1 when no match is found

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 that > exit

[PATCH 1/3] config: fail if --get-urlmatch finds no value

it 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 <j...@keeping.me.uk> --- Documentation/git-config.txt | 2 +- builtin/config.c | 5 - t/t1300-repo-con

Re: git config --get-urlmatch does not set exit code 1 when no match is found

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 co

Re: git config --get-urlmatch does not set exit code 1 when no match is found

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

Re: [PATCH 2/2] Revert "rev-parse: remove restrictions on some options"

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_

Re: [PATCH 1/2] t8005: avoid grep on non-ASCII data

On Tue, Feb 23, 2016 at 03:01:43PM -0800, Junio C Hamano wrote: > John Keeping <j...@keeping.me.uk> writes: > > > My original sed version was: > > > > sed -ne "/^author /p" -e "/^summary /p" > > > > which I think will work on all

Re: [PATCH] git config: do not create .git/ if it does not exist yet

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

Re: Git Daemon Dummy: 301 Redirects for git:// to https://

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

Re: [PATCH 2/2] t9200: avoid grep on non-ASCII data

On Sun, Feb 21, 2016 at 04:15:31PM -0500, Eric Sunshine wrote: > On Sun, Feb 21, 2016 at 12:32 PM, John Keeping <j...@keeping.me.uk> wrote: > > GNU grep 2.23 detects the input used in this test as binary data so it > > does not work for extracting lines from

Re: [PATCH 1/2] t8005: avoid grep on non-ASCII data

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 <j...@keeping.me.uk> wrote: > > > GNU grep 2.23 detects the input used in this test as b

[PATCH 1/2] t8005: avoid grep on non-ASCII data

ines since 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 <j...@keeping.me.uk> --- t/t8005-blame-i18n.sh | 16 -

[PATCH 2/2] t9200: avoid grep on non-ASCII data

ines since it will always treat its input as text. Signed-off-by: John Keeping <j...@keeping.me.uk> --- 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 -

[PATCH 0/2] Fix test failures with GNU grep 2.23

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 g

Re: Test failures with GNU grep 2.23

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 '

Re: Timezone with DATE_STRFTIME

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

Timezone with DATE_STRFTIME

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

Test failures with GNU grep 2.23

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 -- $

Re: no luck with colors for branch names in gitk yet

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 > >> > >>

Re: [PATCH 0/3] Fix $((...)) coding style

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: >

Re: [PATCH 0/3] Fix $((...)) coding style

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 argument par

Re: [PATCH 0/3] Fix $((...)) coding style

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 > >

Re: [PATCH 0/3] Fix $((...)) coding style

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

Re: [PATCH] completion: verify-tag is not plumbing

On Sun, Jan 31, 2016 at 02:37:59PM +0100, SZEDER Gábor wrote: > > Quoting John Keeping <j...@keeping.me.uk>: > > > According to command-list.txt, verify-tag is an ancillary interrogator, > > which means that it should be completed by "git verify-"

[PATCH] completion: verify-tag is not plumbing

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: John

[PATCH] completion: add missing git-rebase options

This adds the --no-* variants where those are documented in git-rebase(1). Signed-off-by: John Keeping <j...@keeping.me.uk> --- contrib/completion/git-completion.bash | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/contrib/completion/git-completion.bash b/c

Re: Odd rebase behavior

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 <j...@keeping.me.uk> writes: > > > > > It seems that the problem is introduces by --preserve-merges (and > > >

Re: Odd rebase behavior

On Fri, Dec 18, 2015 at 11:43:16AM -0600, David A. Greene wrote: > John Keeping <j...@keeping.me.uk> writes: > > > It seems that the problem is introduces by --preserve-merges (and > > -Xsubtree causes something interesting to happen as well). I see the > > fo

Re: Odd rebase behavior

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

Re: What's cooking in git.git (Dec 2015, #03; Thu, 10)

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

Re: best practices against long git rebase times?

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

Re: best practices against long git rebase times?

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

[PATCH v2] send-email: enable SSL level 1 debug output

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 <j...@keeping.me.uk> --- Sorry ab

Re: What's cooking in git.git (Nov 2015, #04; Tue, 24)

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

Re: [PATCH v2] send-email: die if CA path doesn't exist

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 > > be

Re: [RFC/PATCH] send-email: die if CA path doesn't exist

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

Re: [RFC/PATCH] send-email: die if CA path doesn't exist

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

[PATCH v2] send-email: die if CA path doesn't exist

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 <j...@keeping.me.uk> --- Changes since v1: - add missing path to error message - remove trailing '.' on

Re: [PATCH 2/2] send-email: expand paths in sendemail.{to,cc}cmd config

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 <j

[PATCH] send-email: enable SSL level 1 debug output

at level 0 and only emit error messages at level 1, so let's enable it by default. Signed-off-by: John Keeping <j...@keeping.me.uk> --- 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://

Re: [PATCH 2/2] send-email: expand paths in sendemail.{to,cc}cmd config

On Mon, Nov 23, 2015 at 07:04:46PM -0500, Eric Sunshine wrote: > On Tue, Nov 17, 2015 at 5:01 PM, John Keeping <j...@keeping.me.uk> wrote: > > These configuration variables specify the paths to commands so we should > > support tilde-expansion for files inside a user's home d

Re: [RFC/PATCH] send-email: die if CA path doesn't exist

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 > > be

[PATCH 2/2] send-email: expand paths in sendemail.{to,cc}cmd config

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 <j...@keeping.me.uk> --- git-send-email.perl | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/gi

[PATCH 1/2] send-email: expand path in sendemail.smtpsslcertpath config

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 <j...@keeping.me.uk> --- git-send-email.perl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/git-send-email.perl b/git-send-email.perl

[RFC/PATCH] send-email: die if CA path doesn't exist

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 <j...@keeping.me.uk> --- git-send-email.perl | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)

[PATCH 0/2] send-email config path expansion

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 path

Re: Git potential bug with fork-point

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 >

Re: [PATCH v3] Add git-grep threads param

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

Re: [PATCH v3] Add git-grep threads param

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

Re: [PATCH v3] Add git-grep threads param

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

Re: [PATCH] Add git-grep threads-num param

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

Re: [BUG] Broken links in Git Documentation/user-manual.txt

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. >

Re: [BUG?] parallel make interdepencies

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: > > > >

Re: How can I ignore insignificant change during merge ?

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

  1   2   3   4   5   6   7   8   9   >