Re: What's cooking in git.git (Sep 2017, #06; Fri, 29)

On Fri, 2017-09-29 at 13:34 +0900, Junio C Hamano wrote: > > * ic/fix-filter-branch-to-handle-tag-without-tagger (2017-09-22) 4 > commits > (merged to 'next' on 2017-09-25 at c7550033df) > + filter-branch: use hash-object instead of mktag > + filter-branch: stash away ref map in a branch > +

Re: [PATCH v4] technical doc: add a design doc for hash function transition

Junio C Hamano writes: > Or perhaps we could. There is nothing that says a signed tag > created in the SHA-1 world must have the PGP/SHA-1 signature in the > NewHash payload---it could be split off of the object data and > stored in a local metadata cache, to be used only

Re: [Bug/Solution] Git hangs in compat/poll/poll.c on HPE NonStop

On 29/09/2017 00:47, Junio C Hamano wrote: > [jch: a patch that hopefully is applicable is attached at the end; > I'd appreciate input from Paolo, the contributor of the original > upstream] I wasn't involved in upstream commit d42461c3, but Linux is also always overwriting the revents output

[PATCH v16 2/6] bisect--helper: rewrite `check_term_format` shell function in C

Reimplement the `check_term_format` shell function in C and add a `--check-term-format` subcommand to `git bisect--helper` to call it from git-bisect.sh Using `--check-term-format` subcommand is a temporary measure to port shell function to C so as to use the existing test suite. As more

[PATCH v16 1/6] bisect--helper: use OPT_CMDMODE instead of OPT_BOOL

`--next-all` is meant to be used as a subcommand to support multiple "operation mode" though the current implementation does not contain any other subcommand along side with `--next-all` but further commits will include some more subcommands. Helped-by: Johannes Schindelin

[PATCH v16 3/6] bisect--helper: `write_terms` shell function in C

Reimplement the `write_terms` shell function in C and add a `write-terms` subcommand to `git bisect--helper` to call it from git-bisect.sh . Also remove the subcommand `--check-term-format` as it can now be called from inside the function write_terms() C implementation. Also `|| exit` is added

[PATCH v16 4/6] bisect--helper: `bisect_clean_state` shell function in C

Reimplement `bisect_clean_state` shell function in C and add a `bisect-clean-state` subcommand to `git bisect--helper` to call it from git-bisect.sh . Using `--bisect-clean-state` subcommand is a measure to port shell function to C so as to use the existing test suite. As more functions are

[PATCH v16 6/6] bisect--helper: `is_expected_rev` & `check_expected_revs` shell function in C

Reimplement `is_expected_rev` & `check_expected_revs` shell function in C and add a `--check-expected-revs` subcommand to `git bisect--helper` to call it from git-bisect.sh . Using `--check-expected-revs` subcommand is a temporary measure to port shell functions to C so as to use the existing

[PATCH v16 5/6] t6030: explicitly test for bisection cleanup

Add test to explicitly check that 'git bisect reset' is working as expected. This is already covered implicitly by the test suite. Mentored-by: Lars Schneider Mentored-by: Christian Couder Signed-off-by: Pranit Bauva

Re: [PATCH v4] technical doc: add a design doc for hash function transition

Jonathan Nieder writes: > This document describes what a transition to a new hash function for > Git would look like. Add it to Documentation/technical/ as the plan > of record so that future changes can be recorded as patches. > > Also-by: Brandon Williams

Re: [PATCH Outreachy] mru: use double-linked list from list.h

On Fri, Sep 29, 2017 at 12:42 AM, Jeff King wrote: > On Thu, Sep 28, 2017 at 08:38:39AM +, Olga Telezhnaya wrote: > >> diff --git a/packfile.c b/packfile.c >> index f69a5c8d607af..ae3b0b2e9c09a 100644 >> --- a/packfile.c >> +++ b/packfile.c >> @@ -876,6 +876,7 @@ void

Re: [PATCH Outreachy] mru: use double-linked list from list.h

On Fri, Sep 29, 2017 at 09:18:11AM +0200, Christian Couder wrote: > On Fri, Sep 29, 2017 at 12:42 AM, Jeff King wrote: > > On Thu, Sep 28, 2017 at 08:38:39AM +, Olga Telezhnaya wrote: > > > >> diff --git a/packfile.c b/packfile.c > >> index f69a5c8d607af..ae3b0b2e9c09a 100644

Re: [PATCH] fast-import: checkpoint: dump branches/tags/marks even if object_count==0

Eric Rannaud writes: > On Thu, Sep 28, 2017 at 8:51 PM, Junio C Hamano wrote: >> I think that your patch the last round that feeds fd#8 in the >> foreground (i.e. fully trusting that the caller is sensibly giving >> input that produces no output) is

Re: [PATCH] git-sh: Avoid sourcing scripts with git --exec-path

Hi all, Thanks for the fast feedback, I'll answer everyone in a single email if you don't mind. On Fri, Sep 29, 2017 at 5:48 AM, Jonathan Nieder wrote: snip > I wonder if we can make this so intuitive that it doesn't need > mentioning in CodingGuidelines. What if the test

[PATCH v6 0/3] Incremental rewrite of git-submodules

changes in v6: * The function get_submodule_displaypath() was modified for the case when get_super_prefix() returns a non-null value. The condition to check if the super-prefix ends with a '/' is removed. To accomodate this change appropriate value of super_prefix is passed instead in the

Re: What's cooking in git.git (Sep 2017, #03; Fri, 15)

Hi Junio, On Sat, 16 Sep 2017, Junio C Hamano wrote: > Johannes Schindelin writes: > > > On Fri, 15 Sep 2017, Junio C Hamano wrote: > > > >> -- > >> [Cooking] > >> > >> [...] > >> > >> *

Re: [PATCH Outreachy] mru: use double-linked list from list.h

On Fri, Sep 29, 2017 at 9:23 AM, Jeff King wrote: > On Fri, Sep 29, 2017 at 09:18:11AM +0200, Christian Couder wrote: > >> As we use the "prepare_packed_git_run_once" static, this function will >> only be called only once when packed_git_mru has not yet been >> initialized, so

Mr Neil Trotter

A donation of 1 million British Pounds to you in good faith

Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)

