[PATCH v2 01/10] update-index: use enum for untracked cache options

Signed-off-by: Christian Couder --- builtin/update-index.c | 18 +- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/builtin/update-index.c b/builtin/update-index.c index 7431938..2430a68 100644 --- a/builtin/update-index.c +++

[PATCH v2 00/10] Untracked cache improvements

Here is a new version of a patch series to improve the untracked cache feature. This v2 still implements core.untrackedCache as a simple bool config variable. When it's true, Git should always try to use the untracked cache, and when false, Git should never use it. Patchs 1/10 to 3/10 add some

[PATCH v2 05/10] dir: add add_untracked_cache()

Factor out code into add_untracked_cache(), which will be used in a later commit. Signed-off-by: Christian Couder --- builtin/update-index.c | 11 +-- dir.c | 14 ++ dir.h | 1 + 3 files changed, 16 insertions(+),

[PATCH v2 03/10] update-index: add untracked cache notifications

Attempting to flip the untracked-cache feature on for a random index file with cd /random/unrelated/place git --git-dir=/somewhere/else/.git update-index --untracked-cache would not work as you might expect. Because flipping the feature on in the index also records the location of the

[PATCH v2 10/10] dir: do not use untracked cache ident anymore

A previous commit disabled the check to see if the untracked cache ident field was matching the current environment. So this field is now useless and we can remove some related code. We don't remove the ident field from "struct untracked_cache" as it would break compatibility with old indexes

[PATCH v2 04/10] 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 e84674f..fffad79 100644 --- a/builtin/update-index.c +++ b/builtin/update-index.c @@

[PATCH 1/2] Introduce grep threads param

"git grep" can now be configured (or told from the command line) how many threads to use when searching in the working tree files. Signed-off-by: Victor Leschuk --- Documentation/config.txt | 4 +++ Documentation/git-grep.txt | 12

[PATCH v2 08/10] 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

[PATCH v2 06/10] dir: add remove_untracked_cache()

Factor out code into remove_untracked_cache(), which will be used in a later commit. Signed-off-by: Christian Couder --- builtin/update-index.c | 3 +-- dir.c | 6 ++ dir.h | 1 + 3 files changed, 8 insertions(+), 2 deletions(-)

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

On Tue, Dec 15, 2015 at 10:49 AM, Torsten Bögershausen wrote: > On 15.12.15 10:34, Christian Couder wrote: >> On Mon, Dec 14, 2015 at 10:30 PM, Junio C Hamano wrote: >>> Junio C Hamano writes: >>> >>> The primary reason why I do not like your

[PATCH v2 09/10] t7063: add tests for core.untrackedCache

Signed-off-by: Christian Couder --- t/t7063-status-untracked-cache.sh | 48 +-- 1 file changed, 46 insertions(+), 2 deletions(-) diff --git a/t/t7063-status-untracked-cache.sh b/t/t7063-status-untracked-cache.sh index

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

On Tue, Dec 15, 2015 at 11:02 AM, Duy Nguyen wrote: > On Tue, Dec 15, 2015 at 4:34 PM, Christian Couder > wrote: >> On Mon, Dec 14, 2015 at 10:30 PM, Junio C Hamano wrote: >>> Junio C Hamano writes: >>> >>>

[PATCH v2 07/10] dir: free untracked cache when removing it

