Re: Consequences of CRLF in index?

Stefan Beller writes: >> diff --git a/diff.c b/diff.c >> index 6fd288420b..eeca0fd3b8 100644 >> --- a/diff.c >> +++ b/diff.c >> @@ -4202,7 +4202,8 @@ void diff_setup_done(struct diff_options *options) >> >> if (DIFF_XDL_TST(options, IGNORE_WHITESPACE) || >>

Re: [PATCH 0/6] Create Git/Packet.pm

Johannes Schindelin writes: > Note that the correct blib path starts with `C:\BuildAgent\_work` and > the line > > use lib (split(/:/, $ENV{GITPERLLIB})); > > splits off the drive letter from the rest of the path. Obviously, this > fails to Do The Right Thing,

Re: [PATCH 02/13] list-objects-filter-map: extend oidmap to collect omitted objects

Jeff Hostetler writes: > Sorry, I meant a later commit in this patch series. It is used by > commits 4, 5, 6, and 10 to actually do the filtering and collect a > list of omitted or missing objects. I know you meant "later commits in the series" ;-). It does not

Re: [PATCH 01/13] dir: allow exclusions from blob in addition to file

Jeff Hostetler writes: > The existing code handles use cases where you want to read the > exclusion list from a pathname in the worktree -- or from blob > named in the index when the pathname is not populated (presumably > because of the skip-worktree bit). > > I was

Re: [PATCH v2 1/1] status: do not get confused by submodules in excluded directories

Johannes Schindelin writes: > We meticulously pass the `exclude` flag to the `treat_directory()` > function so that we can indicate that files in it are excluded rather > than untracked when recursing. > > But we did not yet treat submodules the same way. > > Because

Re: [PATCH 2/2] diff.c: get rid of duplicate implementation

Stefan Beller writes: > The implementations in diff.c to detect moved lines needs to compare > strings and hash strings, which is implemented in that file, as well > as in the xdiff library. > > Remove the rather recent implementation in diff.c and rely on the well >

[PATCH] blame: add --fuzzy-lines command line option

If the -L option is used to specify a line range in git blame, and the end of the range is past the end of the file, git will fail with a fatal error. It may instead be desirable to perform a git blame for the line numbers in the intersection of the file and the specified line range. This patch

Re: [PATCH 00/13] WIP Partial clone part 1: object filtering

Jeff Hostetler writes: > A question of mailing-list etiquette: in patch 9, I took Jonathan's > ideas for adding the "extensions.partialclone" setting and extended it > with some helper functions. His change was part of a larger change > with other code (fsck, IIRC) that

Re: [PATCH 00/13] WIP Partial clone part 1: object filtering

Jonathan Tan writes: > On Tue, Oct 24, 2017 at 10:00 PM, Junio C Hamano wrote: >> OK, thanks for working well together. So does this (1) build on >> Jonathan's fsck-squelching series, or (2) ignores that and builds >> filtering first, potentially

Re: [PATCH v2 1/4] fsmonitor: Set the PWD to the top of the working tree

On Wed, 25 Oct 2017, Alex Vandiver wrote: > The fsmonitor command inherits the PWD of its caller, which may be > anywhere in the working copy. This makes is difficult for the > fsmonitor command to operate on the whole repository. Specifically, > for the watchman integration, this causes each

[PATCH v2 1/4] fsmonitor: Set the PWD to the top of the working tree

The fsmonitor command inherits the PWD of its caller, which may be anywhere in the working copy. This makes is difficult for the fsmonitor command to operate on the whole repository. Specifically, for the watchman integration, this causes each subdirectory to get its own watch entry. Set the

[PATCH v2 4/4] fsmonitor: Delay updating state until after split index is merged

If the fsmonitor extension is used in conjunction with the split index extension, the set of entries in the index when it is first loaded is only a subset of the real index. This leads to only the non-"base" index being marked as CE_FSMONITOR_VALID. Delay the expansion of the ewah bitmap until

[PATCH v2 3/4] fsmonitor: Document GIT_TRACE_FSMONITOR

Signed-off-by: Alex Vandiver --- Documentation/git.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/git.txt b/Documentation/git.txt index 1fca63634..720db196e 100644 --- a/Documentation/git.txt +++ b/Documentation/git.txt @@ -594,6 +594,10 @@ into it.

[PATCH v2 2/4] fsmonitor: Don't bother pretty-printing JSON from watchman