Hi Jonathan, On Tue, 19 Sep 2017, Jonathan Nieder wrote: > Johannes Schindelin wrote: > > > To relate that, you are using a plain text format that is not well > > defined and not structured, and certainly not machine-readable, for > > information that is crucial for project management. > > > >

[PATCH v6 2/3] submodule--helper: introduce for_each_listed_submodule()

Introduce function for_each_listed_submodule() and replace a loop in module_init() with a call to it. The new function will also be used in other parts of the system in later patches. Mentored-by: Christian Couder Mentored-by: Stefan Beller

[PATCH v6 3/3] submodule: port submodule subcommand 'status' from shell to C

This aims to make git-submodule 'status' a built-in. Hence, the function cmd_status() is ported from shell to C. This is done by introducing four functions: module_status(), submodule_status_cb(), submodule_status() and print_status(). The function module_status() acts as the front-end of the

[PATCH v6 1/3] submodule--helper: introduce get_submodule_displaypath()

Introduce function get_submodule_displaypath() to replace the code occurring in submodule_init() for generating displaypath of the submodule with a call to it. This new function will also be used in other parts of the system in later patches. Mentored-by: Christian Couder

[ANNOUNCE] tig-2.3.0

Hello, Really excited to release version 2.3.0 of Tig which brings several improvements to the rendering performance, new features like search/prompt history persistence, and important fixes to the graph rendering and emoji display. I'd like thank all contributors and Roland Walker and Sven

"man git-stash" explanation of "--include-untracked" and "--all" seems ambiguous

from the man page: "If the --include-untracked option is used, all untracked files are also stashed and then cleaned up with git clean, leaving the working directory in a very clean state. If the --all option is used instead ^^^

Re: [PATCH Outreachy] mru: use double-linked list from list.h

Hi everyone, Many thanks to all of you, I am interested in every opinion. Sorry that I wasn't in the discussion, unfortunately I got sick, that's why I skipped all the process. I want to reply to the main moments and also ask some questions. >> Simplify mru.c, mru.h and related code by reusing

Can I Trust You ??.

Dear Friend, Good day to you. With due respect, i apologize you for this sudden message, it was due to the urgency of this transaction made me to seek for your immediate assistance. I hope that you will not expose or betray this trust. I am Mr.Kevin Achimota, a banker with position of the

Re: What's cooking in git.git (Sep 2017, #06; Fri, 29)

Hi Junio, On 9/29/2017 12:34 AM, Junio C Hamano wrote: * ds/find-unique-abbrev-optim (2017-09-19) 4 commits - SQUASH??? - sha1_name: parse less while finding common prefix - sha1_name: unroll len loop in find_unique_abbrev_r() - sha1_name: create perf test for find_unique_abbrev()