Signed-off-by: Christian Couder --- dir.c | 1 + 1 file changed, 1 insertion(+) diff --git a/dir.c b/dir.c index ffc0286..3b83cc0 100644 --- a/dir.c +++ b/dir.c @@ -1954,6 +1954,7 @@ void add_untracked_cache(void) void remove_untracked_cache(void) { +

[PATCH v2 02/10] 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 | 5 + 2 files changed, 13 insertions(+), 1 deletion(-)

Re: [PATCH v2 07/10] dir: free untracked cache when removing it

Christian Couder writes: > Signed-off-by: Christian Couder > --- > dir.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/dir.c b/dir.c > index ffc0286..3b83cc0 100644 > --- a/dir.c > +++ b/dir.c > @@ -1954,6 +1954,7 @@ void

Re: [PATCH v2 10/10] dir: do not use untracked cache ident anymore

Christian Couder writes: > +/* > + * We used to save the location of the work tree and the kernel version, > + * but it was not a good idea, so we now just save an empty string. > + */ I do agree that storing the kernel version (or hostname or whatever specific to

Re: [PATCH 1/2] Introduce grep threads param

Hello Junio, On 12/15/2015 11:06 PM, Junio C Hamano wrote: Victor Leschuk writes: Subject: Re: [PATCH 1/2] Introduce grep threads param I'll retitle this to something like grep: add --threads= option and grep.threads configuration while queuing (which I did for v7

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

Ævar Arnfjörð Bjarmason writes: > The way the "config decides" patch series deals with this is that if > you have the UC information in the index and the configuration is set > to core.untrackedCache=false the UC will be removed from the index. > > Otherwise you would indeed

Re: [PATCH 1/2] Introduce grep threads param

Victor Leschuk writes: > Subject: Re: [PATCH 1/2] Introduce grep threads param I'll retitle this to something like grep: add --threads= option and grep.threads configuration while queuing (which I did for v7 earlier). > "git grep" can now be configured (or told from

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

On Mon, Dec 14, 2015 at 10:30 PM, Junio C Hamano wrote: > Junio C Hamano writes: > > The primary reason why I do not like your "configuration decides" is > it will be a huge source of confusions and bugs. Imagine what > should happen in this sequence, and

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

On Tue, Dec 15, 2015 at 4:34 PM, Christian Couder wrote: > On Mon, Dec 14, 2015 at 10:30 PM, Junio C Hamano wrote: >> Junio C Hamano writes: >> >> The primary reason why I do not like your "configuration decides" is >> it will be

Re: [PATCH 2/2] push: add '-d' as shorthand for '--delete'

On Mon, Dec 14, 2015 at 11:18:18AM -0800, Junio C Hamano wrote: > Patrick Steinhardt writes: > > > It is only possible to delete branches on remotes by specifying > > the long '--delete' flag. > > Not really. "git push origin :unnecessary-branch" should just work > with out

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

On 15.12.15 10:34, Christian Couder wrote: > On Mon, Dec 14, 2015 at 10:30 PM, Junio C Hamano wrote: >> Junio C Hamano writes: >> >> The primary reason why I do not like your "configuration decides" is >> it will be a huge source of confusions and bugs.

Re: update index mtime etc metadata

On Tue, Dec 15, 2015 at 3:44 AM, Joey Hess wrote: > Is there any available plumbing that can change the mtime etc metadata > that is recorded in the index for a file, to user-provided values? Or, > to force the current file stat metadata to be updated in the index? I don't think

Announcing Git for Windows 2.6.4

Dear Git users, It is my pleasure to announce that Git for Windows 2.6.4 is available from: https://git-for-windows.github.io/ Changes since Git for Windows v2.6.3 (November 10th 2015) New Features ??? Comes with Git v2.6.4. ??? Also available as .tar.bz2 packages (you need an

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

On Tue, Dec 15, 2015 at 8:40 PM, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > I still have a problem with the approach from "design cleanliness" > point of view[...] > > In any case I think we already have agreed to disagree on this > point, so

[ANNOUNCE] Git v2.7.0-rc1

A release candidate Git v2.7.0-rc1 is now available for testing at the usual places. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/testing/ The following public repositories all have a copy of the 'v2.7.0-rc1' tag and the 'master' branch that the tag points at:

Re: [PATCH 0/2] git-p4: fix for handling of multiple depot paths

I'm not sure if my opinion as an outsider is of use, but since the perforce change number is monotonically increasing, my expectation as a user would be for them to be applied in order by the perforce change number. :) - James From: Luke Diamand

Re: [PATCH 3/3] gc: Clean garbage .bitmap files from pack dir

On Fri, Nov 13, 2015 at 04:46:27PM -0800, Doug Kelly wrote: > Similar to cleaning up excess .idx files, clean any garbage .bitmap > files that are not otherwise associated with any .idx/.pack files. > > Signed-off-by: Doug Kelly > --- > builtin/gc.c | 12 ++-- >

[PATCHv2 0/7] Rerolling sb/submodule-parallel-fetch for the time after 2.7

with the interdiff below: diff --git a/git-compat-util.h b/git-compat-util.h index 87456a3..8e39867 100644 --- a/git-compat-util.h +++ b/git-compat-util.h @@ -723,7 +723,6 @@ extern void *xmmap(void *start, size_t length, int prot, int flags, int fd, off_ extern void *xmmap_gently(void *start,

What's cooking in git.git (Dec 2015, #05; Tue, 15)

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. 2.7-rc1 has been tagged. I

Re: [PATCH 1/2] Introduce grep threads param

On Tue, Dec 15, 2015 at 3:06 PM, Junio C Hamano wrote: > Victor Leschuk writes: >> Subject: Re: [PATCH 1/2] Introduce grep threads param > > I'll retitle this to something like > > grep: add --threads= option and grep.threads configuration > > while

Re: [PATCH 0/2] git-p4: fix for handling of multiple depot paths

I'm actually surprised that the patch changes the order at all, since all it does is affect the decision (on a yes/no basis) to include a given file into a changelist. I'm going to have a look at that specific unit test, but of course as a user I'd prefer if the default behaviour could remain

Re: What's cooking in git.git (Dec 2015, #05; Tue, 15)

Jeff King writes: > On Tue, Dec 15, 2015 at 02:48:42PM -0800, Junio C Hamano wrote: > >> * dk/gc-more-wo-pack (2015-11-24) 3 commits >> - gc: Clean garbage .bitmap files from pack dir >> - t5304: Add test for .bitmap garbage files >> - prepare_packed_git(): find more garbage >>

[PATCHv2 7/7] submodules: allow parallel fetching, add tests and documentation

This enables the work of the previous patches. Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano --- Documentation/fetch-options.txt | 7 +++ builtin/fetch.c | 6 +- builtin/pull.c | 6 ++

[PATCHv2 5/7] run-command: add an asynchronous parallel child processor

This allows to run external commands in parallel with ordered output on stderr. If we run external commands in parallel we cannot pipe the output directly to the our stdout/err as it would mix up. So each process's output will flow through a pipe, which we buffer. One subprocess can be directly

[PATCHv2 1/7] submodule.c: write "Fetching submodule " to stderr

From: Jonathan Nieder The "Pushing submodule " progress output correctly goes to stderr, but "Fetching submodule " is going to stdout by mistake. Fix it to write to stderr. Noticed while trying to implement a parallel submodule fetch. When this particular output line went

Re: [RFPR] updates for 2.7?

Junio C Hamano wrote: > Git 2.7-rc1 has just been tagged, and the remainder of the year will > be for the stabilization, fixes to brown-paper-bag bugs, reverts of > regressions, etc., but I haven't seen updates to the various > subsystems you guys maintain for some time.

Re: [PATCH 1/3] prepare_packed_git(): find more garbage

On Thu, Nov 26, 2015 at 12:15:29AM -0600, Doug Kelly wrote: > diff --git a/builtin/count-objects.c b/builtin/count-objects.c > index ba92919..5197b57 100644 > --- a/builtin/count-objects.c > +++ b/builtin/count-objects.c > @@ -17,19 +17,15 @@ static off_t loose_size; > > static const char

[RFPR] updates for 2.7?

Git 2.7-rc1 has just been tagged, and the remainder of the year will be for the stabilization, fixes to brown-paper-bag bugs, reverts of regressions, etc., but I haven't seen updates to the various subsystems you guys maintain for some time. Please throw me "this is a good time to pull and here

Re: What's cooking in git.git (Dec 2015, #05; Tue, 15)

On Tue, Dec 15, 2015 at 2:48 PM, Junio C Hamano wrote: > > * sb/submodule-parallel-fetch (2015-12-14) 8 commits > - submodules: allow parallel fetching, add tests and documentation > - fetch_populated_submodules: use new parallel job processing > - run-command: add an

Re: What's cooking in git.git (Dec 2015, #05; Tue, 15)

On Tue, Dec 15, 2015 at 02:48:42PM -0800, Junio C Hamano wrote: > * dk/gc-more-wo-pack (2015-11-24) 3 commits > - gc: Clean garbage .bitmap files from pack dir > - t5304: Add test for .bitmap garbage files > - prepare_packed_git(): find more garbage > > Follow-on to dk/gc-idx-wo-pack topic,

Re: What's cooking in git.git (Dec 2015, #05; Tue, 15)

Jeff King writes: >> * jc/strbuf-gets (2015-10-28) 17 commits >> [...] >> >> Teach codepaths that communicate with users by reading text files >> to be more lenient to editors that write CRLF-terminated lines. >> Note that this is only about communication with Git, like

[PATCH] blame: display a more helpful error message if the file was deleted

`git blame 22414770 generate-cmdlist.perl` currently results in: fatal: cannot stat path '22414770': No such file or directory This patch changes the error message to: fatal: ambiguous argument 'generate-cmdlist.perl': unknown revision or path not in the working tree. Use '--' to

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

Ævar Arnfjörð Bjarmason writes: > Of course hindsight is 20/20, but I think that given what's been > covered in this thread it's been established that it's categorically > better that if we introduce features like these that they be > configured through the normal configuration

Re: [PATCH 1/3] prepare_packed_git(): find more garbage

On Tue, Dec 15, 2015 at 06:09:57PM -0500, Jeff King wrote: > > @@ -1225,6 +1225,15 @@ static void report_helper(const struct string_list > > *list, > [...] > If I understand this function correctly, we're just trying to > get rid of "boring" cases that do not need to be reported. BTW, I

Re: What's cooking in git.git (Dec 2015, #05; Tue, 15)

Junio C Hamano writes: > There already was strbuf_getline_crlf(), and I wanted a new name to > be conservative. When I re-read the series, I realize that the existing one had exactly the same semantics as strbuf_gets(), so I think no risk would come from reusing that name.

[PATCHv2 0/7] Rerolling sb/submodule-parallel-fetch for the time after 2.7

I am sending out a new version for replacing sb/submodule-parallel-fetch for the time after the 2.7 release. * Dropped the patch, which introduces xread_nonblock * strbuf_read_once uses xread now. This is safe as we poll before using strbuf_read_once, so we know we won't stall. * have the

[PATCHv2 3/7] strbuf: add strbuf_read_once to read without blocking

The new call will read from a file descriptor into a strbuf once. The underlying call xread is just run once. xread only reattempts reading in case of EINTR, which makes it suitable to use for a nonblocking read. Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano

[PATCHv2 2/7] xread: poll on non blocking fds

The man page of read(2) says: EAGAIN The file descriptor fd refers to a file other than a socket and has been marked nonblocking (O_NONBLOCK), and the read would block. EAGAIN or EWOULDBLOCK The file descriptor fd refers to a socket and has been marked

[PATCHv2 6/7] fetch_populated_submodules: use new parallel job processing

In a later patch we enable parallel processing of submodules, this only adds the possibility for it. So this change should not change any user facing behavior. Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano --- submodule.c | 142

[PATCHv2 4/7] sigchain: add command to pop all common signals

The new method removes all common signal handlers that were installed by sigchain_push. CC: Jeff King Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano --- sigchain.c | 9 + sigchain.h | 1 + 2 files changed, 10

Re: What's cooking in git.git (Dec 2015, #05; Tue, 15)

On Tue, Dec 15, 2015 at 03:44:42PM -0800, Junio C Hamano wrote: > Junio C Hamano writes: > > > There already was strbuf_getline_crlf(), and I wanted a new name to > > be conservative. > > When I re-read the series, I realize that the existing one had > exactly the same

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

Jeff King writes: >> If the feature is something only those with really large repositories >> care about, is it a good trade-off to make everybody pay the runtime >> cost and make code more complex and fragile? I am not yet convinced. > > I'm not sure I understand the runtime and

[PATCH] Support rebase --keep-empty and --keep-redundant

From: "David A. Greene" Teach rebase how to invoke cherry-pick to keep empty commits. Add a new option --keep-redundant equivalent to cherry-pick's --keep-redundant-commits. With this option, rebase will preserve empty commits generated as a result of the merging

Re: (unknown)

David Greene writes: > - If new option --keep-redundant is specified, invoke cherry-pick with > --keep-redundant-commits. This came up in the past several weeks, I think; you would need to disable patch-equivalence based commit filtering if you really want to do a

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

Junio C Hamano writes: > This is why the_index.has_untracked_cache is not just a simple "Do I > want to use this feature?" boolean configuration. The index also > stores the real data, and "Am I using this feature?" bit goes hand > in hand with that real data. Thinking that

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

On Tue, Dec 15, 2015 at 2:04 PM, Ævar Arnfjörð Bjarmason wrote: > On Mon, Dec 14, 2015 at 8:44 PM, Junio C Hamano wrote: > > I'm replying to & quoting from two E-Mails of yours at once here for > clarity & less noise. I'm working wich Christian on getting

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

On Mon, Dec 14, 2015 at 8:44 PM, Junio C Hamano wrote: I'm replying to & quoting from two E-Mails of yours at once here for clarity & less noise. I'm working wich Christian on getting this integrated, and we both thought it would be good to have some fresh input on the matter

Re: Where does http.sslcainfo get set in Windows (2.6.3)?

Hi, On Mon, 14 Dec 2015, Lars Schneider wrote: > try to look here: > C:\Users\All Users\Git\config The location should be C:\ProgramData\Git\config for the Git configuration shared between all users and all Git implementations on Windows. Maybe you are running Windows XP, where C:\ProgramData

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

On Wed, Dec 16, 2015 at 12:03 AM, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > >> Of course hindsight is 20/20, but I think that given what's been >> covered in this thread it's been established that it's categorically >> better that if we

[no subject]

This patch isn't ready for prime-time yet but I wanted to get it out for some discussion. While cleaning up and enhancing git-subtree, I've come across the need to have rebase behave nicely in the case of empty and redundant commits. There's a case in pick_one_preserving_merges where git-cherry

Help debugging git-svn

Hello, Eric, Everybody! I need your help getting git-svn to clone a repository. I had already cloned it once but then a few months ago I discovered the authors map file and it's like the first time I did a checkout using git well, perhaps not that much, but close. Seeing the real names of

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

On Tue, Dec 15, 2015 at 03:03:14PM -0800, Junio C Hamano wrote: > The thing is, I do not necessarily view this as "configuration". > The way I see the feature is that you say "--untracked" when you > want the states of untracked paths be kept track of in the index, > just like you say "git add

Odd rebase behavior

Hi, The attached tests do not do what I expected them to do. I commented out the tests involving the new rebase empty commit behavior I just sent. The uncommented tests show the strange behavior. According to the rebase man page, rebase gathers commits as in "git log ..HEAD." However, that is

[RFC] Malicously tampering git metadata?

Hello everyone, I'm Santiago, a PhD student at NYU doing research about secure software development pipelines. We've been studying different aspects of Git lately, (as it is an integral part of many projects) and we believe we've found a vulnerabilty in the way Git structures/signs metadata. An

Re: Announcing Git for Windows 2.6.4

Hi Lars, [since I really do not like to repeat myself, I will re-Cc: the lists] On Tue, 15 Dec 2015, Lars Schneider wrote: > Junio always prefixes his announcements with "[ANNOUNCE] " in the > subject. Would that be an option for you announcements, too? If not then > I just need to update my

Re: Help debugging git-svn

Edmundo Carmona Antoranz wrote: > 1 [main] perl 5652 cygwin_exception::open_stackdumpfile: Dumping stack > trace to perl.exe.stackdump > > And then, in the file: > > Exception: STATUS_ACCESS_VIOLATION at rip=0048360C10C > rax=000601E4BFF8 rbx=5219E248

Re: [PATCH v7] blame: add support for --[no-]progress option

On Sat, Dec 12, 2015 at 7:51 PM, Edmundo Carmona Antoranz wrote: > --progress can't be used with --incremental or > porcelain formats. > > git-annotate inherits the option as well > > Helped-by: Eric Sunshine > Signed-off-by: Edmundo Carmona

[PATCHv3] Makefile: add missing phony target

Add some missing phony target to Makefile. Signed-off-by: Elia Pinto Helped-by: Matthieu Moy --- This is the third version of this patch. Compared to the previous I have added only the missing phony target as suggested by Matthieu Moy

[PATCH v8 0/2] Add git-grep threads param

Introducing v8 of git-grep threads param patch. Patch is now split in 2 parts - 1/2 is actually renewed v6 version (see list of changes below), 2/2 removes dependency on online_cpus() - as we discussed with Eric this is rather significant change in default behavior and should be placed into

[PATCH 2/2] Get rid of online_cpus() when determining grep threads num

Number of threads now doesn't depend on online_cpus(), e.g. if specific number is not configured GREP_NUM_THREADS_DEFAULT (8) threads will be used even on 1-core CPU. Reason: multithreading can improve performance even on single core machines as IO is also a major factor here. Using multiple

Re: What's cooking in git.git (Dec 2015, #05; Tue, 15)

On 15.12.15 23:48, Junio C Hamano wrote: > * tb/ls-files-eol (2015-11-28) 2 commits > - convert.c: mark a file-local function static > - ls-files: Add eol diagnostics > > Add options to ls-files to help diagnose end-of-line problems. > > This latest round hasn't gotten any review yet. > >

Re: [PATCH 0/2] git-p4: fix for handling of multiple depot paths

On 16/12/15 00:38, Sam Hocevar wrote: I'm actually surprised that the patch changes the order at all, since all it does is affect the decision (on a yes/no basis) to include a given file into a changelist. I'm going to have a look at that specific unit test, but of course as a user I'd prefer if

Re: [RFC] Malicously tampering git metadata?

On Tue, Dec 15, 2015 at 7:26 PM, Santiago Torres wrote: > Hello everyone, > > I'm Santiago, a PhD student at NYU doing research about secure software > development pipelines. We've been studying different aspects of Git > lately, (as it is an integral part of many projects) and