Improve support for 'git config gc.reflogExpire never'

If I configure bare repo with git config gc.pruneExpire never git config gc.reflogExpire never then git will never garbage collect any commit ever stored in the repo. This is what I want. However, all commits referenced only via reflog are kept as loose objects and will not be included in packs.

Re: Error fetching submodule from submodule

Thanks Jeff You are completely right! It works as I expect if I remember the extra parameter `--recursive` when doing `git submodule update --init --recursive` Thanks a lot for your feedback! This is really useful! I learned a useful thing today :) /Jesper On Thu, Mar 7, 2019 at 7:08 PM Jeff Ki

Re: [PATCH v3 1/2] worktree: fix worktree add race.

Junio, it seems 2/2 is stuck in an endless discussion. But 1/2 is good regardless, maybe pick it up now and let 2/2 come later whenever it's ready? On Wed, Feb 20, 2019 at 11:16 PM Michal Suchanek wrote: > > Git runs a stat loop to find a worktree name that's available and then does > mkdir on th

[PATCH v5 1/1] worktree add: sanitize worktree names

Worktree names are based on $(basename $GIT_WORK_TREE). They aren't significant until 3a3b9d8cde (refs: new ref types to make per-worktree refs visible to all worktrees - 2018-10-21), where worktree name could be part of a refname and must follow refname rules. Update 'worktree add' code to remove

[PATCH v5 0/1] worktree add: sanitize worktree names

v5 is basically Jeff's version from one of the replies in v4, where check_refname_component is enhanced to optionally sanitize. I was reluctant to go this way because it makes check_refname_component more complex (turns out still manageable) and burns worktree rules in it. But there may never be t

ls-remote set timeout

Hi there! Im new to this list - so hello, hope I'm welcome. My problem is: I have a configuration for my bash saved on a private git-repo. Every time, i start bash, my .bashrc checks this repo out to get all changes (alias, some functions, $PS1 and so on). So i can have my working environment on

Re: [PATCH v3 1/2] worktree: fix worktree add race.

On Fri, Mar 8, 2019 at 4:20 AM Duy Nguyen wrote: > Junio, it seems 2/2 is stuck in an endless discussion. But 1/2 is good > regardless, maybe pick it up now and let 2/2 come later whenever it's > ready? Yep, 1/2 seems a good idea and has not been controversial. It may not solve all the race condi

Re: [GSoC][PATCH v2 3/3] t3600: use helpers to replace test -d/f/e/s

On Fri, Mar 8, 2019 at 12:38 AM Junio C Hamano wrote: > An unrelated tangent, but what do you think of this patch? In the > context of testing "git rm", if foo is a dangling symbolic link, > "git rm foo && test_path_is_missing foo" would need something like > this to work correctly, I would think

PRIVEE

Good day , my name is David William , i sent you a mail and there was no response , please confirm that you did get this mail for more details. Regards. David William

[PATCH v3 02/21] git-checkout.txt: fix one syntax line

can be omitted in this syntax, and it's actually documented a few paragraphs down: You could omit , in which case the command degenerates to "check out the current branch", which is a glorified no-op with rather expensive side-effects to show only the tracking information, if exists, for

[PATCH v3 00/21] Add new command "switch"

v3 contains document and completion updates based on v2's feedback. It also contains some extra git-checkout.txt updates (blame Eric for this, he points out problems in git-switch.txt and makes me want to go fix git-checkout.txt too). The series is now based on 'master' (yay!) Nguyễn Thái Ngọc Du

[PATCH v3 03/21] doc: document --overwrite-ignore

I added this option in git-checkout and git-merge in c1d7036b6b (checkout,merge: disallow overwriting ignored files with --no-overwrite-ignore - 2011-11-27) but did not remember to update documentation. This completes that commit. --- Documentation/git-checkout.txt | 6 ++ Documentation/git-me

[PATCH v3 01/21] git-checkout.txt: spell out --no-option

It's easier to search for and also less cryptic. --- Documentation/git-checkout.txt | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt index f179b43732..99c8c0dc0f 100644 --- a/Documentation/git-checkout.t

[PATCH v3 06/21] checkout: factor out some code in parse_branchname_arg()

