[PATCH v2 18/19] index-pack: relax consistency checks for omitted objects

From: Jeff Hostetler Signed-off-by: Jeff Hostetler --- builtin/index-pack.c | 15 +++ 1 file changed, 15 insertions(+) diff --git a/builtin/index-pack.c b/builtin/index-pack.c index 4ff567d..30ff409 100644 --- a/builtin/index-pack.c

[PATCH v2 00/19] WIP object filtering for partial clone

From: Jeff Hostetler This WIP is a follow up to my earlier patch series to teach pack-objects to omit large blobs from packfiles. [1] Like the previous version, this version builds upon a suggestion from Peff [2] to use the traverse_commit_list() machinery to allow

[PATCH v2 12/19] pack-objects: add filtering help text

From: Jeff Hostetler Update pack-objects help text to describe object filtering. Signed-off-by: Jeff Hostetler --- Documentation/git-pack-objects.txt | 14 ++ 1 file changed, 14 insertions(+) diff --git

[PATCH v2 11/19] pack-objects: add object filtering support

From: Jeff Hostetler Teach pack-objects to use filtering provided by the traverse_commit_list_filtered() interface to omit unwanted objects from the result. This feature is intended for narrow/partial clone/fetch. Filtering requires use of "--stdout" option.

[PATCH v2 14/19] upload-pack: add object filtering

From: Jeff Hostetler Signed-off-by: Jeff Hostetler --- upload-pack.c | 39 ++- 1 file changed, 38 insertions(+), 1 deletion(-) diff --git a/upload-pack.c b/upload-pack.c index ffb028d..c709054 100644 ---

[PATCH v2 08/19] rev-list: add object filtering support

From: Jeff Hostetler Teach rev-list to use the filtering provided by the traverse_commit_list_filtered() interface to omit unwanted objects from the result. This feature is only enabled when one of the "--objects*" options are used. When the "--filter-print-manifest"

[PATCH v2 17/19] clone: add filter arguments

From: Jeff Hostetler Signed-off-by: Jeff Hostetler --- builtin/clone.c | 28 1 file changed, 28 insertions(+) diff --git a/builtin/clone.c b/builtin/clone.c index a6ae7d6..1408396 100644 --- a/builtin/clone.c +++

[PATCH v2 16/19] connected: add filter_allow_omitted option to API

From: Jeff Hostetler Signed-off-by: Jeff Hostetler --- connected.c | 3 +++ connected.h | 6 ++ 2 files changed, 9 insertions(+) diff --git a/connected.c b/connected.c index 136c2ac..c25b816 100644 --- a/connected.c +++ b/connected.c @@

[PATCH v2 15/19] fetch-pack: add object filtering support

From: Jeff Hostetler Signed-off-by: Jeff Hostetler --- builtin/fetch-pack.c | 3 +++ fetch-pack.c | 28 fetch-pack.h | 2 ++ transport.c | 27 +++ transport.h

[PATCH v2 01/19] dir: refactor add_excludes()

From: Jeff Hostetler Refactor add_excludes() to separate the reading of the exclude file into a buffer and the parsing of the buffer into exclude_list items. Add add_excludes_from_blob_to_list() to allow an exclude file be specified with an OID. Signed-off-by: Jeff

[PATCH v2 07/19] object-filter: common declarations for object filtering

From: Jeff Hostetler Create common routines and defines for parsing object-filter-related command line arguments and pack-protocol fields. Signed-off-by: Jeff Hostetler --- Makefile| 1 + object-filter.c | 201

Re: [PATCH] RFC: Introduce '.gitorderfile'

On 07/13, Stefan Beller wrote: > On Thu, Jul 13, 2017 at 8:59 AM, Jeff King wrote: > >> This triggers two reactions for me: > >> > >> (a) We should totally do that. > > > >> (b) It's a rabbit hole to go down. > > > > And yes, I had both of those reactions, too. We've had the > >

Re: [PATCH] RFC: Introduce '.gitorderfile'

On Thu, Jul 13, 2017 at 8:59 AM, Jeff King wrote: >> This triggers two reactions for me: >> >> (a) We should totally do that. > >> (b) It's a rabbit hole to go down. > > And yes, I had both of those reactions, too. We've had the > "project-level .gitconfig" discussion many times

Re: "groups of files" in Git?

