[PATCH] Make git log work for git CWD outside of work tree

Make git log's `--use-mailmap` argument works if the GIT_DIR & GIT_WORK_TREE env vars are set and git is run from outside of work tree. Without the NEED_WORK_TREE set on the log subcommand, .mailmap is silently not found. Signed-off-by: Danny Sauer --- Notes: I'm not

Re: Tools that do an automatic fetch defeat "git push --force-with-lease"

On Sat, Apr 8, 2017 at 3:13 PM, Jeff King wrote: > On Sat, Apr 08, 2017 at 02:54:29PM -0700, Jacob Keller wrote: > >> > So the best way to use it is something like: >> > >> > git fetch ;# update 'master' from remote >> > git tag base master;# mark our base

Re: Tools that do an automatic fetch defeat "git push --force-with-lease"

On Sat, Apr 08, 2017 at 02:54:29PM -0700, Jacob Keller wrote: > > So the best way to use it is something like: > > > > git fetch ;# update 'master' from remote > > git tag base master;# mark our base point > > git rebase -i master ;# rewrite some commits > > git push

Re: broken text encoding in commit author name

Hi Michał, On 08/04/2017 22:30, Michał Walenciak wrote: > Hi > > since git 2.12 I'm having random problems with broken text enciding in author > name. > > As an example broken commit: > Author: Michał Walenciak 2017-04-07 21:38:23 > Committer: Michał Walenciak

Re: Tools that do an automatic fetch defeat "git push --force-with-lease"

On Sat, Apr 08, 2017 at 05:03:06PM +0200, Stefan Haller wrote: > Jeff King wrote: > > > I think Matt's point is just that the default, to use origin/branch, is > > unsafe. It's convenient when you don't have extra fetches, but that > > convenience may not be worth the potential

Re: Tools that do an automatic fetch defeat "git push --force-with-lease"

On Sat, Apr 8, 2017 at 2:29 AM, Jeff King wrote: > On Sat, Apr 08, 2017 at 09:35:04AM +0200, Ævar Arnfjörð Bjarmason wrote: > >> Is it correct that you'd essentially want something that works like: >> >> git push --force-with-lease=master:master origin master:master > > I don't

Re: [PATCH] submodule: prevent backslash expantion in submodule names

Am 08.04.2017 um 12:59 schrieb Jeff King: The reason I mentioned escaping earlier is I wondered what would happen when the submodule starts with a double-quote, or has a newline in the name. I have tested newlines within the name, these work fine. I also tested double and single quotes within

broken text encoding in commit author name

Hi since git 2.12 I'm having random problems with broken text enciding in author name. As an example broken commit: Author: Michał Walenciak 2017-04-07 21:38:23 Committer: Michał Walenciak 2017-04-07 21:38:33 good commit: Author: Michał Walenciak

Re: Tools that do an automatic fetch defeat "git push --force-with-lease"

Ævar Arnfjör? Bjarmason wrote: > On Sat, Apr 8, 2017 at 5:03 PM, Stefan Haller wrote: > > > Here's a rough proposal for how I would imagine this to work. > > > > For every local branch that has a remote tracking branch, git maintains > > a new config

Re: Feature request: --format=json