This is in preparation for the new command restore, which also needs to parse opts->source_tree but does not need all the disambiguation logic. --- builtin/checkout.c | 51 -- 1 file changed, 31 insertions(+), 20 deletions(-) diff --git a/builtin/checko

[PATCH v3 05/21] t: rename t2014-switch.sh to t2014-checkout-switch.sh

The old name does not really say that this is about 'checkout -b'. See 49d833dc07 (Revert "checkout branch: prime cache-tree fully" - 2009-05-12) for more information --- t/{t2014-switch.sh => t2014-checkout-switch.sh} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename t/{t2014-switch.sh

[PATCH v3 04/21] git-checkout.txt: fix monospace typeset

--- Documentation/git-checkout.txt | 60 +- 1 file changed, 30 insertions(+), 30 deletions(-) diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt index 5280d1f9ed..1b9d689933 100644 --- a/Documentation/git-checkout.txt +++ b/Documentation/g

[PATCH v3 12/21] switch: remove -l

This option is ancient. Nowadays reflog is enabled by default and automatically created for new branches. Keep it in git-checkout only. --- builtin/checkout.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builtin/checkout.c b/builtin/checkout.c index 4c3f0f6ac7..a731f983c4 10

[PATCH v3 08/21] checkout: move 'confict_style' and 'dwim_..' to checkout_opts

These local variables are referenced by struct option[]. This struct will soon be broken down, moved away and we can't rely on local variables anymore. Move these two to struct checkout_opts in preparation for that. --- builtin/checkout.c | 17 ++--- 1 file changed, 10 insertions(+), 7

[PATCH v3 13/21] switch: stop accepting pathspec

This command is about switching branch (or creating a new one) and should not accept pathspec. This helps simplify ambiguation handling. The other two ("git checkout" and "git restore") of course do accept pathspec as before. --- builtin/checkout.c | 20 +++- 1 file changed, 15 ins

[PATCH v3 14/21] switch: reject "do nothing" case

"git checkout" can be executed without any arguments. What it does is not exactly great: it switches from HEAD to HEAD and shows worktree modification as a side effect. Make switch reject this case. Just use "git status" if you want that side effect. For switch, you have to either - really switch

[PATCH v3 15/21] switch: only allow explicit detached HEAD

"git checkout " will checkout the commit in question and detach HEAD from the current branch. It is naturally a right thing to do once you get git references. But detached HEAD is a scary concept to new users because we show a lot of warnings and stuff, and it could be hard to get out of (until you

[PATCH v3 17/21] switch: no implicit dwim, use --guess to dwim

Similar to automatic detach, this behavior could be confusing because it can sometimes create a new branch without a user asking it to, especially when the user is still not aware about this feature. In the future, perhaps we could have a config key to disable these safety nets and let 'switch' do

[PATCH v3 16/21] switch: add short option for --detach

"git checkout" automatically detaches branches and --detach is not that useful (--no-detach is more likely). But for "switch", you may want to use it more often once you're used to detached HEAD. This of course adds -d to git-checkout but it does not harm (yet?) to do it. --- builtin/checkout.c |

[PATCH v3 10/21] checkout: split part of it to new command 'switch'

"git checkout" doing too many things is a source of confusion for many users (and it even bites old timers sometimes). To remedy that, the command will be split into two new ones: switch and something-to-checkout-paths. The good old "git checkout" command is still here and will be until all (or mos

[PATCH v3 09/21] checkout: split options[] array in three pieces

This is a preparation step for introducing new commands that do parts of what checkout does. There will be two new commands, one is about switching branches, detaching HEAD... one about checking out paths. These share the a subset of command line options. The rest of command line options are separa

[PATCH v3 11/21] switch: better names for -b and -B

The shortcut of these options do not make much sense when used with switch. And their descriptions are also tied to checkout. Move -b/-B to cmd_checkout() and new -c/-C with the same functionality in cmd_switch_branch() --- builtin/checkout.c | 32 +--- 1 file changed,

[PATCH v3 07/21] checkout: make "opts" in cmd_checkout() a pointer

"opts" will soon be moved out of cmd_checkout(). To keep changes in that patch smaller, convert "opts" to a pointer and keep the real thing behind "real_opts". --- builtin/checkout.c | 115 +++-- 1 file changed, 58 insertions(+), 57 deletions(-) diff --git

[PATCH v3 20/21] completion: support switch

Completion support for --guess could be made better. If no --detach is given, we should only provide a list of refs/heads/* and dwim ones, not the entire ref space. But I still can't penetrate that __git_refs() function yet. --- contrib/completion/git-completion.bash | 27 +

[PATCH v3 21/21] doc: promote "git switch"

The new command "git switch" is added to avoid the confusion of one-command-do-all "git checkout" for new users. They are also helpful to avoid ambiguation context. For these reasons, promote it everywhere possible. This includes documentation, suggestions/advice from other commands... --- Docume

[PATCH v3 19/21] t: add tests for switch

--- t/t2060-switch.sh | 87 +++ 1 file changed, 87 insertions(+) create mode 100755 t/t2060-switch.sh diff --git a/t/t2060-switch.sh b/t/t2060-switch.sh new file mode 100755 index 00..1e1e834c1b --- /dev/null +++ b/t/t2060-switch.sh @@ -0,0 +1,

[PATCH v3 18/21] switch: no worktree status unless real branch switch happens

When we switch from one branch to another, it makes sense to show a summary of local changes since there could be conflicts, or some files left modified When switch is used solely for creating a new branch (and "switch" to the same commit) or detaching, we don't really need to show anything. "

[PATCH v1 07/11] restore: default to --source=HEAD when only --index is specified

"git restore --index" does not make much sense since we're told to restore the index from the (by default) index. Set default source to HEAD in this case. This is basically the same as "git reset -- ". Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/checkout.c | 6 ++ 1 file changed, 6 inser

[PATCH v1 09/11] t: add tests for restore

Signed-off-by: Nguyễn Thái Ngọc Duy --- t/lib-patch-mode.sh | 12 t/t2070-restore.sh (new +x) | 77 ++ t/t2071-restore-patch.sh (new +x) | 105 ++ 3 files changed, 194 insertions(+) diff --git a/t/lib-patch-mode.sh b/t/li

[PATCH v1 05/11] checkout: factor out worktree checkout code

Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/checkout.c | 108 + 1 file changed, 59 insertions(+), 49 deletions(-) diff --git a/builtin/checkout.c b/builtin/checkout.c index 9e59bf792f..5fb85e7b73 100644 --- a/builtin/checkout.c +++ b/builtin/checko

[PATCH v1 08/11] restore: support --patch

git-restore is different from git-checkout that it only restores the worktree by default, not both worktree and index. add--interactive needs some update to support this mode. Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/checkout.c| 5 ++-- git-add--interactive.perl | 52

[PATCH v1 06/11] restore: add --worktree and --index

'git checkout ' updates both index and worktree. But updating the index when you want to restore worktree files is non-intuitive. The index contains the data ready for the next commit, and there's no indication that the user will want to commit the restored versions. 'git restore' therefore by de

[PATCH v1 00/11] And new command "restore"

This is the companion of "git switch" [1] and is based on that topic. This command peforms the "checkout paths" from git-checkout, git-reset and also has a third mode to reset only worktree, leaving the index alone. For new people not aware of previous discussions, this command is supposed to be a

[PATCH v1 01/11] checkout: split part of it to new command 'restore'

Previously the switching branch business of 'git checkout' becomes a new command. This adds restore command for the checking out paths path. Similar to switch, a new man page is added to describe what the command will become. The implementation will be updated shortly to match the man page. A cou

[PATCH v1 03/11] restore: make pathspec mandatory

"git restore" without arguments does not make much sense when it's about restoring files (what files now?). We could default to either git restore . or git restore :/ Neither is intuitive. Make the user always give pathspec, force the user to think the scope of restore they want because

[PATCH v1 10/11] completion: support restore

Completion for restore is straightforward. We could still do better though by give the list of just tracked files instead of all present ones. But let's leave it for later. Signed-off-by: Nguyễn Thái Ngọc Duy --- contrib/completion/git-completion.bash | 15 +++ 1 file changed, 15 ins

[PATCH v1 04/11] restore: disable overlay mode by default

Overlay mode is considered confusing when the command is about restoring files on worktree. Disable it by default. The user can still turn it on, or use 'git checkout' which still has overlay mode on by default. While at there make the check in checkout_branch() stricter. Neither --overlay or --no

[PATCH v1 02/11] restore: take tree-ish from --source option instead

This is another departure from 'git checkout' syntax, which uses -- to separate ref and pathspec. The observation is restore (or "git checkout ,, ") is most often used to restore some files from the index. If this is correct, we can simplify it by taking a way the ref, so that we can write git

[PATCH v1 11/11] doc: promote "git restore"

The new command "git restore" (together with "git switch") are added to avoid the confusion of one-command-do-all "git checkout" for new users. They are also helpful to avoid ambiguation context. For these reasons, promote it everywhere possible. This includes documentation, suggestions/advice fro

One failed self test on Fedora 29

Fedora 29, x86_64. One failed self test: *** t0021-conversion.sh *** ok 1 - setup ok 2 - check ok 3 - expanded_in_repo ok 4 - filter shell-escaped filenames ok 5 - required filter should filter data ok 6 - required filter smudge failure ok 7 - required filter clean failure ok 8 - filtering large i

fast-import on existing branches

Hi there, I've struggled for quite some time to sort out documented, intended and actual behavior of git fast-import. Unless I'm completely mistaken, it seems to be a straightforward bug, but if that is the case, I am really surprised why nobody else has stumbled over it before: I managed to u

[PATCH 1/2] modified dir-iterator.c

--- Some places in git use raw API opendir/readdir/closedir to traverse a directory recursively, which usually involves function recursion. Now that we have struct dir_iterator,we have to convert these to use the dir-iterator to simplify the code. Signed-off-by: Sushma Unnibhavi dir-iterator

[GSOC][PATCH 1/2] modified dir-iterator.c

--- Some places in git use raw API opendir/readdir/closedir to traverse a directory recursively, which usually involves function recursion. Now that we have struct dir_iterator,we have to convert these to use the dir-iterator to simplify the code. Signed-off-by: Sushma Unnibhavi dir-iterator

Re: [PATCH v13 18/27] stash: convert create to builtin

Hi Peff, On Thu, 7 Mar 2019, Jeff King wrote: > On Mon, Feb 25, 2019 at 11:16:22PM +, Thomas Gummerer wrote: > > > +static void add_pathspecs(struct argv_array *args, > > + struct pathspec ps) { > > Here and elsewhere in the series, I notice that we pass the pathspec > s

how can i "gc" or "prune" objects related to a deleted remote?

writing a short tutorial on how to add a remote and work with it and, as a final step, show how, if one is uninterested in the remote after all, one can simply delete it, but i also want to show how one can then prune or garbage collect the objects related to that remote, but i can't figure out

Re: [PATCH v2] line-log: suppress diff output with "-s"

Hi Peff, On Thu, 7 Mar 2019, Jeff King wrote: > When "-L" is in use, we ignore any diff output format that the user > provides to us, and just always print a patch (with extra context lines > covering the whole area of interest). It's not entirely clear what we > should do with all formats (e.g.,

Re: fast-import on existing branches

Hi Norbert, On Fri, Mar 8, 2019 at 2:51 AM Norbert Nemec wrote: > > Hi there, > > I've struggled for quite some time to sort out documented, intended and > actual behavior of git fast-import. Unless I'm completely mistaken, it seems > to be a straightforward bug, but if that is the case, I am r

Re: git reset error on Windows

Hi Adrian, On Thu, 7 Mar 2019, Adrian Godong wrote: > Windows 10, git version 2.21.0.windows.1 > > git reset tries to delete folder when last file is removed but failed > to do so if shell is in the deleted folder. > > Repro steps (powershell): > mkdir test > cd test > git init > mkdir dir > cd

New Ft. for Git : Allow resumable cloning of repositories.

Objective: Allow pause and resume functionality while cloning repositories. Below is a rough idea on how this may be achieved. 1) Create a repository_name.json file. 2) repository_name.json will be an index file containing list of all the files in the repository with default status being "False".

[PATCH 1/1] mingw: allow building with an MSYS2 runtime v3.x

From: Johannes Schindelin Recently the Git for Windows project started the upgrade process to a MSYS2 runtime version based on Cygwin v3.x. This has the very notable consequence that `$(uname -r)` no longer reports a version starting with "2", but a version with "3". That breaks our build, as d

[PATCH 0/1] mingw: fix uname -r test

In df5218b4c30b (config.mak.uname: support MSys2, 2016-01-13), I obviously made the assumption that calling uname -r in MSYS2 would always yield a version number starting with "2". That is incorrect, though, as uname -r reports the version of the Cygwin runtime on which the current MSYS2 runtime i

Re: [PATCH 0/2] stash: handle pathspec magic again

Hi Junio, On Fri, 8 Mar 2019, Junio C Hamano wrote: > "Johannes Schindelin via GitGitGadget" > writes: > > > It was reported in https://github.com/git-for-windows/git/issues/2037 that > > git stash -- ':(glob)**/*.testextension is broken. The problem is not even > > the stash operation itself,

Re: [PATCH v2] line-log: suppress diff output with "-s"

On Fri, Mar 08, 2019 at 04:38:44PM +0100, Johannes Schindelin wrote: > On Thu, 7 Mar 2019, Jeff King wrote: > > > When "-L" is in use, we ignore any diff output format that the user > > provides to us, and just always print a patch (with extra context lines > > covering the whole area of interest

Re: [PATCH 0/1] Drop last MakeMaker reference

Hi Junio, On Fri, 8 Mar 2019, Junio C Hamano wrote: > Johannes Schindelin writes: > > > On Sun, 3 Mar 2019, Junio C Hamano wrote: > > > >> "Johannes Schindelin via GitGitGadget" > >> writes: > >> > >> > Back when we stopped using MakeMaker, we forgot one reference... > >> > > >> > Johannes Sc

Re: [RFC PATCH 0/5] Fix some fast-import parsing issues

Hi, On Wed, Feb 20, 2019 at 2:58 PM Elijah Newren wrote: > > I found a few issues with parsing in fast-import (dating back to > I've cc'ed the relevant folks, and have a few patches that fix the > issue and I think make the parser more robust against future issues in > a way that I think is

RE: fast-import on existing branches

Thanks, Elijah, I had indeed missed that block about the ^0 handling. I still don't get why this awkward workaround is required. Why isn't that lookup done by default? Performance can't be the reason, since the same lookup is done lateron anyway, just as correctness check. The way I read the do

Re: New Ft. for Git : Allow resumable cloning of repositories.

> Objective: Allow pause and resume functionality while cloning repositories. > > Below is a rough idea on how this may be achieved. This is indeed a nice feature to have, and thanks for details of how this would be accomplished. > 1) Create a repository_name.json file. > 2) repository_name.json

Re: One failed self test on Fedora 29

Hi, Jeffrey Walton wrote: > Fedora 29, x86_64. One failed self test: > > *** t0021-conversion.sh *** [...] > not ok 13 - disable filter with empty override > # > # test_config_global filter.disable.smudge false && > # test_config_global filter.disable.clean false && >

Re: [PATCH v3 00/21] Add new command "switch"

On 08/03/2019 09:57, Nguyễn Thái Ngọc Duy wrote: [snip] > Range-diff dựa trên v2: > -: -- > 1: 949f3dd4fd git-checkout.txt: spell out --no-option > 1: 8358b9ca36 = 2: 1ddbbae3e2 git-checkout.txt: fix one syntax line > 2: 1686ccbf8d ! 3: b0cb2372db doc: document --overwrite-ig

Re: [PATCH v1 01/11] checkout: split part of it to new command 'restore'

Thanks for working on this; overall looks really good. I've got a few comments here and there on the wording and combinations of options... On Fri, Mar 8, 2019 at 2:17 AM Nguyễn Thái Ngọc Duy wrote: > +SYNOPSIS It might be worth adding some words somewhere to differentiate between `reset` and `

Re: [PATCH v2] line-log: suppress diff output with "-s"

Hi Peff, On Fri, 8 Mar 2019, Jeff King wrote: > On Fri, Mar 08, 2019 at 04:38:44PM +0100, Johannes Schindelin wrote: > > > On Thu, 7 Mar 2019, Jeff King wrote: > > > > > When "-L" is in use, we ignore any diff output format that the user > > > provides to us, and just always print a patch (with

[PATCH] upload-pack.c: fix a sparse 'NULL pointer' warning

Signed-off-by: Ramsay Jones --- Hi Jonathan, If you need to re-roll your 'jt/fetch-cdn-offload' branch, could you please squash this into the relevant patch (commit 0e821b4427 ("upload-pack: send part of packfile response as uri", 2019-02-23)). Thanks! ATB, Ramsay Jones upload-pack.c | 2 +

Re: [PATCH v5 02/10] add--helper: create builtin helper for interactive add

Hi Junio, On Thu, 21 Feb 2019, Junio C Hamano wrote: > "Daniel Ferreira via GitGitGadget" writes: > > > diff --git a/git.c b/git.c > > index 2dd588674f..cb42591f37 100644 > > --- a/git.c > > +++ b/git.c > > @@ -444,6 +444,7 @@ static int run_builtin(struct cmd_struct *p, int argc, > > const ch

Re: Bug: git for Windows spawning a lot of processes recursively

Hi Pierre, On Fri, 22 Feb 2019, Garcia, Pierre wrote: > I'd like to report an issue with git for Windows > > Git version 2.20.1 > Windows 7 x64 (Build 7601: Service Pack 1) > > > Issue: > When running from Git-bash (no

[PATCH v2 1/8] http: use --stdin when getting dumb HTTP pack

When Git fetches a pack using dumb HTTP, it reuses the server's name for the packfile (which incorporates a hash), which is different from the behavior of fetch-pack and receive-pack. A subsequent patch will allow downloading packs over HTTP(S) as part of a fetch. These downloads will not necessar

[PATCH v2 0/8] CDN offloading of fetch response

Here's my current progress - the only thing that is lacking is more tests, maybe, so I think it's ready for review. I wrote in version 1: > I know > that there are some implementation details that could be improved (e.g. > parallelization of the CDN downloads, starting CDN downloads *after* > clo

[PATCH v2 6/8] upload-pack: refactor reading of pack-objects out

Subsequent patches will change how the output of pack-objects is processed, so extract that processing into its own function. Currently, at most 1 character can be buffered (in the "buffered" local variable). One of those patches will require a larger buffer, so replace that "buffered" local varia

[PATCH v2 7/8] fetch-pack: support more than one pack lockfile

Whenever a fetch results in a packfile being downloaded, a .keep file is generated, so that the packfile can be preserved (from, say, a running "git repack") until refs are written referring to the contents of the packfile. In a subsequent patch, a successful fetch using protocol v2 may result in

[PATCH v2 2/8] http: improve documentation of http_pack_request

struct http_pack_request and the functions that use it will be modified in a subsequent patch. Using it is complicated (to use, call the initialization function, then set some but not all fields in the returned struct), so add some documentation to help future users. Signed-off-by: Jonathan Tan S

[PATCH v2 3/8] http-fetch: support fetching packfiles by URL

Teach http-fetch the ability to download packfiles directly, given a URL, and to verify them. The http_pack_request suite of functions have been modified to support a NULL target. When target is NULL, the given URL is downloaded directly instead of being treated as the root of a repository. Signe

[PATCH v2 8/8] upload-pack: send part of packfile response as uri

Teach upload-pack to send part of its packfile response as URIs. An administrator may configure a repository with one or more "uploadpack.blobpackfileuri" lines, each line containing an OID, a pack hash, and a URI. A client may configure fetch.uriprotocols to be a comma-separated list of protocols

[PATCH v2 5/8] Documentation: add Packfile URIs design doc

Signed-off-by: Jonathan Tan Signed-off-by: Junio C Hamano --- Documentation/technical/packfile-uri.txt | 78 Documentation/technical/protocol-v2.txt | 28 - 2 files changed, 105 insertions(+), 1 deletion(-) create mode 100644 Documentation/technical/packfile-ur

[PATCH v2 4/8] Documentation: order protocol v2 sections

The current C Git implementation expects Git servers to follow a specific order of sections when transmitting protocol v2 responses, but this is not explicit in the documentation. Make the order explicit. Signed-off-by: Jonathan Tan Signed-off-by: Junio C Hamano --- Documentation/technical/prot

bitmaps by default? [was: prune: use bitmaps for reachability traversal]

Jeff King wrote: > Pruning generally has to traverse the whole commit graph in order to > see which objects are reachable. This is the exact problem that > reachability bitmaps were meant to solve, so let's use them (if they're > available, of course). Perhaps this is good impetus for doing bitma