Re: [PATCH 0/2] git-candidate: git based patch tracking and review

Michael Haggerty wrote: > On 11/10/2015 01:56 PM, Richard Ipsum wrote: >> I've continued my work[1] to add patch tracking and candidate review >> capability >> to git. >> >> git-candidate now has a more git-like user interface, so remote candidates >> can now be specified in a similar way to

Re: [PATCH 0/2] git-candidate: git based patch tracking and review

On Tue, Dec 1, 2015 at 3:55 PM, Jonathan Nieder wrote: > Cc-ing dborowitz, who has been working on storing Gerrit's code review > information in Git instead of a separate database (e.g., see [1]). Thanks, we actually already had a thread going that I realize only in

[RFC/PATCH 3/8] update-index: move 'uc' var declaration

Signed-off-by: Christian Couder --- builtin/update-index.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/builtin/update-index.c b/builtin/update-index.c index b7b5108..b54ddc3 100644 --- a/builtin/update-index.c +++ b/builtin/update-index.c @@

[RFC/PATCH 8/8] update-index: make core.untrackedCache a bool

Most features in Git can be enabled or disabled using a simple bool config variable and it would be nice if untracked cache behaved the same way. This makes --[no-|force-]untracked-cache change the value of core.untrackedCache in the repo config file, to avoid making those options useless and

[RFC/PATCH 4/8] dir: add add_untracked_cache()

This new function will be used in a later patch. Signed-off-by: Christian Couder --- builtin/update-index.c | 11 +-- dir.c | 14 ++ dir.h | 1 + 3 files changed, 16 insertions(+), 10 deletions(-) diff --git

[RFC/PATCH 1/8] update-index: add untracked cache notifications

Doing: cd /tmp git --git-dir=/git/somewhere/else/.git update-index --untracked-cache doesn't work how one would expect. It hardcodes "/tmp" as the directory that "works" into the index, so if you use the working tree, you'll never use the untracked cache. With this patch "git update-index

[RFC/PATCH 2/8] update-index: add --test-untracked-cache

It is nice to just be able to test if untracked cache is supported without enabling it. Signed-off-by: Christian Couder --- Documentation/git-update-index.txt | 9 - builtin/update-index.c | 8 ++-- 2 files changed, 14 insertions(+), 3

[RFC/PATCH 0/8] Untracked cache improvements

Following the discussions on the "config: add core.trustmtime" patch I previously sent, here is a patch series that tries to improve the untracked cache feature. This patch series implements core.untrackedCache instead of core.trustmtime. core.untrackedCache is more complex because basically when

[RFC/PATCH 5/8] dir: add remove_untracked_cache()

This new function will be used in a later patch. Signed-off-by: Christian Couder --- builtin/update-index.c | 3 +-- dir.c | 6 ++ dir.h | 1 + 3 files changed, 8 insertions(+), 2 deletions(-) diff --git a/builtin/update-index.c

Re: [PATCH v2] add test to demonstrate that shallow recursive clones fail

Duy Nguyen writes: > maybe > > git clone --commit-id repo (*) > > instead. Detached head is implied, and this way you don't have to > disambiguate sha-1 vs refname. And --commit-id can also be added in > git-fetch. Actually the git-fetch case is even more interesting, what >

Re: [PATCH v2] add test to demonstrate that shallow recursive clones fail