On Sat, Apr 8, 2017 at 6:07 PM, Fred .Flintstone wrote: > $ git log --format=json > [{ > "commit": "64eabf050e315a4c7a11e0c05ca163be7cf9075e", > "tree": "b1e977800f40bbf6de906b1fe4f2de4b4b14f0fd", > "author": "Tux 1490981516 +0200", >

Feature request: --format=json

$ git log --format=json [{ "commit": "64eabf050e315a4c7a11e0c05ca163be7cf9075e", "tree": "b1e977800f40bbf6de906b1fe4f2de4b4b14f0fd", "author": "Tux 1490981516 +0200", "committer": "Tux 1490981516 +0200", "message": "This is a test commit",

Re: Tools that do an automatic fetch defeat "git push --force-with-lease"

On Sat, Apr 8, 2017 at 5:03 PM, Stefan Haller wrote: > Matt McCutchen wrote: > >> When I'm rewriting history, "git push --force-with-lease" is a nice >> safeguard compared to "git push --force", but it still assumes the >> remote-tracking ref gives

Re: Tools that do an automatic fetch defeat "git push --force-with-lease"

Jeff King wrote: > I think Matt's point is just that the default, to use origin/branch, is > unsafe. It's convenient when you don't have extra fetches, but that > convenience may not be worth the potential surprise. I don't think "surprise" is the right word here. The point of

Re: Tools that do an automatic fetch defeat "git push --force-with-lease"

Matt McCutchen wrote: > When I'm rewriting history, "git push --force-with-lease" is a nice > safeguard compared to "git push --force", but it still assumes the > remote-tracking ref gives the old state the user wants to overwrite. > Tools that do an implicit fetch,

Re: [PATCH 4/6] receive-pack: quarantine objects until pre-receive accepts

On Sat, Oct 1, 2016 at 11:12 AM, Jeff King wrote: > On Fri, Sep 30, 2016 at 03:36:30PM -0400, Jeff King wrote: > >> @@ -1639,6 +1666,18 @@ static const char *unpack(int err_fd, struct >> shallow_info *si) >> argv_array_push(, alt_shallow_file); >> } >> >> +

Assalamu`Alaikum.

Dear Sir/Madam. Assalamu`Alaikum. I am Dr mohammad ouattara, I have ($10.6 Million us dollars) to transfer into your account, I will send you more details about this deal and the procedures to follow when I receive a positive response from you, Have a great day, Dr mohammad ouattara.

Re: [PATCH v2] unpack-trees: avoid duplicate ODB lookups during checkout

Am 07.04.2017 um 17:53 schrieb g...@jeffhostetler.com: From: Jeff Hostetler Teach traverse_trees_recursive() to not do redundant ODB lookups when both directories refer to the same OID. In operations such as read-tree, checkout, and merge when the differences between

[PATCH 10/12] grep: change the internal PCRE macro names to be PCRE1

Change the internal USE_LIBPCRE define, & build options flag to use a naming convention ending in PCRE1, without changing the long-standing USE_LIBPCRE Makefile flag which enables this code. This is for preparation for libpcre2 support where having things like USE_LIBPCRE and USE_LIBPCRE2 in any

[PATCH 12/12] grep: add support for PCRE v2

Add support for v2 of the PCRE API. This is a new major version of PCRE that came out in early 2015[1]. The regular expression syntax is the same, but while similar-ish requires a different codepath to support it. Git can now be compiled with any combination of USE_LIBPCRE=[YesPlease|] &

[PATCH 06/12] log: add -P as a synonym for --perl-regexp

Add a short -P option as a synonym for the longer --perl-regexp, for consistency with the options the corresponding grep invocations accept. This was intentionally omitted in commit 727b6fc3ed ("log --grep: accept --basic-regexp and --perl-regexp", 2012-10-03) for unspecified future use. Since

[PATCH 04/12] grep: add a test for backreferences in PCRE patterns

Add a test for backreferences such as (.)\1 in PCRE patterns. This test ensures that the PCRE_NO_AUTO_CAPTURE option isn't turned on. Before this change turning it on would break these sort of patterns, but wouldn't break any tests. Signed-off-by: Ævar Arnfjörð Bjarmason ---

[PATCH 02/12] grep: remove redundant regflags assignment under PCRE

Remove a redundant assignment to the "regflags" variable. This variable is only used for POSIX regular expression matching, not when the PCRE library is used. This redundant assignment was added as a result of copy/paste programming in commit 84befcd0a4 ("grep: add a grep.patternType

[PATCH 05/12] log: add exhaustive tests for pattern style options & config

Add exhaustive tests for how the different grep.patternType options & the corresponding command-line options affect git-log. Before this change it was possible to patch revision.c so that the --basic-regexp option was synonymous with --extended-regexp, and --perl-regexp wasn't recognized at all,

[PATCH 09/12] test-lib: rename the LIBPCRE prerequisite to PCRE

Rename the LIBPCRE prerequisite to PCRE. This is for preparation for libpcre2 support, where having just "LIBPCRE" would be confusing as it implies v1 of the library. None of these tests are incompatible between versions 1 & 2 of libpcre, it's less confusing to give them a more general name to

[PATCH 11/12] grep: change the internal PCRE code & header names to be PCRE1

Change the internal PCRE variable & function names to have a "1" suffix. This is for preparation for libpcre2 support, where having non-versioned names would be confusing. The earlier "grep: change the internal PCRE macro names to be PCRE1" change elaborates on the motivations behind this commit.

[PATCH 07/12] grep & rev-list doc: stop promising libpcre for --perl-regexp

Stop promising in our grep & rev-list options documentation that we're always going to be using libpcre when given the --perl-regexp option. Instead talk about using "Perl-compatible regular expressions" and using "the PCRE library". Saying "libpcre" strongly suggests that we might be talking

[PATCH 08/12] grep: make grep.patternType=[pcre|pcre1] a synonym for "perl"

Make the pattern types "pcre" & "pcre1" synonyms for long-standing "perl" grep.patternType. This change is part of a longer patch series to add pcre2 support to Git. It's nice to be able to performance test PCRE v1 v.s. v2 without having to recompile git, and doing that via grep.patternType makes

[PATCH 03/12] Makefile & configure: reword outdated comment about PCRE

Reword an outdated comment which suggests that only git-grep can use PCRE. This comment was added back when PCRE support was initially added in commit 63e7e9d8b6 ("git-grep: Learn PCRE", 2011-05-09), and was true at the time. It hasn't been telling the full truth since git-log learned to use

[PATCH 01/12] grep: add ability to disable threading with --threads=0 or grep.threads=0

Add the ability to entirely disable threading by having grep.threads=0 in the config or --threads=0 on the command-line. This was made configurable in commit 89f09dd34e ("grep: add --threads= option and grep.threads configuration", 2015-12-15). Before that change there was no way to disable

[PATCH 00/12] PCREv2 & more

This adds PCRE v2 support, but as I was adding that I kept noticing other related problems to fix. It's all bundled up into the same series because much of it conflicts because it modifies the same test or other code. Notes on each patch below. Ævar Arnfjörð Bjarmason (12): grep: add ability to

[PATCH] push: document & test --force-with-lease with multiple remotes

Document & test for cases where there are two remotes pointing to the same URL, and a background fetch & subsequent `git push --force-with-lease` shouldn't clobber un-updated references we haven't fetched. Some editors like Microsoft's VSC have a feature to auto-fetch in the background, this

Re: [PATCH] submodule: prevent backslash expantion in submodule names

On Fri, Apr 07, 2017 at 10:23:06AM -0700, Brandon Williams wrote: > When attempting to add a submodule with backslashes in its name 'git > submodule' fails in a funny way. We can see that some of the > backslashes are expanded resulting in a bogus path: > > git -C main submodule add

Re: [PATCH v6 0/3] read-cache: speed up add_index_entry

On Fri, Apr 07, 2017 at 02:27:24PM -0400, Jeff Hostetler wrote: > > Just thinking about this algorithmically for a moment. You're saving the > > binary search when the input is given in sorted order. But in other > > cases you're adding an extra strcmp() before the binary search begins. > > So

Re: [PATCH v7 2/3] p0004-read-tree: perf test to time read-tree

On Fri, Apr 07, 2017 at 09:20:46PM +, g...@jeffhostetler.com wrote: > diff --git a/t/perf/p0004-read-tree.sh b/t/perf/p0004-read-tree.sh > new file mode 100755 > index 000..a70e969 I think p0004 is taken by your lazy-init-name-hash script already (which, btw, I think is missing its

Re: [PATCH v7 1/3] read-cache: add strcmp_offset function

On Fri, Apr 07, 2017 at 09:20:45PM +, g...@jeffhostetler.com wrote: > diff --git a/t/helper/test-strcmp-offset.c b/t/helper/test-strcmp-offset.c > new file mode 100644 > index 000..03e1eef > --- /dev/null > +++ b/t/helper/test-strcmp-offset.c > @@ -0,0 +1,64 @@ > +#include "cache.h" > + >

Re: Tools that do an automatic fetch defeat "git push --force-with-lease"

W dniu 08.04.2017 o 11:29, Jeff King pisze: [...] > Perhaps it would be enough to reset the markers whenever the ref is > pushed. I haven't thought it through well enough to know whether that > just hits more corner cases. I wonder if using a separate remote for pushing (with separate remote-

Re: [PATCH v7 3/3] read-cache: speed up add_index_entry during checkout

On Fri, Apr 07, 2017 at 09:20:47PM +, g...@jeffhostetler.com wrote: > This helps performance on very large repositories. > > > Before and after numbers on index with 1M files > ./p0004-read-tree.sh > 0004.2: read-tree work1 (1003037) 3.21(2.54+0.62) > 0004.3: switch

Re: Tools that do an automatic fetch defeat "git push --force-with-lease"

On Sat, Apr 08, 2017 at 01:25:43AM -0700, Jacob Keller wrote: > On Fri, Apr 7, 2017 at 7:15 PM, Matt McCutchen wrote: > > When I'm rewriting history, "git push --force-with-lease" is a nice > > safeguard compared to "git push --force", but it still assumes the > >

Re: Tools that do an automatic fetch defeat "git push --force-with-lease"

On Sat, Apr 08, 2017 at 09:35:04AM +0200, Ævar Arnfjörð Bjarmason wrote: > Is it correct that you'd essentially want something that works like: > > git push --force-with-lease=master:master origin master:master I don't think that would do anything useful. It would reject any push where the

Re: Tools that do an automatic fetch defeat "git push --force-with-lease"

On Fri, Apr 7, 2017 at 7:15 PM, Matt McCutchen wrote: > When I'm rewriting history, "git push --force-with-lease" is a nice > safeguard compared to "git push --force", but it still assumes the > remote-tracking ref gives the old state the user wants to overwrite. > Tools

Re: Tools that do an automatic fetch defeat "git push --force-with-lease"

On Sat, Apr 8, 2017 at 4:15 AM, Matt McCutchen wrote: > When I'm rewriting history, "git push --force-with-lease" is a nice > safeguard compared to "git push --force", but it still assumes the > remote-tracking ref gives the old state the user wants to overwrite. > Tools

Re: Tools that do an automatic fetch defeat "git push --force-with-lease"

Matt McCutchen wrote: > When I'm rewriting history, "git push --force-with-lease" is a nice > safeguard compared to "git push --force", but it still assumes the > remote-tracking ref gives the old state the user wants to overwrite. > Tools that do an implicit fetch,