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 t
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 and
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
> # Huh?!
> # I didn't wan
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
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, based on the experien
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, it
> might go t
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 config file .git
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 to the main "git" to append to the
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 stuff that is not pr
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 wha
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 'master' will have
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 excludes?
You can kind-o
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:
> >
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 u
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 defaul
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 befo
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
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
> ---
> diff --git a/ref-filt
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
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 the '*' deref indicator still attached
to the n
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 merging
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 helps us
s/which a/which
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:
>> On Thu, Nov 26, 2015 at 9:44 AM, James wro
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 refname), e.g. come u
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 update" command. That way
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
> do we do with refspe
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
retrospect did not include the
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 remo
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 won
`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 them
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 ove
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 deletions(-)
diff --git a/Documenta
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
@@ -1107,8 +1107,6 @@ int cmd_u
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 beca
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 a/builtin/update-index.c b/built
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 --
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 b/builtin/update-index.c
ind
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
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 pro
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 (no
> submodules, maybe not ev
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 an (undocumented) feature. We could
>> a
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 ver
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 o
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 with,
>>> but has been discussed before[1].
>>>
>>> Junio wrot
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 --recurse-subm
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 proje
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:
>> 1. remote upload-pack finds out "not o
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 as there are no O
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 additional flags (thanks Torsten)
>> * fix P4 vers
49 matches
Mail list logo