Junio C Hamano writes: > I do not think you would need a new option for this, by the way. > Just add a new syntax for the LFS of a refspec that cannot possibly > be confused with existing choices of what can come there (i.e. an > empty string to denote deletion, or a partial

Re: [PATCH] clean: new option --exclude-from

On Tue, Dec 1, 2015 at 4:36 PM, James Rouzier wrote: > Eric thank you for the feedback. [re-adding git@vger.kernel.org to recipient list since this response was likely intended to be public] > On Sun, Nov 29, 2015 at 9:24 PM, Eric Sunshine > wrote:

[RFC/PATCH 7/8] update-index: prevent --untracked-cache from performing tests

`git update-index --untracked-cache` used to perform tests to check that the underlying operating system and file system change `st_mtime` field of a directory if files are added or deleted in that directory. But those tests take a long time and there is now `--test-untracked-cache` to perform

[RFC/PATCH 6/8] config: add core.untrackedCache

When we know that mtime is fully supported by the environment, we might want the untracked cache to be always used by default without any mtime test or kernel version check being performed. Also when we know that mtime is not supported by the environment, for example because the repo is shared

Re: [RFC PATCH 0/5] Submodule Groups

Am 01.12.2015 um 00:54 schrieb Stefan Beller: On Wed, Nov 25, 2015 at 11:18 AM, Jens Lehmann wrote: Hmm, I doubt it makes much sense to add the --group option to "git submodule init". I'd rather init all submodules and do the group handling only in the "git submodule

Re: Dependency query regarding contrib scripts

Richard Ipsum wrote: > Having read the docs for integrating new subcommands into git[1] I am looking > for some clarification of the following, > > "While we strongly encourage coding in portable C for portability, > these [C, shell, perl] specific scripting languages are also acceptable. > We

Re: [PATCH/RFC 02/10] ref-filter: introduce struct used_atom

On Wed, Nov 11, 2015 at 2:44 PM, Karthik Nayak wrote: > Introduce the 'used_array' structure which would replace the existing I guess you meant s/used_array/used_atom/ or something? Also, s/which would/to/ > implementation of 'used_array' (which a list of atoms). This

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

On Sat, Nov 28, 2015 at 05:09:32PM +, brian m. carlson wrote: > > I got a bunch of conflicts trying to merge it into 'next' and 'pu' and > > punted on it. I think the tricky bits are coming from > > dt/refs-backend-pre-vtable, where there was a lot of code movement. > > I think as for

Re: [PATCH] verify_pack: do not ignore return value of verification function

On Mon, Nov 30, 2015 at 05:47:42PM -0500, David Turner wrote: > In verify_pack, a caller-supplied verification function is called. > The function returns an int. If that return value is non-zero, > verify_pack should fail. > > The only caller of verify_pack is in builtin/fsck.c, whose verify_fn

Re: [PATCH] Make error message after failing commit_lock_file() less confusing

On Mon, Nov 30, 2015 at 12:40:53PM +0100, SZEDER Gábor wrote: > The error message after a failing commit_lock_file() call sometimes > looks like this, causing confusion: > > $ git remote add remote g...@server.com/repo.git > error: could not commit config file .git/config > # Huh?! > # I

Re: [PATCH v8] Add Travis CI support

On Tue, Dec 01, 2015 at 09:43:45AM +0100, Lars Schneider wrote: > > Thanks. I don't have any other comments on this one. I guess the next > > step is for me to get git/git signed up for Travis, and then merging > > this to 'master' will have the desired effect. > > Thanks! You're right, signing

Re: [PATCH v3] push: add recurseSubmodules config option

On Tue, Dec 01, 2015 at 11:49:43AM +, Mike Crowe wrote: > The --recurse-submodules command line parameter has existed for some > time but it has no config file equivalent. > > Following the style of the corresponding parameter for git fetch, > invent push.recurseSubmodules to provide a

Re: [git-for-windows] How is detected binary files?

On Fri, Nov 27, 2015 at 03:14:58PM +0100, Johannes Schindelin wrote: > On Wed, 25 Nov 2015, Andrzej Borucki wrote: > > > How git detects that file is binary? This must be safe because it not > > allowed to change line breaks in binary files. > > Binary files can contain byte 0 (zero), but: > >

Re: [PATCH/RFC 04/10] ref-filter: skip deref specifier in match_atom_name()

On Wed, Nov 11, 2015 at 2:44 PM, Karthik Nayak wrote: > Signed-off-by: Karthik Nayak A bit of explanation about why this change is desirable would be welcome. I'm guessing it's because a future patch is going to make calls to match_atom_name() with

Re: [PATCH/RFC 05/10] ref-filter: introduce color_atom_parser()

On Wed, Nov 11, 2015 at 2:44 PM, Karthik Nayak wrote: > Introduce color_atom_parser() which will parse a "color" atom and > store its color in the "use_atom" structure for further usage in s/use_atom/used_atom/ > 'populate_value()'. > > Signed-off-by: Karthik Nayak

What's cooking in git.git (Dec 2015, #01; Tue, 1)

What's cooking in git.git (Dec 2015, #01; Tue, 1) -- Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. This should by my final whats-cooking

Re: [PATCH v8] Add Travis CI support

On Tue, Dec 1, 2015 at 4:45 PM, Jeff King wrote: > On Tue, Dec 01, 2015 at 09:43:45AM +0100, Lars Schneider wrote: > >> > Thanks. I don't have any other comments on this one. I guess the next >> > step is for me to get git/git signed up for Travis, and then merging >> > this to

Re: Bug: Incorrect stripping of the [PATCH] prefix in git-am

On Tue, Dec 1, 2015 at 4:58 PM, Jeff King wrote: > On Wed, Nov 25, 2015 at 04:59:35PM +0100, huebbe wrote: > >> Yes, it looks like the `--keep-non-patch` option works around this. >> >> However, shouldn't that be the default behaviour? >> I mean, what is the point in stripping

Re: [PATCH] clean: new option --exclude-from

On Tue, Dec 01, 2015 at 06:18:30PM -0800, Junio C Hamano wrote: > > Should this perhaps be an option to the main "git" to append to the set > > of excludes? > > > > You can kind-of do this already with: > > > > git -c core.excludesfile=/path/to/whatever clean ... > > > > but of course you might

Re: [PATCH] Make error message after failing commit_lock_file() less confusing

Jeff King writes: > On Mon, Nov 30, 2015 at 12:40:53PM +0100, SZEDER Gábor wrote: > >> The error message after a failing commit_lock_file() call sometimes >> looks like this, causing confusion: >> >> $ git remote add remote g...@server.com/repo.git >> error: could not commit

Re: [PATCH] clean: new option --exclude-from

Jeff King writes: > On Thu, Nov 26, 2015 at 09:44:25AM -0500, James wrote: > >> From: James Rouzier >> >> Specify a file to read for exclude patterns. >> --- > > Lots of commands care about excludes (e.g., "add", "status"). > > Should this perhaps be an option

Re: Bug: Incorrect stripping of the [PATCH] prefix in git-am

Jeff King writes: > The "[]" convention is a microformat used by Linux kernel folks. So it's > not "whoops, we are stripping stuff not added by git". It is respecting > a microformat used by the tool's authors. > > That being said, if we were choosing a default from scratch today,

Re: [PATCH] clean: new option --exclude-from

On Thu, Nov 26, 2015 at 09:44:25AM -0500, James wrote: > From: James Rouzier > > Specify a file to read for exclude patterns. > --- Lots of commands care about excludes (e.g., "add", "status"). Should this perhaps be an option to the main "git" to append to the set of

Re: Bug: Incorrect stripping of the [PATCH] prefix in git-am

On Wed, Nov 25, 2015 at 04:59:35PM +0100, huebbe wrote: > Yes, it looks like the `--keep-non-patch` option works around this. > > However, shouldn't that be the default behaviour? > I mean, what is the point in stripping stuff that is not proven to be > inserted by `git` itself? > That's not

Re: Bug: Incorrect stripping of the [PATCH] prefix in git-am

Stefan Beller writes: > Do we as the Git community have a place where we take notes for version 3? I do not think there is, I do think we might need one when a need arises, and I do not think this topic is one that creates such a need. And I said "might" in the second one,

Dependency query regarding contrib scripts

Hi, Having read the docs for integrating new subcommands into git[1] I am looking for some clarification of the following, "While we strongly encourage coding in portable C for portability, these [C, shell, perl] specific scripting languages are also acceptable. We won’t accept more without a

Re: Git clone fails during pre-commit hook due to GIT_WORK_TREE=. (regression 2.5 -> 2.6)

On Mon, Nov 30, 2015 at 9:16 PM, Junio C Hamano wrote: > Duy Nguyen writes: > >> I was wrong, GIT_WORK_TREE support was added in git-clone many years >> ago in 20ccef4 (make git-clone GIT_WORK_TREE aware - 2007-07-06). So >> my change accidentally triggers

Re: [RFC/PATCH 6/8] config: add core.untrackedCache

On 12/01/2015 09:31 PM, Christian Couder wrote: When we know that mtime is fully supported by the environment, we might want the untracked cache to be always used by default without any mtime test or kernel version check being performed. I'm not sure if ever "we know" ? How can we know without

Re: arbitrary memory allocation

On Thu, Nov 26, 2015 at 05:06:35AM +0100, ytr...@sdf-eu.org wrote: > First, something I still don t understand, should I always ulimit ram > usage for security purposes when I m manage a public server? You didn't define "public" here. For serving fetches, the memory tends to be fairly bounded

Re: [PATCH] Make error message after failing commit_lock_file() less confusing

On Mon, Nov 30, 2015 at 6:40 AM, SZEDER Gábor wrote: > The error message after a failing commit_lock_file() call sometimes > looks like this, causing confusion: > > $ git remote add remote g...@server.com/repo.git > error: could not commit config file .git/config > #

[PATCH] git-gui: Remove ancient Cygwin compatibility code

Remove special path handling for Cygwin in the git-gui Makefile. This used to be necessary, but has been being patched out of the official Cygwin distribution builds since Git v1.7.9, and should really be patched out of the upstream code rather than being patched every time in the Cygwin build

Re: [PATCHv2] builtin/clone: support submodule groups

On Mon, Nov 30, 2015 at 10:53 PM, Michael J Gruber wrote: > I think we have to solve more basic issues for sparse checkouts first. > I'm using them with extra worktrees now and everything seems to be > working fine. But we need to get the UI right for the simple case

Re: [PATCH v8] Add Travis CI support

On 28 Nov 2015, at 18:12, Jeff King wrote: > On Fri, Nov 27, 2015 at 10:23:26AM +0100, larsxschnei...@gmail.com wrote: > >> From: Lars Schneider >> >> diff to v7: >> * remove NO_GETTEXT patch and install gettext on OS X to compile with >> no

Re: [PATCH v1 2/2] add "ok=sigpipe" to test_must_fail and use it to fix flaky tests

On 28 Nov 2015, at 18:10, Jeff King wrote: > On Fri, Nov 27, 2015 at 10:15:14AM +0100, larsxschnei...@gmail.com wrote: > >> From: Lars Schneider >> >> t5516 "75 - deny fetch unreachable SHA1, allowtipsha1inwant=true" is >> flaky in the following case:

Re: [RFC] OS X El Capitan + Xcode ships without SSL header?!

On 29 Nov 2015, at 18:04, Torsten Bögershausen wrote: > On 21/11/15 19:58, Lars Schneider wrote: >> Hi, >> >> I cannot build Git on a clean machine with OS X El Capitan 10.11, Xcode >> 7.1.1 and Xcode command line tools because of missing OpenSSL headers. >> >> It looks like

Re: Investment/loan

Hello, Kindly permit me to properly introduce myself, I'm a broker, financial consultant in Beverly Hills, California, US. I'm contacting you regarding the company GIFG, a financial institute funding extremely wide variety of projects including real estate, amusement parks, eco and green

Re: Git 'pre-receive' hook and 'git-clang-format' script to reliably reject pushes that violate code style conventions

I don't want to smell like a nasty bumper here, but assuming that my questions were posted not in appropriate time (Saturday evening), I would like to call for help one last time. Thank you. Kind regards, Alexander -- To unsubscribe from this list: send the line "unsubscribe git" in the body

[PATCH v3] push: add recurseSubmodules config option

The --recurse-submodules command line parameter has existed for some time but it has no config file equivalent. Following the style of the corresponding parameter for git fetch, invent push.recurseSubmodules to provide a default for this parameter. This also requires the addition of

Re: [PATCH v2] add test to demonstrate that shallow recursive clones fail

On Tue, Dec 1, 2015 at 1:47 AM, Stefan Beller wrote: > On Mon, Nov 30, 2015 at 10:11 AM, Junio C Hamano wrote: >> Stefan Beller writes: >> >>> +cc Junio, Duy >>> >>> So cloning from an arbitrary SHA1 is not a new thing I just came up