RE: [PATCH v8 00/12] Fast git status via a file system watcher

> -Original Message- > From: Junio C Hamano [mailto:gits...@pobox.com] > Sent: Thursday, September 28, 2017 10:21 PM > To: Ben Peart > Cc: david.tur...@twosigma.com; ava...@gmail.com; > christian.cou...@gmail.com; git@vger.kernel.org; > johannes.schinde...@gmx.de;

Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)

Hi Nicolas, On Tue, 19 Sep 2017, Nicolas Morey-Chaisemartin wrote: > Le 19/09/2017 à 17:43, Johannes Schindelin a écrit : > > > > C'mon, don't *try* to misunderstand me. > > > > Of course there need to be updates as to the state of patch series. > > > > It's just that mails only go *so* far when

Your response is highly appreciated

Hello , I am specifically contacting you in respect of a business proposal that I have for you as you appear very relevant in the proposal. Please kindly reply back to me for further details. Waiting to hear from you. Regards, Mr.Adams Salem

Re: RFC v3: Another proposed hash function transition plan

Dear Johannes, if ever there was a SHA-2 competition, it must have been held inside NSA:-) But maybe you are confusing with the SHA-3 competition. In any case, when considering SHA-2 vs SHA-3 for usage in git, you may have a look at arguments we give in the following blogpost:

Re: [PATCH] clang-format: adjust line break penalties

Hi Dscho, Johannes Schindelin wrote: > Signed-off-by: Johannes Schindelin > --- > .clang-format | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) Well executed and well explained. Thank you. Reviewed-by: Jonathan Nieder

Re: [PATCH v16 1/6] bisect--helper: use OPT_CMDMODE instead of OPT_BOOL

Hi Pranit, On 09/29/2017 08:49 AM, Pranit Bauva wrote: > It has been a long time since this series appeared on the mailing list. > The previous version v15[1] is now split into many parts and I am > sending the first part right now, will focus on getting this merged and > then send out the next

Re: What's cooking in git.git (Sep 2017, #06; Fri, 29)

On Fri, Sep 29, 2017 at 6:08 AM, Derrick Stolee wrote: > Hi Junio, > > On 9/29/2017 12:34 AM, Junio C Hamano wrote: >> >> * ds/find-unique-abbrev-optim (2017-09-19) 4 commits >> - SQUASH??? >> - sha1_name: parse less while finding common prefix >> - sha1_name: unroll len

Re: [PATCH v4] technical doc: add a design doc for hash function transition

Junio C Hamano wrote: > Jonathan Nieder writes: >> This document describes what a transition to a new hash function for >> Git would look like. Add it to Documentation/technical/ as the plan >> of record so that future changes can be recorded as patches. >> >> Also-by:

Re: [PATCH 4/3] branch: fix "copy" to never touch HEAD

On Wed, Sep 27 2017, Junio C. Hamano jotted: > Ævar Arnfjörð Bjarmason writes: > >> I do think however that we also need to update the docs, the relevant >> origin/master...gitster/sd/branch-copy diff is currently: >> >> +The `-c` and `-C` options have the exact same

[PATCH] clang-format: adjust line break penalties