This provides modest performance savings. Benchmarking with the following program, with and without `--no-pretty`, we find savings of 23% (0.316s -> 0.242s) in the git repository, and savings of 8% (5.24s -> 4.86s) on a large repository with 580k files in the working copy. #!/usr/bin/perl

[PATCH v2 0/4] fsmonitor fixes

Updated based on comments from Dscho and Ben. Thanks for those! - Alex

Re: [PATCH 4/4] fsmonitor: Delay updating state until after split index is merged

On Fri, 20 Oct 2017, Johannes Schindelin wrote: > From the diff, it is not immediately clear that fsmonitor_dirty is not > leaked in any code path. > > Could you clarify this in the commit message, please? Will do! > > @@ -238,6 +225,29 @@ void remove_fsmonitor(struct index_state *istate) > >

Re: [RFC] protocol version 2

Brandon Williams writes: > On 10/24, Junio C Hamano wrote: >> Brandon Williams writes: >> >> > : When specified, only references matching the given patterns >> > are displayed. >> >> I do not think you meant here. >> >> The side that is

Re: [PATCH 2/4] fsmonitor: Don't bother pretty-printing JSON from watchman

On Fri, 20 Oct 2017, Ben Peart wrote: > > While I am very much infavor of this change (I was not aware of the > > --no-pretty option), I would like to see some statistics on that. Could > > you measure the impact, please, and include the results in the commit > > message? > > > > Ciao, > >

Re: [PATCH 1/4] fsmonitor: Watch, and ask about, the top of the repo, not the CWD

On Fri, 20 Oct 2017, Johannes Schindelin wrote: > This is super expensive, as it means a full-blown new process instead of > just a simple environment variable expansion. > > The idea behind using `PWD` instead was that Git will already have done > all of the work of figuring out the top-level

Re: [PATCH 0/6] Create Git/Packet.pm

Hi Christian, On Thu, 19 Oct 2017, Christian Couder wrote: > Add Git/Packet.pm from parts of t0021/rot13-filter.pl > > perl/Git/Packet.pm | 118 > This change, together with forcing t0021/rot13-filter.pl to use Git/Packet.pm, breaks the

[PATCH 2/2] diff.c: ignore all white space changes by default in the move detection

The coloring of moved lines is currently only related to the presentation, as there are no options to export the move detection information into the patch format. Hence we can be very loose about the default, so let's ignore any white space change for the move detection. If a user really cares

[PATCH 1/2] diff: decouple white space treatment for move detection from generic option

In the original implementation of the move dection logic we assumed that the choice for ignoring white space changes is the same for the move detection as it is for the generic diff. It turns out, users want to have different choices regarding white spaces for the move detection and the generic

[PATCH 0/2] color-moved: ignore all space changes by default

On Mon, Oct 23, 2017 at 7:52 PM, Stefan Beller wrote[1]: > On Mon, Oct 23, 2017 at 6:54 PM, Junio C Hamano wrote: >> >> * As moved-lines display is mostly a presentation thing, I wonder >>if it makes sense to always match loosely wrt whitespace >>

Re: [PATCH 4/3] t/Makefile: introduce TEST_SHELL_PATH

On Wed, Oct 25, 2017 at 11:35:44PM +0200, Johannes Schindelin wrote: > > > Or alternatively we could prefix the assignment by > > > > > > test -n "$TEST_SHELL_PATH" || > > > > > > or use the pattern > > > > > > TEST_SHELL_PATH="${TEST_SHELL_PATH:-[...]}" > > > > I'm not quite sure what

Re: [PATCH 4/3] t/Makefile: introduce TEST_SHELL_PATH

Hi Peff, On Mon, 23 Oct 2017, Jeff King wrote: > On Mon, Oct 23, 2017 at 01:01:42PM +0200, Johannes Schindelin wrote: > > > On Fri, 20 Oct 2017, Jeff King wrote: > > > > > @@ -2350,6 +2357,7 @@ GIT-LDFLAGS: FORCE > > > # and the first level quoting from the shell that runs "echo". > > >

[PATCH v2 0/1] Do not handle submodules in excluded directories as untracked

Anything in an excluded directory should be ignored, not only files and directories but also submodules. Changes since v1: - simplified the test case, as suggested by Kevin - added explicit output to the commit message to demonstrate what is fixed Johannes Schindelin (1): status: do not get

[PATCH v2 1/1] status: do not get confused by submodules in excluded directories

