Re: [PATCH 1/3] usage.c: add BUG() function

On Fri, May 12, 2017 at 11:28:50PM -0400, Jeff King wrote: > +static NORETURN void BUG_vfl(const char *file, int line, const char *fmt, > va_list params) > +{ > + char prefix[256]; > + > + /* truncation via snprintf is OK here */ > + if (file) > + snprintf(prefix,

[PATCH] usage.c: drop set_error_handle()

The set_error_handle() function was introduced by 3b331e926 (vreportf: report to arbitrary filehandles, 2015-08-11) so that run-command could send post-fork, pre-exec errors to the parent's original stderr. That use went away in 79319b194 (run-command: eliminate calls to error handling functions

[PATCH 2/3] setup_git_env: convert die("BUG") to BUG()

Converting to BUG() makes it easier to detect and debug cases where we hit this assertion. Coupled with a new test in t1300, this shows that the test suite can detect such corner cases. Signed-off-by: Jeff King --- environment.c | 2 +- t/t1300-repo-config.sh | 6 ++

[PATCH 3/3] config: complain about --local outside of a git repo

The "--local" option instructs git-config to read or modify the repository-level config. This doesn't make any sense if you're not actually in a repository. Older versions of Git would blindly try to read or write ".git/config". For reading, this would result in a quiet failure, since there was

[PATCH 1/3] usage.c: add BUG() function

There's a convention in Git's code base to write assertions as: if (...some_bad_thing...) die("BUG: the terrible thing happened"); with the idea that users should never see a "BUG:" message (but if they, it at least gives a clue what happened). We use die() here because it's

[PATCH 0/3] BUG() and "config --local" outside of repo

On Fri, May 12, 2017 at 10:03:46PM -0400, Jeff King wrote: > On Sat, May 13, 2017 at 12:31:31AM +0200, Ævar Arnfjörð Bjarmason wrote: > > > > + if (use_local_config && nongit) > > > + die(_("--local only be used inside a git repository")); > > > + > > > > It would be better

Re: [PATCH v2] builtin/log: honor log.decorate

On Fri, May 12, 2017 at 07:23:04PM -0600, Alex Henrie wrote: > When I saw Brian's email today, my first thought was "What was I > thinking?" My mistake was pretty obvious. Then I remembered that when > I wrote the original patch, I wasn't sure where to set the default > value, because there were

Re: [PATCH v2] builtin/log: honor log.decorate

On Fri, May 12, 2017 at 04:48:14PM -0700, Jonathan Nieder wrote: > Hi, > > brian m. carlson wrote: > > > Does anyone else have views on whether this is good thing to test for? > > I know you don't mean to be rude, but this comes across as a bit of > a dismissive question. Sorry, that wasn't my

Re: [PATCH] config: complain about --local outside of a git repo

On Fri, May 12, 2017 at 05:04:42PM -0700, Jonathan Nieder wrote: > > diff --git a/builtin/config.c b/builtin/config.c > > index 3a554ad50..ad7c6a19c 100644 > > --- a/builtin/config.c > > +++ b/builtin/config.c > > @@ -496,6 +496,9 @@ int cmd_config(int argc, const char **argv, const char > >

Re: [PATCH] config: complain about --local outside of a git repo

On Sat, May 13, 2017 at 12:31:31AM +0200, Ævar Arnfjörð Bjarmason wrote: > > + if (use_local_config && nongit) > > + die(_("--local only be used inside a git repository")); > > + > > It would be better to have a test for edge cases that are currently > only being discovered

[PATCH v4] send-email: --batch-size to work around some SMTP server limit

Some email servers (e.g. smtp.163.com) limit the number emails to be sent per session(connection) and this will lead to a faliure when sending many messages. Teach send-email to disconnect after sending a number of messages (configurable via the --batch-size= option), wait for a few seconds

Re: [PATCH v2] builtin/log: honor log.decorate

2017-05-12 17:48 GMT-06:00 Jonathan Nieder : > Hi, > > brian m. carlson wrote: > >> Does anyone else have views on whether this is good thing to test for? > > I know you don't mean to be rude, but this comes across as a bit of > a dismissive question. The question sounded

Re: [PATCH] config: complain about --local outside of a git repo

Jeff King wrote: > Subject: [PATCH] config: complain about --local outside of a git repo > > The "--local" option instructs git-config to read or modify > the repository-level config. This doesn't make any sense if > you're not actually in a repository. > > Older versions of Git would blindly try

Re: [PATCH v2] builtin/log: honor log.decorate

Hi, brian m. carlson wrote: > Does anyone else have views on whether this is good thing to test for? I know you don't mean to be rude, but this comes across as a bit of a dismissive question. > On Fri, May 12, 2017 at 04:32:14PM -0700, Jonathan Nieder wrote: >> brian m. carlson wrote: >>> The

Re: [PATCH] fixup! log: add exhaustive tests for pattern style options & config

Johannes Schindelin wrote: > On Windows, `(1|2)` is not a valid file name, and therefore the tag > cannot be created as expected by the new test. > > So simply skip this test on Windows. > > Signed-off-by: Johannes Schindelin > --- Reviewed-by: Jonathan Nieder

Re: [PATCH v2] builtin/log: honor log.decorate

On Fri, May 12, 2017 at 04:32:14PM -0700, Jonathan Nieder wrote: > brian m. carlson wrote: > > > The recent change that introduced autodecorating of refs accidentally > > broke the ability of users to set log.decorate = false to override it. > > Yikes. It sounds to me like we need a test to

Re: [PATCH v2] builtin/log: honor log.decorate

brian m. carlson wrote: > The recent change that introduced autodecorating of refs accidentally > broke the ability of users to set log.decorate = false to override it. Yikes. It sounds to me like we need a test to ensure we don't regress it again later. > When the git_log_config was traversed

[PATCH v2] send-email: support validate hook

Currently, send-email has support for rudimentary e-mail validation. Allow the user to add support for more validation by providing a sendemail-validate hook. Helped-by: Ævar Arnfjörð Bjarmason Signed-off-by: Jonathan Tan --- Change from v1: followed

Re: [PATCH v4 1/3] usability: don't ask questions if no reply is required

Thanks, all three patches look good. Will queue. Let's merge them to 'next' soonish and eventually down to 'master' and 'maint'. Thanks.

Re: [RFC] send-email: support validate hook

On Sat, May 13, 2017 at 12:31 AM, Jonathan Tan wrote: > On 05/12/2017 12:23 AM, Ævar Arnfjörð Bjarmason wrote: >> >> I hacked this up last night, it also addresses Junio's comment about >> GIT_DIR: >> > [snip] >> >> >> Changes there: >> >> * use catdir instead of string

Re: [PATCH] config: complain about --local outside of a git repo

On Fri, May 12, 2017 at 10:34 PM, Jeff King wrote: > On Fri, May 12, 2017 at 10:19:59AM -0400, Josh Hagins wrote: > >> Since upgrading to Git 2.13.0 I'm seeing this error message whenever >> `git config --local ` is called outside a Git repository. >> For example, note the

Re: [PATCH] fixup! log: add exhaustive tests for pattern style options & config

Johannes Schindelin writes: > On Windows, `(1|2)` is not a valid file name, and therefore the tag > cannot be created as expected by the new test. > > So simply skip this test on Windows. > > Signed-off-by: Johannes Schindelin > --- Will

Re: [RFC] send-email: support validate hook

On 05/12/2017 12:23 AM, Ævar Arnfjörð Bjarmason wrote: I hacked this up last night, it also addresses Junio's comment about GIT_DIR: [snip] Changes there: * use catdir instead of string concat, I don't know if we run format-patch on any platform where this matters in theory (e.g. VMS I

Re: [PATCH v6] fetch-pack: always allow fetching of literal SHA1s

Jonathan Tan wrote: > Helped-by: Jeff King > Signed-off-by: Jonathan Tan > --- > fetch-pack.c | 35 +-- > t/t5500-fetch-pack.sh | 35 +++ > 2 files changed, 68 insertions(+), 2

Re: [PATCH] compat/regex: fix compilation on Windows

On Thu, May 11, 2017 at 3:50 PM, Johannes Schindelin wrote: > The real issue here is that GNU awk's regex implementation assumes a bit > too much about the relative sizes of pointers and long integers. What they > really want is to use intptr_t. > > This patch

Re: [PATCH v2] builtin/log: honor log.decorate

2017-05-12 16:12 GMT-06:00 brian m. carlson : > The recent change that introduced autodecorating of refs accidentally > broke the ability of users to set log.decorate = false to override it. > When the git_log_config was traversed a second time with an option other >

[PATCH v2] builtin/log: honor log.decorate

The recent change that introduced autodecorating of refs accidentally broke the ability of users to set log.decorate = false to override it. When the git_log_config was traversed a second time with an option other than log.decorate, the decoration style would be set to the automatic style, even if

Re: [PATCH] builtin/log: honor log.decorate

On Fri, May 12, 2017 at 04:03:04PM -0600, Alex Henrie wrote: > > diff --git a/builtin/log.c b/builtin/log.c > > index b3b10cc1e..304923836 100644 > > --- a/builtin/log.c > > +++ b/builtin/log.c > > @@ -34,7 +34,7 @@ static int default_abbrev_commit; > > static int default_show_root = 1; > >

Re: [PATCH] builtin/log: honor log.decorate

2017-05-12 15:34 GMT-06:00 brian m. carlson : > The recent change that introduced autodecorating of refs accidentally > broke the ability of users to set log.decorate = false to override it. > When the git_log_config was traversed a second time with an option other >

[PATCH] builtin/log: honor log.decorate

The recent change that introduced autodecorating of refs accidentally broke the ability of users to set log.decorate = false to override it. When the git_log_config was traversed a second time with an option other than log.decorate, the decoration style would be set to the automatic style, even if

Re: [PATCH] compat/regex: fix compilation on Windows

Johannes Schindelin writes: > I'd place a bet on this part of compat/mingw.h for GCC builds: > > #ifdef __MINGW64_VERSION_MAJOR > #include > #include > typedef _sigset_t sigset_t; > #endif > > and on this part of git-compat-util.h for

Re: [PATCH 00/11] Start retiring .git/remotes/ and .git/branches/ for good

Johannes Schindelin writes: > On Fri, 12 May 2017, Junio C Hamano wrote: >> ... >> FWIW, I do not think there is any reason for people to be using >> .git/remotes/, but for .git/branches/, I do not think I can offer a >> more efficient and easier to use alternative

Re: [PATCH] compat/regex: fix compilation on Windows

On 12/05/17 11:25, Johannes Schindelin wrote: > Hi Junio, > > On Fri, 12 May 2017, Junio C Hamano wrote: > >> Johannes Schindelin writes: >> >>> The real issue here is that GNU awk's regex implementation assumes a >>> bit too much about the relative sizes of

Re: [PATCH 1/7] compat/regex: add a README with a maintenance guide

Johannes Schindelin writes: > - rather than scraping the files from the CGit website (which does not > guarantee that the first scraped file will be from the same revision as > the last scraped file), I would very strongly prefer the files to be > copied from a

[PATCH v6] fetch-pack: always allow fetching of literal SHA1s

fetch-pack, when fetching a literal SHA-1 from a server that is not configured with uploadpack.allowtipsha1inwant (or similar), always returns an error message of the form "Server does not allow request for unadvertised object %s". However, it is sometimes the case that such object is advertised.

[PATCH v5] fetch-pack: always allow fetching of literal SHA1s

fetch-pack, when fetching a literal SHA-1 from a server that is not configured with uploadpack.allowtipsha1inwant (or similar), always returns an error message of the form "Server does not allow request for unadvertised object %s". However, it is sometimes the case that such object is advertised.

[PATCH] config: complain about --local outside of a git repo

On Fri, May 12, 2017 at 10:19:59AM -0400, Josh Hagins wrote: > Since upgrading to Git 2.13.0 I'm seeing this error message whenever > `git config --local ` is called outside a Git repository. > For example, note the difference in behavior between Git 2.13 and > Apple Git: > > $ pwd >

[PATCH] hashmap: hashmap_get_next passes through keydata as well

The 'keydata' may be of value in the underlying compare function to decide if the given two entries are the same. Signed-off-by: Stefan Beller --- Documentation/technical/api-hashmap.txt | 6 -- diffcore-rename.c | 2 +- hashmap.c

Re: [PATCH v5] fetch-pack: always allow fetching of literal SHA1s

Jonathan Tan wrote: > To make the interface less muddy, would you agree with this (untested): > > @@ -648,7 +669,9 @@ static void filter_refs(struct fetch_pack_args *args, > continue; > > if ((allow_unadvertised_object_request & > -(ALLOW_TIP_SHA1 | ALLOW_REACHABLE_SHA1))) { > +

Re: [PATCH 3/2] ls-files: only recurse on active submodules

On 05/12, Paul Jolly wrote: > >> How can I help diagnose what's going on here? > > > > > Welp that's a pretty terrible bug which stems from > > missing a check to see if a submodule is initialized, and not explicitly > > setting GIT_DIR=.git (theres cases where we don't want this but turns > >

Re: [PATCH 1/7] grep: don't redundantly compile throwaway patterns under threading

On Fri, May 12, 2017 at 7:35 PM, Brandon Williams wrote: > On 05/11, Ęvar Arnfjörš Bjarmason wrote: >> Change the pattern compilation logic under threading so that grep >> doesn't compile a pattern it never ends up using on the non-threaded >> code path, only to compile it

Re: [PATCH 3/2] ls-files: only recurse on active submodules

>> How can I help diagnose what's going on here? > Welp that's a pretty terrible bug which stems from > missing a check to see if a submodule is initialized, and not explicitly > setting GIT_DIR=.git (theres cases where we don't want this but turns > out we probably should do that here). Let

Re: [PATCH v5] fetch-pack: always allow fetching of literal SHA1s

On Fri, May 12, 2017 at 12:59 AM, Jeff King wrote: > On Fri, May 12, 2017 at 03:01:35PM +0900, Junio C Hamano wrote: >> Also, tip_oids_contain() uses unmatched and newlist only on the >> first call, but the internal API this patch establishes gives an >> illusion (confusion) that

Re: [PATCH v5] fetch-pack: always allow fetching of literal SHA1s

On Fri, May 12, 2017 at 1:14 AM, Jeff King wrote: > diff --git a/fetch-pack.c b/fetch-pack.c > index afb8b0502..e167213c0 100644 > --- a/fetch-pack.c > +++ b/fetch-pack.c > @@ -15,6 +15,7 @@ > #include "version.h" > #include "prio-queue.h" > #include "sha1-array.h" > +#include

Re: [PATCH 00/11] Start retiring .git/remotes/ and .git/branches/ for good

Johannes Schindelin wrote: > On Fri, 12 May 2017, Junio C Hamano wrote: >> And this one is also important. I do not think we had to touch any >> code that handles .git/remotes/ or .git/branches when we extended >> the .git/config based configuration for remotes, simply because the >> old data

Re: [PATCH 1/7] grep: don't redundantly compile throwaway patterns under threading

On 05/11, Ævar Arnfjörð Bjarmason wrote: > Change the pattern compilation logic under threading so that grep > doesn't compile a pattern it never ends up using on the non-threaded > code path, only to compile it again N times for N threads which will > each use their own copy, ignoring the

Re: [PATCH] pull: optionally rebase submodules

On 05/11, Philip Oakley wrote: > From: "Brandon Williams" > >Teach pull to optionally update submodules when '--recurse-submodules' > >is provided. This will teach pull to run 'submodule update --rebase' > >when the '--recurse-submodules' and '--rebase' flags are given. > > >

Re: [PATCH v2 0/6] convert pathspec.c to take an index parameter

On 05/12, Junio C Hamano wrote: > Brandon Williams writes: > > > The main difference in v2 is that instead of piping through an index_state > > struct into parse_pathspec, I ripped out the logic that needed to access the > > index and either removed it completely if it wasn't

Re: [PATCH 3/2] ls-files: only recurse on active submodules

On 05/12, p...@myitcv.io wrote: > > ... > > I'm nowhere near up to speed with the entire history of this chain so > please excuse me if I've missed some detail somewhere. > > As of b06d3643105c8758ed019125a4399cb7efdcce2c, the following command > "hangs" at near 100% CPU in a repo of mine: > >

Re: [PATCH 3/2] ls-files: only recurse on active submodules

> ... I'm nowhere near up to speed with the entire history of this chain so please excuse me if I've missed some detail somewhere. As of b06d3643105c8758ed019125a4399cb7efdcce2c, the following command "hangs" at near 100% CPU in a repo of mine: git ls-files --recurse-submodules The "hang"

Re: Best "triangle" workflow setup?

On Thu, May 11, 2017 at 6:36 PM, Jeff King wrote: > On Thu, May 11, 2017 at 04:23:03PM -0500, Robert Dailey wrote: > >> On Thu, May 11, 2017 at 3:17 PM, Jeff King wrote: >> > I think you want: >> > >> > [push] >> > default = current >> > [remote] >> >

Re: [Git 2.13.0] BUG: setup_git_env called without repository

Hi Josh, On Fri, 12 May 2017, Josh Hagins wrote: > Since upgrading to Git 2.13.0 I'm seeing this error message whenever > `git config --local ` is called outside a Git repository. > For example, note the difference in behavior between Git 2.13 and > Apple Git: > > $ pwd > /Users/jhagins

[Git 2.13.0] BUG: setup_git_env called without repository

Hey Git people, Since upgrading to Git 2.13.0 I'm seeing this error message whenever `git config --local ` is called outside a Git repository. For example, note the difference in behavior between Git 2.13 and Apple Git: $ pwd /Users/jhagins $ /usr/bin/git --version git version

Re: [PATCH 00/11] Start retiring .git/remotes/ and .git/branches/ for good

Hi Junio, On Fri, 12 May 2017, Junio C Hamano wrote: > Junio C Hamano writes: > > > Johannes Schindelin writes: > > > >> Git uses the config for remote/upstream information in favor of the > >> previously-used .git/remotes/ and .git/branches/ for

Git 2.13 silent install

Hi, Just wondering if someone can send me the instructions for an unattended/silent install for Git 2.13. Thanks, Rabii Sent from my iPhone

[PATCH v4 3/3] git-filter-branch: be more direct in an error message

git-filter-branch requires the specification of a branch by one way or another. If no branch appears to have been specified, we know the user got the usage wrong but we don't know what they were trying to do --- e.g. maybe they specified the ref to rewrite but in the wrong place. In this case,

[PATCH v4 2/3] read-tree -m: make error message for merging 0 trees less smart aleck

"git read-tree -m" requires a tree argument to name the tree to be merged in. Git uses a cutesy error message to say so and why: $ git read-tree -m warning: read-tree: emptying the index with no arguments is deprecated; use --empty fatal: just how do you expect me to merge 0

[PATCH v4 1/3] usability: don't ask questions if no reply is required

There has been a bug report by a corporate user that stated that "spelling mistake of stash followed by a yes prints character 'y' infinite times." This analysis was false. When the spelling of a command contains errors, the git program tries to help the user by providing candidates which are

Re: [PATCH v3 2/3] read-tree -m: make error message for merging 0 trees less smart aleck

On Friday, 12 May 2017, 15:28:53 CEST Junio C Hamano wrote: > Jonathan Nieder writes: > > >> @@ -226,9 +226,10 @@ int cmd_read_tree(int argc, const char **argv, const > >> char *unused_prefix) > >>setup_work_tree(); > >> > >>if (opts.merge) { > >> -

Re: [PATCH 00/11] Start retiring .git/remotes/ and .git/branches/ for good

Junio C Hamano writes: > Johannes Schindelin writes: > >> Git uses the config for remote/upstream information in favor of the >> previously-used .git/remotes/ and .git/branches/ for a decade now. > > The last time I thought about trying this

[GSoC][RFC/PATCH v3 1/2] t7407: test "submodule foreach --recursive" from subdirectory added

Additional test cases added to the submodule-foreach test suite to check the submodule foreach --recursive behavior from a subdirectory as this was missing from the test suite. Mentored-by: Christian Couder Mentored-by: Stefan Beller

[GSoC][RFC/PATCH v3 2/2] submodule: port subcommand foreach from shell to C

This aims to make git-submodule foreach a builtin. This is the very first step taken in this direction. Hence, 'foreach' is ported to submodule--helper, and submodule--helper is called from git-submodule.sh. The code is split up to have one function to obtain all the list of submodules. This

Re: [PATCH 00/11] Start retiring .git/remotes/ and .git/branches/ for good

Hi Peff, On Fri, 12 May 2017, Jeff King wrote: > On Thu, May 11, 2017 at 03:47:33PM +0200, Johannes Schindelin wrote: > > > Git uses the config for remote/upstream information in favor of the > > previously-used .git/remotes/ and .git/branches/ for a decade now. > > > > Nothing in Git writes

[PATCH] fixup! log: add exhaustive tests for pattern style options & config

On Windows, `(1|2)` is not a valid file name, and therefore the tag cannot be created as expected by the new test. So simply skip this test on Windows. Signed-off-by: Johannes Schindelin --- Published-As:

Re: [PATCH] compat/regex: fix compilation on Windows

Hi Junio, On Fri, 12 May 2017, Junio C Hamano wrote: > Johannes Schindelin writes: > > > The real issue here is that GNU awk's regex implementation assumes a > > bit too much about the relative sizes of pointers and long integers. > > What they really want is to use

Re: [PATCH 00/11] Start retiring .git/remotes/ and .git/branches/ for good

Hi Junio, On Fri, 12 May 2017, Junio C Hamano wrote: > Johannes Schindelin writes: > > > Git uses the config for remote/upstream information in favor of the > > previously-used .git/remotes/ and .git/branches/ for a decade now. > > The last time I thought about

Re: [PATCH 1/7] compat/regex: add a README with a maintenance guide

Hi, [replacing Ramsay's email address with a working one] On Fri, 12 May 2017, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > > > diff --git a/compat/regex/README b/compat/regex/README > > new file mode 100644 > > index 00..345d322d8c > > --- /dev/null >

Re: Git credential helper store flushes randomly

12.05.2017 11:45, Jeff King пишет: On Fri, May 12, 2017 at 10:24:50AM +0200, Matthieu Moy wrote: Jeff King writes: The only time it should remove an entry is when Git asks it to. And the only time that happens is when Git sees the credential rejected by the server (e.g., an

Re: [BUG] fast-export --anonymize does not maintain fixup! commits

On Fri, May 12, 2017 at 11:22 AM, Jeff King wrote: >> these (or any other command prefixes in commit messages). Given that >> the --anonymize option is explicitly designed to help reproducing >> bugs, I consider this to be a bug in the --anonymize option itself. > > Yes, it

Re: [PATCH 1/4] docs/config: clarify include/includeIf relationship

On Thu, May 11, 2017 at 05:47:28PM +0100, Ramsay Jones wrote: > > diff --git a/Documentation/config.txt b/Documentation/config.txt > > index 475e874d5..d5a453ed3 100644 > > --- a/Documentation/config.txt > > +++ b/Documentation/config.txt > > @@ -79,14 +79,20 @@ escape sequences) are invalid. > >

Re: [BUG] fast-export --anonymize does not maintain fixup! commits

On Thu, May 11, 2017 at 04:38:17PM +0200, Sebastian Schuberth wrote: > I just tried to created an anonymized repo to allow the list to > reproduce a bug in "rebase -i" I discovered in Git 2.13 for Linux > (Windows is not affected). However, in order to reproduce the bug it's > important to keep

Re: [PATCH 00/11] Start retiring .git/remotes/ and .git/branches/ for good

On Thu, May 11, 2017 at 03:47:33PM +0200, Johannes Schindelin wrote: > Git uses the config for remote/upstream information in favor of the > previously-used .git/remotes/ and .git/branches/ for a decade now. > > Nothing in Git writes to these files any longer, and the most prominent > user of

Re: [PATCH 0/3] interpret-trailers + commit -v bugfix

On Thu, May 11, 2017 at 10:03:44PM -0700, Brian Malehorn wrote: > This patch series addresses a bug in interpret-trailers. If the commit > that is being editted is "verbose", it will contain a scissors string > ("-- >8 --") and a diff. interpret-trailers doesn't interpret the > scissors and

Re: Possible bug in includeIf / conditional includes on non git initialised directories

On Thu, May 11, 2017 at 8:53 PM, Raphael Stolt wrote: > Hi there, > > I might have stumbled this time over a real bug in includeIf / conditional > includes or maybe it's just as intended. > 1) Given I have a correct configured includeIf and I’m issuing `git config >

Re: What's cooking in git.git (May 2017, #04; Fri, 12)

On Fri, May 12, 2017 at 10:44 AM, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > >> On Fri, May 12, 2017 at 8:43 AM, Junio C Hamano wrote: >>> * ab/grep-preparatory-cleanup (2017-05-12) 15 commits >>> - grep: add tests to fix

Re: [PATCH 3/3] commit.c: skip scissors when computing trailers

On Thu, May 11, 2017 at 10:03:47PM -0700, Brian Malehorn wrote: > "scissors" ("- >8 -") can be automatically added to commit > messages by setting commit.verbose = true. Prevent this from interfering > with trailer calculations by automatically skipping over scissors, > instead of

Re: Git credential helper store flushes randomly

On Fri, May 12, 2017 at 10:24:50AM +0200, Matthieu Moy wrote: > Jeff King writes: > > > The only time it should remove an entry is when Git asks it to. And the > > only time that happens is when Git sees the credential rejected by the > > server (e.g., an HTTP 401 even after we

Re: What's cooking in git.git (May 2017, #04; Fri, 12)

Ævar Arnfjörð Bjarmason writes: > On Fri, May 12, 2017 at 8:43 AM, Junio C Hamano wrote: >> * ab/grep-preparatory-cleanup (2017-05-12) 15 commits >> - grep: add tests to fix blind spots with \0 patterns >> - grep: prepare for testing binary regexes

Re: [PATCH 2/3] commit.c: add is_scissors_line

On Thu, May 11, 2017 at 10:03:46PM -0700, Brian Malehorn wrote: > Move is_scissors_line to commit.c and expose it through commit.h. > This is needed in commit.c, and mailinfo.c shouldn't really own it. It was fine for mailinfo to own it until now, since it was the only user. :) I think there are

Re: Git credential helper store flushes randomly

Jeff King writes: > The only time it should remove an entry is when Git asks it to. And the > only time that happens is when Git sees the credential rejected by the > server (e.g., an HTTP 401 even after we fed the stored credential). I > don't know why that would happen unless

Re: [PATCH 1/3] mailinfo.c: is_scissors_line ends on newline

On Thu, May 11, 2017 at 10:03:45PM -0700, Brian Malehorn wrote: > Needed to work with git interpret-trailers. Since "line" is, of course, > a line, it will always end with "\n\0" and therefore we can safely end > on "\n". > [...] > - for (c = line; *c; c++) { > + for (c = line; *c !=

Re: Git credential helper store flushes randomly

On Fri, May 12, 2017 at 11:05:19AM +0300, Райцин Антон wrote: > I have very strange git credentials store behavior on one of my servers. > I Use Ubuntu 14.04 LTS and git 2.10.2. The server have multiple users with > multiple projects, so they have got many different git credentials to >

Re: [PATCH v5] fetch-pack: always allow fetching of literal SHA1s

On Fri, May 12, 2017 at 03:59:31AM -0400, Jeff King wrote: > It's hard to resolve that because the loop that chops up the lists is > also the loop that is figuring out if there are leftover raw-sha1 > names. But you could probably structure it like: > > 1. Loop and see if we have unmatched

Git credential helper store flushes randomly

Hello. I have very strange git credentials store behavior on one of my servers. I Use Ubuntu 14.04 LTS and git 2.10.2. The server have multiple users with multiple projects, so they have got many different git credentials to different repositories. I set git config --global credential.helper

Re: [PATCH v5] fetch-pack: always allow fetching of literal SHA1s

On Fri, May 12, 2017 at 03:01:35PM +0900, Junio C Hamano wrote: > Jonathan Nieder writes: > > >> +static void add_refs_to_oidset(struct oidset *oids, struct ref *refs) > >> +{ > >> + for (; refs; refs = refs->next) > >> + oidset_insert(oids, >old_oid); > >> +} > >>

Re: What's cooking in git.git (May 2017, #04; Fri, 12)

On Fri, May 12, 2017 at 8:43 AM, Junio C Hamano wrote: > * ab/grep-preparatory-cleanup (2017-05-12) 15 commits > - grep: add tests to fix blind spots with \0 patterns > - grep: prepare for testing binary regexes containing rx metacharacters > - SQUASH??? > - grep: add a

Re: [RFC] send-email: support validate hook

On Thu, May 11, 2017 at 9:37 PM, Jonathan Tan wrote: > Currently, send-email has support for rudimentary e-mail validation. > Allow the user to add support for more validation by providing a > sendemail-validate hook. > > Signed-off-by: Jonathan Tan

What's cooking in git.git (May 2017, #04; Fri, 12)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The ones marked with '.' do not appear in any of the integration branches, but I am still holding onto them. You can find the changes

Re: [PATCH v3 2/3] read-tree -m: make error message for merging 0 trees less smart aleck

Jonathan Nieder writes: >> @@ -226,9 +226,10 @@ int cmd_read_tree(int argc, const char **argv, const >> char *unused_prefix) >> setup_work_tree(); >> >> if (opts.merge) { >> -if (stage < 2) >> -die("just how do you expect

Re: [PATCH v3 3/3] git-filter-branch:

Jean-Noel Avila writes: > Subject: Re: [PATCH v3 3/3] git-filter-branch: Forgot the body of the single-liner summary? In the meantime I'll queue this as: Subject: git-filter-branch: be more direct in an error message > test -s "$tempdir"/heads || > - die "Which

Re: [PATCH v5] fetch-pack: always allow fetching of literal SHA1s

Jonathan Nieder writes: >> +static void add_refs_to_oidset(struct oidset *oids, struct ref *refs) >> +{ >> +for (; refs; refs = refs->next) >> +oidset_insert(oids, >old_oid); >> +} >> + >> +static int tip_oids_contain(struct oidset *tip_oids, >> +