We really, really, really want to limit the columns to 80 per line: One of the few consistent style comments on the Git mailing list is that the lines should not have more than 80 columns/line (even if 79 columns/line would make more sense, given that the code is frequently viewed as diff, and

Re: RFC v3: Another proposed hash function transition plan

Hi Gilles, On Tue, 19 Sep 2017, Gilles Van Assche wrote: > On 19/09/17 00:16, Johannes Schindelin wrote: > >>> SHA-256 got much more cryptanalysis than SHA3-256 […]. > >> > >> I do not think this is true. > > > > Please read what I said again: SHA-256 got much more cryptanalysis > > than

Re: [PATCH v6 09/40] Add initial external odb support

On Wed, 27 Sep 2017 18:46:30 +0200 Christian Couder wrote: > I am ok to split the patch series, but I am not sure that 01/40 to > 09/40 is the right range for the first patch series. > I would say that 01/40 to 07/40 is better as it can be seen as a > separate

Re: [PATCH 00/18] Partial clone (from clone to lazy fetch in 18 patches)

Hi Jonathan, On Fri, 29 Sep 2017, Jonathan Tan wrote: > Jeff Hostetler has sent out some object-filtering patches [1] that is a > superset of the object-filtering functionality that I have (in the > pack-objects patches). I have gone for the minimal approach here, but if > his patches are

Re: [PATCH v2 3/9] protocol: introduce protocol extention mechanisms

On 09/27, Junio C Hamano wrote: > Junio C Hamano writes: > > >> +enum protocol_version determine_protocol_version_server(void) > >> +{ > >> + const char *git_protocol = getenv(GIT_PROTOCOL_ENVIRONMENT); > >> + enum protocol_version version = protocol_v0; > >> + > >> + if

Re: [PATCH v2 7/9] connect: tell server that the client understands v1

On 09/27, Junio C Hamano wrote: > Junio C Hamano writes: > > >> + # Client requested to use protocol v1 > >> + grep "version=1" log && > >> + # Server responded using protocol v1 > >> + grep "clone< version 1" log > > > > This looked a bit strange to check "clone< version

Re: [PATCH Outreachy] mru: use double-linked list from list.h

> About minor issues ( "tmp" vs "p2", variable scope, space indentation) > - fully agree, I will fix it. > ... > So finally I think that I need to fix that minor issues and that's > all. I forgot about leak. I also need to add checking in mru_clear. That's not beautiful solution but it works

Re: [PATCH v16 1/6] bisect--helper: use OPT_CMDMODE instead of OPT_BOOL

Hey Stephan, On Sat, Sep 30, 2017 at 12:24 AM, Stephan Beyer wrote: > > Hi Pranit, > > On 09/29/2017 08:49 AM, Pranit Bauva wrote: > > It has been a long time since this series appeared on the mailing list. > > The previous version v15[1] is now split into many parts and I am >

Re: [PATCH] oidmap: map with OID as key

On Thu, 28 Sep 2017 16:05:57 -0400 Jeff King wrote: > When I saw that you were implementing "oidset" in terms of "oidmap", I > was all ready to be crabby about this extra memory. But then I saw that > the implementation tries hard not to waste any memory. :) > > All of which is

Re: [PATCH 07/13] object-filter: common declarations for object filtering

On Thu, 28 Sep 2017 10:33:39 -0400 Jeff Hostetler wrote: > Maybe. What I have here now is the result of adding these arguments to > rev-list and pack-objects (in the current patch series), and also to > fetch-pack, fetch, clone, upload-pack, index-pack, and the transport

Re: [PATCH] clang-format: adjust line break penalties

On 09/29, Jonathan Nieder wrote: > Hi Dscho, > > Johannes Schindelin wrote: > > > Signed-off-by: Johannes Schindelin > > --- > > .clang-format | 12 ++-- > > 1 file changed, 6 insertions(+), 6 deletions(-) > > Well executed and well explained. Thank you. >

[PATCH 16/18] clone: configure blobmaxbytes in created repos

Teach clone to configure blobmaxbytes in any repos that it generates when the --blob-max-bytes parameter is set. Also teach fetch to use this parameter. Signed-off-by: Jonathan Tan --- builtin/clone.c | 1 + builtin/fetch.c | 4 remote.c

[PATCH 05/18] index-pack: refactor writing of .keep files

In a subsequent commit, index-pack will be taught to write ".promisor" files which are similar to the ".keep" files it knows how to write. Refactor the writing of ".keep" files, so that the implementation of writing ".promisor" files becomes easier. Signed-off-by: Jonathan Tan

[PATCH 09/18] gc: do not repack promisor packfiles

Teach gc to stop traversal at promisor objects, and to leave promisor packfiles alone. This has the effect of only repacking non-promisor packfiles, and preserves the distinction between promisor packfiles and non-promisor packfiles. Signed-off-by: Jonathan Tan ---

[PATCH 14/18] fetch: support excluding large blobs

Teach fetch to support excluding large blobs through a blob-max-bytes parameter. This is only allowed for the remote configured in extensions.partialclone. Signed-off-by: Jonathan Tan --- builtin/fetch.c | 22 -- connected.c | 1 +

[PATCH 08/18] rev-list: support termination at promisor objects

Teach rev-list to support termination of an object traversal at any object from a promisor remote (whether one that the local repo also has, or one that the local repo knows about because it has another promisor object that references it). This will be used subsequently in gc and in the

[PATCH 04/18] fsck: support promisor objects as CLI argument

Teach fsck to not treat missing promisor objects provided on the CLI as an error when extensions.partialclone is set. Signed-off-by: Jonathan Tan --- builtin/fsck.c | 2 ++ t/t0410-partial-clone.sh | 13 + 2 files changed, 15 insertions(+) diff

[PATCH 06/18] introduce fetch-object: fetch one promisor object

Introduce fetch-object, providing the ability to fetch one object from a promisor remote. This uses fetch-pack. To do this, the transport mechanism has been updated with 2 flags, "from-promisor" to indicate that the resulting pack comes from a promisor remote (and thus should be annotated as such

[PATCH 17/18] unpack-trees: batch fetching of missing blobs

When running checkout, first prefetch all blobs that are to be updated but are missing. This means that only one pack is downloaded during such operations, instead of one per missing blob. This operates only on the blob level - if a repository has a missing tree, they are still fetched one at a

[PATCH 12/18] fetch-pack: support excluding large blobs

Teach fetch-pack and upload-pack to support excluding large blobs through a blob-max-bytes parameter. Signed-off-by: Jonathan Tan --- Documentation/technical/pack-protocol.txt | 9 Documentation/technical/protocol-capabilities.txt | 7 ++

[PATCH 18/18] fetch-pack: restore save_commit_buffer after use

In fetch-pack, the global variable save_commit_buffer is set to 0, but not restored to its original value after use. In particular, if show_log() (in log-tree.c) is invoked after fetch_pack() in the same process, show_log() will return before printing out the commit message (because the

[PATCH 15/18] clone: support excluding large blobs

Teach clone to support excluding large blobs through a blob-max-bytes parameter. Signed-off-by: Jonathan Tan --- builtin/clone.c | 23 +-- t/t5601-clone.sh | 49 + 2 files changed, 70 insertions(+), 2

[PATCH 11/18] pack-objects: support --blob-max-bytes

As part of an effort to improve Git support for very large repositories in which clients typically have only a subset of all version-controlled blobs, teach pack-objects to support --blob-max-bytes, packing only blobs not exceeding that size unless the blob corresponds to a file whose name starts

[PATCH 02/18] fsck: support refs pointing to promisor objects

Teach fsck to not treat refs referring to missing promisor objects as an error when extensions.partialclone is set. For the purposes of warning about no default refs, such refs are still treated as legitimate refs. Signed-off-by: Jonathan Tan --- builtin/fsck.c

[PATCH 10/18] pack-objects: rename want_.* to ignore_.*

Currently, in pack_objects, add_object_entry() distinguishes between 2 types of non-preferred-base objects: (1) objects that should not be in "to_pack" because an option like --local or --honor-pack-keep is set (2) objects that should be in "to_pack" A subsequent commit will teach

[PATCH 07/18] sha1_file: support lazily fetching missing objects

Teach sha1_file to fetch objects from the remote configured in extensions.partialClone whenever an object is requested but missing. The fetching of objects can be suppressed through a global variable. This is used by fsck and index-pack. However, by default, such fetching is not suppressed. This

[PATCH 03/18] fsck: support referenced promisor objects

Teach fsck to not treat missing promisor objects indirectly pointed to by refs as an error when extensions.partialclone is set. Signed-off-by: Jonathan Tan --- builtin/fsck.c | 11 +++ t/t0410-partial-clone.sh | 23 +++ 2 files

[PATCH 13/18] fetch: refactor calculation of remote list

Separate out the calculation of remotes to be fetched from and the actual fetching. This will allow us to include an additional step before the actual fetching in a subsequent commit. Signed-off-by: Jonathan Tan --- builtin/fetch.c | 14 -- 1 file changed,

Re: [PATCH] oidmap: map with OID as key

On Fri, Sep 29, 2017 at 12:04:56PM -0700, Jonathan Tan wrote: > > So depending how you count it, we're wasting between 28% (sha1 and no > > extra hash) and 16% (sha256 plus reusing hashmap). That's not great, but > > it's probably not breaking the bank. > > Hmm...how did you get the 16% figure?

Re: RFC: Design and code of partial clones (now, missing commits and trees OK)

On Tue, 26 Sep 2017 17:26:33 +0200 Michael Haggerty wrote: > Maybe naming has been discussed at length before, and I am jumping into > a long-settled topic. And admittedly this is bikeshedding. > > But I find these names obscure, even as a developer. And terms like this >

[PATCH 01/18] fsck: introduce partialclone extension

Currently, Git does not support repos with very large numbers of objects or repos that wish to minimize manipulation of certain blobs (for example, because they are very large) very well, even if the user operates mostly on part of the repo, because Git is designed on the assumption that every

[PATCH 00/18] Partial clone (from clone to lazy fetch in 18 patches)

These patches are also available online: https://github.com/jonathantanmy/git/commits/partialclone3 (I've announced it in another e-mail, but am now sending the patches to the mailing list too.) Here's an update of my work so far. Notable features: - These 18 patches allow a user to clone with

Re: [PATCH] gitk: expand $config_file_tmp before reporting to user

Well something like this is not paying _Paul_ enough for what he gave to The People, so I do not think there is worth trying. > On 28 Sep 2017, at 06:37, Junio C Hamano wrote: > > Max Kirillov writes: > >> Tilda-based path may confise some users. First,

Re: [idea] File history tracking hints

Hi Philip, On Fri, 15 Sep 2017, Philip Oakley wrote: > From: "Johannes Schindelin" > > > In light of such experiences, I have to admit that the notion that the > > rename detection can always be improved in hindsight puts quite a bit of > > insult to injury for those

RE: Is finalize_object_file in sha1_file.c handling errno from "rename" correctly?

Hi, On Fri, 15 Sep 2017, Wesley Smith wrote: > Thanks for your response. I'm glad to see that you've been able to > understand the problem. I'm working with the Windows git team to properly > return EACCESS when "rename" fails due to access permissions, but it also > sounds like there will

Re: [PATCH] oidmap: map with OID as key

On Fri, Sep 29, 2017 at 11:43:57PM +0200, Johannes Schindelin wrote: > On Thu, 28 Sep 2017, Jeff King wrote: > > > If you're planning on using an oidset to mark every object in a > > 100-million-object monorepo, we'd probably care more. But I'd venture to > > say that any scheme which involves

Re: [PATCH Outreachy] mru: use double-linked list from list.h

On Fri, Sep 29, 2017 at 07:08:28PM +0300, Оля Тележная wrote: > Many thanks to all of you, I am interested in every opinion. Sorry > that I wasn't in the discussion, unfortunately I got sick, that's why > I skipped all the process. No problem. It's often reasonable to let review comments come in

Re: [PATCH Outreachy] mru: use double-linked list from list.h

On Fri, Sep 29, 2017 at 11:38:27PM +0300, Оля Тележная wrote: > > About minor issues ( "tmp" vs "p2", variable scope, space indentation) > > - fully agree, I will fix it. > > ... > > So finally I think that I need to fix that minor issues and that's > > all. > > I forgot about leak. I also need

Re: RFC v3: Another proposed hash function transition plan

Hi Joan, On Fri, 29 Sep 2017, Joan Daemen wrote: > if ever there was a SHA-2 competition, it must have been held inside NSA:-) Oops. My bad, I indeed got confused about that, as you suggest below (I actually thought of the AES competition, but that was obviously not about SHA-2). Sorry. > But

Re: [PATCH] clang-format: adjust line break penalties

Hi, On 09/29/2017 08:40 PM, Jonathan Nieder wrote: > Going forward, is there an easy way to preview the effect of this kind > of change (e.g., to run "make style" on the entire codebase so as to be > able to compare the result with two different versions of > .clang-format)? I just ran

Re: [PATCH] clang-format: adjust line break penalties

Stephan Beyer wrote: > On 09/29/2017 08:40 PM, Jonathan Nieder wrote: >> Going forward, is there an easy way to preview the effect of this kind >> of change (e.g., to run "make style" on the entire codebase so as to be >> able to compare the result with two different versions of >>

[PATCH v2] oidmap: map with OID as key

This is similar to using the hashmap in hashmap.c, but with an easier-to-use API. In particular, custom entry comparisons no longer need to be written, and lookups can be done without constructing a temporary entry structure. This is implemented as a thin wrapper over the hashmap API. In

Re: [PATCH] oidmap: map with OID as key

Hi Peff, On Thu, 28 Sep 2017, Jeff King wrote: > If you're planning on using an oidset to mark every object in a > 100-million-object monorepo, we'd probably care more. But I'd venture to > say that any scheme which involves generating that hash table on the fly > is doing it wrong. At at that

Re: [PATCH Outreachy] mru: use double-linked list from list.h

Jeff King writes: > Yes, I think we could just call this "list_move_to_front()" or > something. The fact that it's operating on a list called > "packed_git_mru" is probably sufficient to make it clear that the > purpose is managing recentness. I earlier said I wasn't sure, but I