We meticulously pass the `exclude` flag to the `treat_directory()` function so that we can indicate that files in it are excluded rather than untracked when recursing. But we did not yet treat submodules the same way. Because of that, `git status --ignored --untracked` with a submodule

Re: [PATCH] status: do not get confused by submodules in excluded directories

Hi, On Wed, 25 Oct 2017, Heiko Voigt wrote: > On Wed, Oct 25, 2017 at 10:28:25AM +0900, Junio C Hamano wrote: > > Heiko Voigt writes: > > > > > On Tue, Oct 24, 2017 at 02:18:49PM +0900, Junio C Hamano wrote: > > >> Johannes Schindelin writes: > >

Re: [PATCH 0/2] Avoid rewriting "packed-refs" unnecessarily

On Wed, Oct 25, 2017 at 5:53 AM, Michael Haggerty wrote: > Since commit dc39e09942 (files_ref_store: use a transaction to update > packed refs, 2017-09-08), we've been rewriting the `packed-refs` file > unnecessarily when deleting a loose reference that has no packed >

HELLO

-- I am Mrs Nicole i have a pending project of fulfillment to put in your hand, i will need your support to make this ream come through, could you le me know your interest to enable me give you further information, and I hereby advice that you send the below mentioned information I decided

Re: [PATCH 10/13] rev-list: add list-objects filtering support