Thank you taking time to think about my issue (I am actually grateful to everyone in this e-mail thread, who did). I looked into Mercurian MQ and it doesn't seem to fit what I need - from what I understood, it speaks about the committed changes and those are not amendable. This is kinda not what I

Re: [PATCH v1 0/4] Teach 'run' perf script to read config files

On Thu, Jul 13, 2017 at 08:50:46AM +0200, Christian Couder wrote: > Goal > > > Using many long environment variables to give parameters to the 'run' > script is error prone and tiring. > > We want to make it possible to store the parameters to the 'run' > script in a config file. This will

Re: What's cooking in git.git (Jul 2017, #03; Mon, 10)

On Thu, Jul 13, 2017 at 8:53 AM, Jeff King wrote: > So I'd say this is not really force-with-lease at all, but rather a > special mode that is somewhere between a normal fast-forward and a true > force-with-lease. I don't know if it would make sense to give it a > different name,

Re: [PATCH] RFC: Introduce '.gitorderfile'

On Wed, Jul 12, 2017 at 04:54:38PM -0700, Junio C Hamano wrote: > Jeff King writes: > > > I could see somebody arguing that format-patch should respect a project > > preference, since its primary purpose is to communicate your work to the > > rest of the project. > > > > But then

Re: [PATCH] RFC: Introduce '.gitorderfile'

On Wed, Jul 12, 2017 at 02:08:35PM -0700, Stefan Beller wrote: > > I could see somebody arguing that format-patch should respect a project > > preference, since its primary purpose is to communicate your work to the > > rest of the project. > > > > But then you could make a similar argument for

Re: What's cooking in git.git (Jul 2017, #03; Mon, 10)

On Thu, Jul 13, 2017 at 08:22:54AM -0700, Junio C Hamano wrote: > > In other words, --force-with-lease could verify that the upstream branch > > has no commits that weren't seen in the current branch's reflog, i.e. that > > `git rev-parse HEAD@{upstream}` is identical to `git merge-base > >

Re: "groups of files" in Git?

Thank you for the detailed explanation, it looks like merging the commits would be helpful in my case. And I think it is a very good analogy that Perforce changelists are like multiple pending committs, if Git were supporting such. What it won't be achieving by using commits in this schema is the

Re: What's cooking in git.git (Jul 2017, #03; Mon, 10)

Johannes Schindelin writes: > I wonder whether the --force-with-lease option would benefit (and counter > the "unsafe because of behind-the-back operations" argument) from doing > some kind of "reverse pull --rebase". > > In other words, --force-with-lease could

Re: "groups of files" in Git?

Thank you, this could work, but if I am adding new file to the feature/removing the existing file from the feature, aliases usage for "add" doesn't help much. I would really need to have the lists of files... and attributes look more promising. On Tue, Jul 11, 2017 at 4:20 PM, Lars Schneider

[PATCH 15/15] ref-filter: consult want_color() before emitting colors

When color placeholders like %(color:red) are used in a ref-filter format, we unconditionally output the colors, even if the user has asked us for no colors. This usually isn't a problem when the user is constructing a --format on the command line, but it means we may do the wrong thing when the

[PATCH 14/15] pretty: respect color settings for %C placeholders

The color placeholders have traditionally been unconditional, showing colors even when git is not otherwise configured to do so. This was not so bad for their original use, which was on the command-line (and the user could decide at that moment whether to add colors or not). But these days we have

[PATCH 13/15] rev-list: pass diffopt->use_colors through to pretty-print

When rev-list pretty-prints a commit, it creates a new pretty_print_context and copies items from the rev_info struct. We don't currently copy the "use_color" field, though. Nobody seems to have noticed because the only part of pretty.c that cares is the %C(auto,...) placeholder, and presumably

[PATCH 11/15] color: check color.ui in git_default_config()

Back in prehistoric times, our decision on whether or not to show color by default relied on using a config callback that either did or didn't load color config like color.diff. When we introduced color.ui, we put it in the same boat: commands had to manually respect it by using git_color_config()

[PATCH 12/15] for-each-ref: load config earlier

In most commands we load config before parsing command line options, since it lets the latter override the former with a simple variable assignment. In the case of for-each-ref, though, we do it in the reverse order. This is OK with the current code, since there's no interaction between the config

[PATCH 10/15] ref-filter: pass ref_format struct to atom parsers

The callback for parsing each formatting atom gets to see only the atom struct (which it's filling in) and the text to be parsed. This doesn't leave any room for it to behave differently based on context known only to the ref_format. We can solve this by passing in the surrounding ref_format to

Re: [RFC PATCH 1/3] promised-blob, fsck: introduce promised blobs

On 7/13/2017 10:48 AM, Jeff Hostetler wrote: On 7/12/2017 3:28 PM, Jonathan Nieder wrote: Hi, Jeff Hostetler wrote: My primary concern is scale and managing the list of objects over time. [...] For example, on the

[PATCH 09/15] ref-filter: factor out the parsing of sorting atoms

We parse sort strings as single formatting atoms, and just build on parse_ref_filter_atom(). Let's pull this idea into its own function, since it's about to get a little more complex. As a bonus, we can give the function a slightly more natural interface, since our single atoms are in their own

[PATCH 08/15] ref-filter: make parse_ref_filter_atom a private function

The parse_ref_filter_atom() function really shouldn't be exposed outside of ref-filter.c; its return value is an integer index into an array that is private in that file. Since the previous commit removed the sole external caller (and replaced it with a public function at a more appropriately

[PATCH 07/15] ref-filter: provide a function for parsing sort options

The ref-filter module currently provides a callback suitable for parsing command-line --sort options. But since git-tag also supports the tag.sort config option, it needs a function whose implementation is quite similar, but with a slightly different interface. The end result is that builtin/tag.c

[PATCH 06/15] ref-filter: move need_color_reset_at_eol into ref_format

Calling verify_ref_format() doesn't just confirm that the format is sane; it actually sets some global variables that will be used later when formatting the refs. These logically should belong to the ref_format, which would make it possible to use multiple formats within a single program

[PATCH 05/15] ref-filter: abstract ref format into its own struct

The ref-filter module provides routines for formatting a ref for output. The fundamental interface for the format is a "const char *" containing the format, and any additional options need to be passed to each invocation of show_ref_array_item. Instead, let's make a ref_format struct that holds

[PATCH 04/15] ref-filter: simplify automatic color reset

When the user-format doesn't add the closing color reset, we add one automatically. But we do so by parsing the "reset" string. We can just use the baked-in string literal, which is simpler. Signed-off-by: Jeff King --- ref-filter.c | 6 +- 1 file changed, 1 insertion(+), 5

[PATCH 03/15] t: use test_decode_color rather than literal ANSI codes

When we put literal ANSI terminal codes into our test scripts, it makes diffs on those scripts hard to read (the colors may be indistinguishable from diff coloring, or in the case of a reset, may not be visible at all). Some scripts get around this by including human-readable names and converting

[PATCH 02/15] docs/for-each-ref: update pointer to color syntax

The documentation for the %(color) placeholder refers to the color.branch.* config for more details. But those details moved to their own section in b92c1a28f (Documentation/config.txt: describe 'color' value type in the "Values" section, 2015-03-03). Let's update our pointer. We can steal the

[PATCH 01/15] check return value of verify_ref_format()

Users of the ref-filter code must call verify_ref_format() before formatting any refs, but most ignore its return value. This means we may print an error on a syntactically bogus pattern, but keep going anyway. In most cases this results in a fatal error when we actually try to format a ref. But

[PATCH 0/15] making user-format colors conditional on config/tty

This is a cleanup of the patch I posted last October: https://public-inbox.org/git/20161010151517.6wszhuyp57yfn...@sigill.intra.peff.net/ The general idea is that it's rather confusing that "%C(red)" in a pretty-print format does not currently respect color.ui, --no-color, or the usual isatty

Re: [RFC PATCH 1/3] promised-blob, fsck: introduce promised blobs

On 7/12/2017 3:28 PM, Jonathan Nieder wrote: Hi, Jeff Hostetler wrote: My primary concern is scale and managing the list of objects over time. [...] For example, on the Windows repo we have (conservatively) 100M+ blobs (and

Re: [PATCH] commit & merge: modularize the empty message validator

On Tue, 2017-07-11 at 13:22 -0700, Junio C Hamano wrote: > Having said all that, I am not sure "Prevent such surprises" is a > problem that is realistic to begin with.  When a user sees the > editor buffer in "git merge", it is pre-populated with at least a > single line of message "Merge branch

[ANNOUNCE] Git for Windows 2.13.3

Dear Git users, It is my pleasure to announce that Git for Windows 2.13.3 is available from: https://git-for-windows.github.io/ Changes since Git for Windows v2.13.2 (June 26th 2017) New Features * Comes with Git v2.13.3. * Comes with Git LFS v2.2.1. * Comes with MSYS2 runtime

Re: What's cooking in git.git (Jul 2017, #03; Mon, 10)

Hi Junio, On Mon, 10 Jul 2017, Junio C Hamano wrote: > * jc/allow-lazy-cas (2017-07-06) 1 commit > - push: disable lazy --force-with-lease by default > > Because "git push --force-with-lease[=]" that relies on the > stability of remote-tracking branches is unsafe when something > fetches

Re: Git on macOS shows committed files as untracked

On 13/07/17 01:15, Jeff King wrote: On Wed, Jul 12, 2017 at 06:21:28PM -0400, roeder@mailnull.com wrote: In Git on macOS (git version 2.13.2 | brew install git) the status command will show folders as untracked even though they are committed and checked out from the repository. Does not

Re: [PATCH] git-p4: parse marshal output "p4 -G" in p4 changes

Thanks, I've just sent in reply to your previous e-mail three different patches. * The first patch is just to show some broken tests, * Second patch is to fix the original issue I had (the one that initiated this thread) * Third patch is the one that filters out "info" messages in p4CmdList

[PATCH 2/3] git-p4: parse marshal output "p4 -G" in p4 changes

The option -G of p4 (python marshal output) gives more context about the data being output. That's useful when using the command "change -o" as we can distinguish between warning/error line and real change description. This fixes the case where a p4 trigger for "p4 change" is set and the command

[PATCH 3/3] git-p4: filter for {'code':'info'} in p4CmdList

The function p4CmdList accepts a new argument: skip_info. When set to True it ignores any 'code':'info' entry (skip_info=False by default). That allows us to fix some of the tests in t9831-git-p4-triggers.sh known to be broken with verobse p4 triggers Signed-off-by: Miguel Torroja

[PATCH 1/3] git-p4: git-p4 tests with p4 triggers

Some p4 triggers in the server side generate some warnings when executed. Unfortunately those messages are mixed with the output of p4 commands. A few git-p4 commands don't expect extra messages or output lines and may fail with verbose triggers. New tests added are known to be broken.

[PATCH v1 4/4] perf/run: add calls to get_var_from_env_or_config()

These calls make it possible to have the make command or the make options in a config file, instead of in environment variables. Signed-off-by: Christian Couder --- t/perf/run | 3 +++ 1 file changed, 3 insertions(+) diff --git a/t/perf/run b/t/perf/run index

[PATCH v1 3/4] perf/run: add GIT_PERF_DIRS_OR_REVS

This environment variable can be set to some revisions or directories whose Git versions should be tested, in addition to the revisions or directories passed as arguments to the 'run' script. This enables a "perf.dirsOrRevs" configuration variable to be used to set revisions or directories whose

[PATCH v1 1/4] perf/run: add '--config' option to the 'run' script

It is error prone and tiring to use many long environment variables to give parameters to the 'run' script. Let's make it easy to store some parameters in a config file and to pass them to the run script. The GIT_PERF_CONFIG_FILE variable will be set to the argument of the '--config' option.

[PATCH v1 2/4] perf/run: add get_var_from_env_or_config()

Add get_var_from_env_or_config() to easily set variables from a config file if they are defined there and not already set. This can also set them to a default value if one is provided. As an example, use this function to set GIT_PERF_REPEAT_COUNT from the perf.repeatCount config option or from

[PATCH v1 0/4] Teach 'run' perf script to read config files

Goal Using many long environment variables to give parameters to the 'run' script is error prone and tiring. We want to make it possible to store the parameters to the 'run' script in a config file. This will make it easier to store, reuse, share and compare parameters. In the future it

Re: [PATCH v2 2/3] trailers: export action enums and corresponding lookup functions

On Thu, Jul 13, 2017 at 12:21 AM, Paolo Bonzini wrote: > diff --git a/trailer.h b/trailer.h > index e90ba1270..f306bf059 100644 > --- a/trailer.h > +++ b/trailer.h > @@ -1,11 +1,33 @@ > #ifndef TRAILER_H > #define TRAILER_H > > +enum action_where { > + WHERE_END, > +

<    1   2