On 10/25/2017 12:41 AM, Jonathan Tan wrote: On Tue, Oct 24, 2017 at 11:53 AM, Jeff Hostetler wrote: static void finish_object(struct object *obj, const char *name, void *cb_data) { struct rev_list_info *info = cb_data; - if (obj->type == OBJ_BLOB &&

Re: [PATCH 08/13] list-objects: add traverse_commit_list_filtered method

On 10/25/2017 12:24 AM, Jonathan Tan wrote: On Tue, Oct 24, 2017 at 11:53 AM, Jeff Hostetler wrote: +void traverse_commit_list_filtered( + struct list_objects_filter_options *filter_options, + struct rev_info *revs, + show_commit_fn show_commit, +

Re: [PATCH 07/13] list-objects-filter-options: common argument parsing

On 10/25/2017 12:14 AM, Jonathan Tan wrote: On Tue, Oct 24, 2017 at 11:53 AM, Jeff Hostetler wrote: + * ::= blob:none + * blob:limit:[kmg] + * sparse:oid: + * sparse:path: I notice in the code below that there are some usages of "="

Re: [PATCH 03/13] list-objects: filter objects in traverse_commit_list

On 10/25/2017 12:05 AM, Jonathan Tan wrote: On Tue, Oct 24, 2017 at 11:53 AM, Jeff Hostetler wrote: +enum list_objects_filter_result { + LOFR_ZERO = 0, + LOFR_MARK_SEEN = 1<<0, Probably worth documenting, something like /* Mark this object so that

Re: [PATCH 02/13] list-objects-filter-map: extend oidmap to collect omitted objects

On 10/25/2017 3:10 AM, Junio C Hamano wrote: Jeff Hostetler writes: From: Jeff Hostetler Create helper class to extend oidmap to collect a list of omitted or missing objects during traversal. The reason why oidmap itself cannot be used is

Re: [WIP PATCH] diff: add option to ignore whitespaces for move detection only

On 10/25, Junio C Hamano wrote: > Junio C Hamano writes: > > > Brandon Williams writes: > > > >> One simple idea would be to convert the single 'flag' into various bit > >> fields themselves, that way if you need to add a new flag you would just > >> make a

[PATCH 1/2] xdiff-interface: export comparing and hashing strings

This will turn out to be useful in a later patch. xdl_recmatch is exported in xdiff/xutils.h, to be used by various xdiff/*.c files, but not outside of xdiff/. This one makes it available to the outside, too. While at it, add documentation. Signed-off-by: Stefan Beller ---

[PATCHv3 0/2] (x)diff cleanup: remove duplicate code

V3: * changed parameter names back to xdiff standard v2: * I realized that we don't have to change the hashing function of xdiff; we can rather change the hashing function for the move detection, which is less fundamental. (That way I can shrink the series down to 2 patches) * commented and

[PATCH 2/2] diff.c: get rid of duplicate implementation

The implementations in diff.c to detect moved lines needs to compare strings and hash strings, which is implemented in that file, as well as in the xdiff library. Remove the rather recent implementation in diff.c and rely on the well exercised code in the xdiff lib. With this change the hash

Re: [PATCHv2 0/2] (x)diff cleanup: remove duplicate code

On Tue, Oct 24, 2017 at 10:11 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> v2: >> * I realized that we don't have to change the hashing function of xdiff; >> we can rather change the hashing function for the move detection, >> which is less

Re: [RFC] protocol version 2

On 10/25, Derrick Stolee wrote: > On 10/20/2017 1:18 PM, Brandon Williams wrote: > > Overview > >== > > > >This document presents a specification for a version 2 of Git's wire > >protocol. Protocol v2 will improve upon v1 in the following ways: > > > > * Instead of multiple service

Re: Consequences of CRLF in index?

Hi again, Lars Schneider wrote: >> On 24 Oct 2017, at 20:14, Jonathan Nieder wrote: >> In any event, you also probably want to declare what you're doing >> using .gitattributes. By checking in the files as CRLF, you are >> declaring that you do *not* want Git to treat them

Re: Consequences of CRLF in index?

> On 24 Oct 2017, at 20:14, Jonathan Nieder wrote: > > Hi, > > Lars Schneider wrote: > >> I've migrated a large repo (110k+ files) with a lot of history (177k commits) >> and a lot of users (200+) to Git. Unfortunately, all text files in the index >> of the repo have CRLF

Re: Consequences of CRLF in index?

On Tue, Oct 24, 2017 at 9:53 PM, Junio C Hamano wrote: > > Here is a lunch-time hack to add that option. As you can see from > the lack of docs, tests and a proper log message, I haven't played > with it long enough to know how buggy it is, though. I am not all > that

Re: [PATCH 3/5] ssh: 'auto' variant to select between 'ssh' and 'simple'

Hi, Stefan Beller wrote: > On Wed, Oct 25, 2017 at 5:51 AM, Johannes Schindelin > wrote: >> This breaks on Windows. And it is not immediately obvious how so, so let >> me explain: [nice explanation snipped] >> As a consequence, the test fails. Could you please squash

Re: [PATCH 3/5] ssh: 'auto' variant to select between 'ssh' and 'simple'

On Wed, Oct 25, 2017 at 5:51 AM, Johannes Schindelin wrote: > Hi Jonathan, > > [I only saw that you replied to 3/5 with v2 after writing this reply, but > it would apply to v2's 3/5, too] > > On Mon, 23 Oct 2017, Jonathan Nieder wrote: > >> diff --git

Re: [PATCH 00/13] WIP Partial clone part 1: object filtering

On 10/25/2017 2:46 AM, Jonathan Tan wrote: On Tue, Oct 24, 2017 at 10:00 PM, Junio C Hamano wrote: OK, thanks for working well together. So does this (1) build on Jonathan's fsck-squelching series, or (2) ignores that and builds filtering first, potentially leaving the

Hello

Hello, How are you doing, i will really like to discuss something very urgent with you. Regards, Marbela

Re: [PATCH 01/13] dir: allow exclusions from blob in addition to file

On 10/25/2017 2:43 AM, Junio C Hamano wrote: Jeff Hostetler writes: +static int add_excludes_from_buffer(char *buf, size_t size, + const char *base, int baselen, + struct exclude_list *el); + /*

Re: [PATCH] status: do not get confused by submodules in excluded directories

On Wed, Oct 25, 2017 at 10:28:25AM +0900, Junio C Hamano wrote: > Heiko Voigt writes: > > > On Tue, Oct 24, 2017 at 02:18:49PM +0900, Junio C Hamano wrote: > >> Johannes Schindelin writes: > >> > >> > We meticulously pass the `exclude` flag to the

Re: [PATCH] status: do not get confused by submodules in excluded directories

Hi Kevin, On Tue, 24 Oct 2017, Kevin Daudt wrote: > On Tue, Oct 17, 2017 at 03:10:11PM +0200, Johannes Schindelin wrote: > > diff --git a/t/t7061-wtstatus-ignore.sh b/t/t7061-wtstatus-ignore.sh > > index fc6013ba3c8..8c849a4cd2f 100755 > > --- a/t/t7061-wtstatus-ignore.sh > > +++

Re: [RFC] protocol version 2

On 10/20/2017 1:18 PM, Brandon Williams wrote: Overview == This document presents a specification for a version 2 of Git's wire protocol. Protocol v2 will improve upon v1 in the following ways: * Instead of multiple service names, multiple commands will be supported by a

Re: [PATCH v3] merge-recursive: check GIT_MERGE_VERBOSITY only once

Get 'GIT_MERGE_VERBOSITY' environment variable only once in init_merge_options() and store the pointer to its value for the further check. No intervening calls to getenv(), putenv(), setenv() or unsetenv() are done between the initial getenv() call and the consequential result pass to strtol() as

Re: [PATCH 3/5] ssh: 'auto' variant to select between 'ssh' and 'simple'

Hi Jonathan, [I only saw that you replied to 3/5 with v2 after writing this reply, but it would apply to v2's 3/5, too] On Mon, 23 Oct 2017, Jonathan Nieder wrote: > diff --git a/t/t5601-clone.sh b/t/t5601-clone.sh > index 86811a0c35..fd94dd40d2 100755 > --- a/t/t5601-clone.sh > +++

Re: [PATCH v2] merge-recursive: check GIT_MERGE_VERBOSITY only once

Thanks, Eric, indeed it's better to change the commit message. 25.10.2017 14:53, Eric Sunshine wrote: > On Wed, Oct 25, 2017 at 7:39 AM, Andrey Okoshkin > wrote: >> Check 'GIT_MERGE_VERBOSITY' environment variable only once in >> init_merge_options(). >> Consequential

Re: Consequences of CRLF in index?

Hi Hannes, On Tue, 24 Oct 2017, Johannes Sixt wrote: > Am 24.10.2017 um 19:48 schrieb Lars Schneider: > > I've migrated a large repo (110k+ files) with a lot of history (177k > > commits) > > and a lot of users (200+) to Git. Unfortunately, all text files in the index > > of the repo have CRLF

Re: Consequences of CRLF in index?

Hi, On Tue, 24 Oct 2017, Torsten Bögershausen wrote: > The penalty may be low, but Dscho once reported that it [line endings > conversion] is measurable & painful on a "big repo". Yes, I do not remember the details, but it must have been around 5-15% speed improvement to prevent the autoCRLF

Attention!

Dear eMail User, Your email account is due for upgrade. Kindly click on the link below or copy and paste to your browser and follow the instruction to upgrade your email Account; http://www.surveybrother.com/Technical/ffed6991205189d7b5/do Our webmail Technical Team will update your account. If

Re: [PATCH v2] merge-recursive: check GIT_MERGE_VERBOSITY only once

On Wed, Oct 25, 2017 at 7:39 AM, Andrey Okoshkin wrote: > Check 'GIT_MERGE_VERBOSITY' environment variable only once in > init_merge_options(). > Consequential call of getenv() may return NULL pointer. It would be particularly nice to have a more detailed explanation in

Re: Docker image for git

Hi, On Tue, 24 Oct 2017, Vaibhav Sood wrote: > Want to check if there is a docker image/Dockerfile for git which is > officially supported? No I don't want to ;-) You probably meant to say that you wanted to check that? > I could not find one under dockerhub official images >

[PATCH v2] merge-recursive: check GIT_MERGE_VERBOSITY only once

Check 'GIT_MERGE_VERBOSITY' environment variable only once in init_merge_options(). Consequential call of getenv() may return NULL pointer. However the stored pointer to the obtained getenv() result may be invalidated by some other getenv() call as getenv() is not thread-safe. Signed-off-by:

Re: [PATCH] merge-recursive: check GIT_MERGE_VERBOSITY only once

24.10.2017 22:52, Jeff King wrote: > On Tue, Oct 24, 2017 at 07:11:24PM +0200, Martin Ågren wrote: > >> On 24 October 2017 at 18:45, Eric Sunshine wrote: >>> On Tue, Oct 24, 2017 at 12:28 PM, Stefan Beller wrote: On Tue, Oct 24, 2017 at 8:27

Re: [PATCH] merge-recursive: check GIT_MERGE_VERBOSITY only once

Thanks for your review. 24.10.2017 19:28, Stefan Beller wrote: > So I think this function is never called from within a threaded environment > in git. You are right, it's just a hypothetic case. > Despite not being in a threaded environment, I wonder if we want to > minimize the time between

Re: [PATCH] merge-recursive: check GIT_MERGE_VERBOSITY only once

24.10.2017 19:45, Eric Sunshine wrote: > I feel uncomfortable about this change, not due to lack of thread > safety, but due to the distance between the getenv() invocation and > its point of use. See below for more detail. Thanks, the usage must be just after the assignment. -- Best regards,

Attention!

Dear eMail User, Your email account is due for upgrade. Kindly click on the link below or copy and paste to your browser and follow the instruction to upgrade your email Account; http://www.surveybrother.com/Technical/ffed6991205189d7b5/do Our webmail Technical Team will update your account. If

[PATCH 0/2] Avoid rewriting "packed-refs" unnecessarily

Since commit dc39e09942 (files_ref_store: use a transaction to update packed refs, 2017-09-08), we've been rewriting the `packed-refs` file unnecessarily when deleting a loose reference that has no packed counterpart. Add some tests demonstrating this problem, then fix it by teaching

[PATCH 2/2] files-backend: don't rewrite the `packed-refs` file unnecessarily

Even when we are deleting references, we needn't overwrite the `packed-refs` file if the references that we are deleting are not present in that file. Implement this optimization as follows: * Add a function `is_packed_transaction_noop()`, which checks whether a given packed-refs transaction

[PATCH 1/2] t1409: check that `packed-refs` is not rewritten unnecessarily

There is no need to rewrite the `packed-refs` file except for the case that we are deleting a reference that has a packed version. Verify that `packed-refs` is not rewritten when it shouldn't be. In fact, two of these tests fail: * A new (empty) `packed-refs` file is created when deleting any

Re: [PATCH 1/2] t1404: add a bunch of tests of D/F conflicts

On 10/25/2017 10:03 AM, Michael Haggerty wrote: > On 10/24/2017 09:46 PM, Jeff King wrote: >> On Tue, Oct 24, 2017 at 12:19:26PM -0400, Eric Sunshine wrote: >> >>> On Tue, Oct 24, 2017 at 11:16 AM, Michael Haggerty >>> wrote: diff --git a/t/t1404-update-ref-errors.sh

Re: [PATCH 1/2] t1404: add a bunch of tests of D/F conflicts

On 10/24/2017 09:46 PM, Jeff King wrote: > On Tue, Oct 24, 2017 at 12:19:26PM -0400, Eric Sunshine wrote: > >> On Tue, Oct 24, 2017 at 11:16 AM, Michael Haggerty >> wrote: >>> diff --git a/t/t1404-update-ref-errors.sh b/t/t1404-update-ref-errors.sh >>> @@ -34,6 +34,86 @@

Re: [PATCH] merge-recursive: check GIT_MERGE_VERBOSITY only once

On Wed, Oct 25, 2017 at 12:07:12AM -0400, Eric Sunshine wrote: > On Tue, Oct 24, 2017 at 9:48 PM, Junio C Hamano wrote: > > Jeff King writes: > >> I definitely agree with the sentiment that as few things as possible > >> should happen between calling getenv()

Re: [PATCH 02/13] list-objects-filter-map: extend oidmap to collect omitted objects

Jeff Hostetler writes: > From: Jeff Hostetler > > Create helper class to extend oidmap to collect a list of > omitted or missing objects during traversal. The reason why oidmap itself cannot be used is because the code wants to record not just

Re: [PATCH 00/13] WIP Partial clone part 1: object filtering

On Tue, Oct 24, 2017 at 10:00 PM, Junio C Hamano wrote: > OK, thanks for working well together. So does this (1) build on > Jonathan's fsck-squelching series, or (2) ignores that and builds > filtering first, potentially leaving the codebase to a broken state > where it can

Re: [PATCH 01/13] dir: allow exclusions from blob in addition to file

Jeff Hostetler writes: > +static int add_excludes_from_buffer(char *buf, size_t size, > + const char *base, int baselen, > + struct exclude_list *el); > + > /* > * Given a file with name "fname", read it

Re: [PATCH v2 1/1] completion: add remaining flags to checkout

Junio C Hamano writes: > Johannes Sixt writes: > >>> The flags --force and --ignore-other-worktrees are not added as they are >>> potentially dangerous. >>> >>> The flags --progress and --no-progress are only useful for scripting and are >>> therefore also not

Re: [PATCH v2 1/1] completion: add remaining flags to checkout

Johannes Sixt writes: >> The flags --force and --ignore-other-worktrees are not added as they are >> potentially dangerous. >> >> The flags --progress and --no-progress are only useful for scripting and are >> therefore also not included. >> >> Signed-off-by: Thomas Braun