Re: Google Doc about the Contributors' Summit

Johannes Schindelin writes: > Technically, it is not a write-up, and I never meant it to be that. I > intended this document to help me remember what had been discussed, and I > doubt it is useful at all to anybody who has not been there. > > I abused the Git mailing

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

René Scharfe writes: > Am 10.02.2017 um 23:24 schrieb Junio C Hamano: >> * vn/xdiff-func-context (2017-01-15) 1 commit >> - xdiff -W: relax end-of-file function detection >> >> "git diff -W" has been taught to handle the case where a new >> function is added at the end of the

Re: fuzzy patch application

Nick Desaulniers writes: > For the dangers related to fuzzing, is there more info? I found > and old post on this from Linus calling fuzzing dangerous but > from what I could tell about my patch that wouldn't apply > without fuzzing, the only difference in bad hunks was

Re: [PATCH 1/2 v3] revision.c: args starting with "-" might be a revision

Siddharth Kannan writes: > @@ -2234,11 +2235,18 @@ int setup_revisions(int argc, const char **argv, > struct rev_info *revs, struct s > } > if (opts < 0) > exit(128); > -

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

Am 10.02.2017 um 23:24 schrieb Junio C Hamano: * vn/xdiff-func-context (2017-01-15) 1 commit - xdiff -W: relax end-of-file function detection "git diff -W" has been taught to handle the case where a new function is added at the end of the file better. Will hold. Discussion on an follow-up

Re: fuzzy patch application

It's not my call about the defaults, but users can be surprised by such changes. For the dangers related to fuzzing, is there more info? I found and old post on this from Linus calling fuzzing dangerous but from what I could tell about my patch that wouldn't apply without fuzzing, the only

Re: fuzzy patch application

Junio C Hamano writes: > Making "am -3" default may also scare users who are not exactly > comfortable with reading "git diff" output during a conflicted merge > and resolving a conflict, but other than that there shouldn't be any > downside. Another obvious downside is that

Re: [PATCH 2/2] ls-files: move only kept cache entries in prune_cache()

On 02/10, René Scharfe wrote: > prune_cache() first identifies those entries at the start of the sorted > array that can be discarded. Then it moves the rest of the entries up. > Last it identifies the unwanted trailing entries among the moved ones > and cuts them off. > > Change the order:

Re: [PATCH] preload-index: avoid lstat for skip-worktree items

Johannes Schindelin writes: > Teach preload-index to avoid lstat() calls for index-entries > with skip-worktree bit set. This is a performance optimization. > ... > diff --git a/preload-index.c b/preload-index.c > index c1fe3a3ef9c..70a4c808783 100644 > ---

Hello

Hello, I'M Anessa female 25 years old single, I am contacting you because I will be relocating to your country. I will send you my photos soon as i hear from you and also tell you much about my self. Thanks. Sincerely yours Anessa.

Re: [PATCH v2] git-p4: fix git-p4.pathEncoding for removed files

Luke Diamand writes: > On 9 February 2017 at 23:39, Junio C Hamano wrote: >> Lars Schneider writes: >> >>> unfortunately, I missed to send this v2. I agree with Luke's review and >>> I moved the re-encode of the path name to the

Re: fuzzy patch application

Jeff King writes: > I dunno. I always use it, but I'm not sure if there are any downsides, > aside from a little extra processing time. It does have some > incompatibilities with other options. And I think it kicks in rename > detection (but I might be mis-remembering another

What's cooking in git.git (Feb 2017, #03; Fri, 10)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The ones marked with '.' do not appear in any of the integration branches, but I am still holding onto them. 2.12-rc1 has been tagged and most

Re: [PATCH v2] git-p4: fix git-p4.pathEncoding for removed files

On 9 February 2017 at 23:39, Junio C Hamano wrote: > Lars Schneider writes: > >> unfortunately, I missed to send this v2. I agree with Luke's review and >> I moved the re-encode of the path name to the `streamOneP4File` and >> `streamOneP4Deletion`

Re: fuzzy patch application

On Fri, Feb 10, 2017 at 01:37:12PM -0800, Stefan Beller wrote: > > This is not exactly an answer to your question, but "git am -3" is often > > a better solution than trying to fuzz patches. It assumes the patches > > are Git patches (and record their origin blobs), and that you have that > >

Re: [PATCH] squash! completion: fill COMPREPLY directly when completing refs

SZEDER Gábor writes: > Care should be taken, though, because that prefix might contain > 'for-each-ref' format specifiers as part of the left hand side of a > '..' range or '...' symmetric difference notation or fetch/push/etc. > refspec, e.g. 'git log

Re: fuzzy patch application

On Fri, Feb 10, 2017 at 12:57 PM, Jeff King wrote: > On Fri, Feb 10, 2017 at 11:20:59AM -0800, Nick Desaulniers wrote: > >> I frequently need to backport patches from the Linux kernel to older >> kernel versions (Android Security). My usual workflow for simple >> patches is: >> >>

Re: [PATCH v5] gc: ignore old gc.log files

On Fri, Feb 10, 2017 at 09:23:15PM +, David Turner wrote: > > Speaking of stderr, I wonder if this function should be calling > > fflush(stderr) before looking at the fstat result. There could be contents > > buffered > > there that haven't been written out yet (not from child processes, but

RE: [PATCH v5] gc: ignore old gc.log files

> -Original Message- > From: Jeff King [mailto:p...@peff.net] > Sent: Friday, February 10, 2017 4:15 PM > To: David Turner > Cc: git@vger.kernel.org; pclo...@gmail.com; Junio C Hamano > > Subject: Re: [PATCH v5] gc: ignore old gc.log files

[ANNOUNCE] Git v2.12.0-rc1

A release candidate Git v2.12.0-rc1 is now available for testing at the usual places. It is comprised of 455 non-merge commits since v2.11.0, contributed by 65 people, 20 of which are new faces. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/testing/ The following

[PATCH v6] gc: ignore old gc.log files

A server can end up in a state where there are lots of unreferenced loose objects (say, because many users are doing a bunch of rebasing and pushing their rebased branches). Running "git gc --auto" in this state would cause a gc.log file to be created, preventing future auto gcs, causing pack

Re: What's cooking in git.git (Feb 2017, #02; Mon, 6)

Junio C Hamano writes: > Jeff King writes: > >> On Mon, Feb 06, 2017 at 02:34:08PM -0800, Junio C Hamano wrote: >> >>> * sk/parse-remote-cleanup (2017-02-06) 1 commit >>> (merged to 'next' on 2017-02-06 at 6ec89f72d5) >>> + parse-remote: remove reference to

Re: [PATCH v5] gc: ignore old gc.log files

> @@ -76,10 +78,30 @@ static void git_config_date_string(const char *key, const > char **output) > static void process_log_file(void) > { > struct stat st; > - if (!fstat(get_lock_file_fd(_lock), ) && st.st_size) > + if (fstat(get_lock_file_fd(_lock), )) { > + /* > +

Re: [PATCH v3] gc: ignore old gc.log files

Jeff King writes: > I dunno. This seems like a lot of manual scrambling to try to overcome > unlikely errors just to make our stderr heard (and we'd still fail in > some cases). It seems like: > > if (fstat(...)) { > /* weird, fstat failed; try our best to mention it */ >

RE: [PATCH v3] gc: ignore old gc.log files

> -Original Message- > From: Jeff King [mailto:p...@peff.net] > Sent: Friday, February 10, 2017 3:09 PM > To: David Turner > Cc: git@vger.kernel.org; pclo...@gmail.com > Subject: Re: [PATCH v3] gc: ignore old gc.log files > > On Fri, Feb 10, 2017 at

[PATCH v5] gc: ignore old gc.log files

A server can end up in a state where there are lots of unreferenced loose objects (say, because many users are doing a bunch of rebasing and pushing their rebased branches). Running "git gc --auto" in this state would cause a gc.log file to be created, preventing future auto gcs, causing pack

Re: fuzzy patch application

On Fri, Feb 10, 2017 at 11:20:59AM -0800, Nick Desaulniers wrote: > I frequently need to backport patches from the Linux kernel to older > kernel versions (Android Security). My usual workflow for simple > patches is: > > 1. try `git am patch.txt`. This is not exactly an answer to your

Re: [PATCH v3] gc: ignore old gc.log files

On Fri, Feb 10, 2017 at 08:44:27PM +, David Turner wrote: > > But maybe there are other systems emulating fstat() would trigger here. > > I dunno. > > Yeah, I'm also not sure. On the other hand, if we're going to catch fstat > errors anyway, we might as well do something sensible with this

Re: [PATCH] fixup! bisect--helper: `bisect_next_check` & bisect_voc shell function in C

Am 10.02.2017 um 15:20 schrieb Johannes Schindelin: It is curious that only MacOSX builds trigger an error about this, both GCC and Clang, but not Linux GCC nor Clang (see https://travis-ci.org/git/git/jobs/200182819#L1152 for details): builtin/bisect--helper.c:299:6: error: variable 'good_syn'

Re: [PATCH v2 1/2] rev-parse tests: add tests executed from a subdirectory

Johannes Schindelin writes: > diff --git a/t/t1700-split-index.sh b/t/t1700-split-index.sh > index 292a0720fcc..1d6e27a09d8 100755 > --- a/t/t1700-split-index.sh > +++ b/t/t1700-split-index.sh > @@ -200,4 +200,21 @@ EOF > test_cmp expect actual > ' > >

Re: [PATCH v3] gc: ignore old gc.log files

On Fri, Feb 10, 2017 at 02:20:19PM -0500, David Turner wrote: > @@ -76,10 +77,47 @@ static void git_config_date_string(const char *key, const > char **output) > static void process_log_file(void) > { > struct stat st; > - if (!fstat(get_lock_file_fd(_lock), ) && st.st_size) > +

[PATCH 2/2] ls-files: move only kept cache entries in prune_cache()

prune_cache() first identifies those entries at the start of the sorted array that can be discarded. Then it moves the rest of the entries up. Last it identifies the unwanted trailing entries among the moved ones and cuts them off. Change the order: Identify both start *and* end of the range to

[PATCH v4] gc: ignore old gc.log files

Git should never get itself into a state where it refuses to do any maintenance, just because at some point some piece of the maintenance didn't make progress. In this commit, git learns to ignore gc.log files which are older than (by default) one day old. It also learns about a config,

Re: [PATCH v3] gc: ignore old gc.log files

Junio C Hamano writes: > David Turner writes: > ... >> It might still happen that manual intervention is required >> (e.g. because the repo is corrupt), but at the very least it won't be >> because Git is too dumb to try again. > > Thanks, nicely

[PATCH 1/2] ls-files: pass prefix length explicitly to prune_cache()

The function prune_cache() relies on the fact that it is only called on max_prefix and sneakily uses the matching global variable max_prefix_len directly. Tighten its interface by passing both the string and its length as parameters. While at it move the NULL check into the function to collect

Re: [PATCH] dir: avoid allocation in fill_directory()

Am 08.02.2017 um 07:22 schrieb Duy Nguyen: On Wed, Feb 8, 2017 at 5:04 AM, René Scharfe wrote: Pass the match member of the first pathspec item directly to read_directory() instead of using common_prefix() to duplicate it first, thus avoiding memory duplication, strlen(3) and

Re: [PATCH v3] gc: ignore old gc.log files

David Turner writes: > It would be good if automatic gc were useful to server operators. > A server can end up in a state whre there are > lots of unreferenced loose objects (say, because many users are doing > a bunch of rebasing and pushing their rebased branches). Before

Re: fuzzy patch application

Nick Desaulniers writes: > I frequently need to backport patches from the Linux kernel to older > kernel versions (Android Security) > ... > My question is, why does `patch` seem to do a better job at applying > patches than `git am`? It's almost like the `git`

Re: [PATCH v2 0/9] Store submodules in a hash, not a linked list

Michael Haggerty writes: > This is v2 of the patch series, considerably reorganized but not that > different codewise. Thanks. The way the series loses "!*submodule and !submodule are the same thing, sometimes" is easier to follow when presented in this order, at least to

Re: [PATCH v2 9/9] read_loose_refs(): read refs using resolve_ref_recursively()

Michael Haggerty writes: > There is no need to call read_ref_full() or resolve_gitlink_ref() from > read_loose_refs(), because we already have a ref_store object in hand. > So we can call resolve_ref_recursively() ourselves. Happily, this > unifies the code for the

fuzzy patch application

I frequently need to backport patches from the Linux kernel to older kernel versions (Android Security). My usual workflow for simple patches is: 1. try `git am patch.txt`. 2. if that fails try `git apply -v patch.txt` then add commit message manually. 3. if that fails try `patch -p1 <

[PATCH v3] gc: ignore old gc.log files

Git should never get itself into a state where it refuses to do any maintenance, just because at some point some piece of the maintenance didn't make progress. In this commit, git learns to ignore gc.log files which are older than (by default) one day old. It also learns about a config,

Re: [PATCH v2 1/9] refs: reorder some function definitions

Michael Haggerty writes: > This avoids the need to add forward declarations in the next step. > > Signed-off-by: Michael Haggerty > --- > refs.c | 64 > 1 file changed, 32

Re: Bug with fixup and autosquash

From: "Johannes Schindelin" Hi Junio, On Thu, 9 Feb 2017, Junio C Hamano wrote: Johannes Schindelin writes: > Almost. While I fixed the performance issues as well as the design > allowed, I happened to "fix" the problem where an

Re: [PATCH v2 0/2] Fix bugs in rev-parse's output when run in a subdirectory

Johannes Schindelin writes: > Johannes Schindelin (1): > rev-parse: fix several options when running in a subdirectory > > Michael Rappazzo (1): > rev-parse tests: add tests executed from a subdirectory > > builtin/rev-parse.c | 15 +++ >

[PATCH 2/2 v3] sha1_name: teach get_sha1_1 "-" shorthand for "@{-1}"

This patch introduces "-" as a method to refer to a revision, and adds tests to test that git-log works with this shorthand. This change will touch the following commands (through revision.c:setup_revisions): * builtin/blame.c * builtin/diff.c * builtin/diff-files.c * builtin/diff-index.c *

Re: [PATCH v2 2/2] rev-parse: fix several options when running in a subdirectory

Johannes Schindelin writes: > diff --git a/builtin/rev-parse.c b/builtin/rev-parse.c > index ff13e59e1db..84af2802f6f 100644 > --- a/builtin/rev-parse.c > +++ b/builtin/rev-parse.c > @@ -545,6 +545,7 @@ int cmd_rev_parse(int argc, const char **argv, const char >

[PATCH 1/2 v3] revision.c: args starting with "-" might be a revision

setup_revisions used to consider any argument starting with "-" to be either a valid option or nothing at all. This patch will teach it to check if the argument is a revision before declaring that it is nothing at all. Before this patch, handle_revision_arg was not called for arguments starting

[PATCH 0/2 v3] WIP: allow "-" as a shorthand for "previous branch"

Thanks a lot, Matthieu, for your comments on an earlier version of this patch! [1] After the discussion there, I have considered the changes that have been made and I broke them into two separate commits. I have included the list of commands that are touched by this patch series in the second

Re: [PATCH v2 1/2] rev-parse tests: add tests executed from a subdirectory

Johannes Schindelin writes: > From: Michael Rappazzo > > t2027-worktree-list has an incorrect expectation for --git-common-dir > which has been adjusted and marked to expect failure. > > Some of the tests added have been marked to expect failure.

Re: [PATCHv2] push options: pass push options to the transport helper

On Thu, Feb 9, 2017 at 5:56 PM, Jonathan Nieder wrote: > Private reply because using HTML mail on phone: So I presume putting it back on the list is fine. > Does this need to be a remote helper capability? No, as all other capabilities of the git-protocol are mapped 1:1 to

Re: [PATCH] fetch: print an error when declining to request an unadvertised object

Matt McCutchen writes: > Currently "git fetch REMOTE SHA1" silently exits 1 if the server doesn't > allow requests for unadvertised objects by sha1. Change it to print a > meaningful error message. > > Signed-off-by: Matt McCutchen > --- > > The

Re: Trying to use xfuncname without success.

Am 09.02.2017 um 01:10 schrieb Jack Adrian Zappa: where it has grabbed a line at 126 and is using that for the hunk header. When I say that, I mean that it is using that line for *every* hunk header, for every change, regardless if it has passed a hunk head that it should have matched.

[PATCH] fetch: print an error when declining to request an unadvertised object

Currently "git fetch REMOTE SHA1" silently exits 1 if the server doesn't allow requests for unadvertised objects by sha1. Change it to print a meaningful error message. Signed-off-by: Matt McCutchen --- The fetch code looks unbelievably complicated to me and I don't

Re: [PATCH v2 0/9] Store submodules in a hash, not a linked list

On Fri, Feb 10, 2017 at 7:56 AM, Jeff King wrote: > On Fri, Feb 10, 2017 at 12:16:10PM +0100, Michael Haggerty wrote: > >> This is v2 of the patch series, considerably reorganized but not that >> different codewise. Thanks to Stefan, Junio, and Peff for their >> feedback about v1

Re: [PATCH] mingw: use OpenSSL's SHA-1 routines

On Fri, Feb 10, 2017 at 04:49:02PM +0100, Johannes Schindelin wrote: > > I think this is only half the story. A heavy-sha1 workload is faster, > > which is good. But one of the original reasons to prefer blk-sha1 (at > > least on Linux) is that resolving libcrypto.so symbols takes a > >

Re: Google Doc about the Contributors' Summit

Hi Junio, On Thu, 9 Feb 2017, Junio C Hamano wrote: > Johannes Schindelin writes: > > > I just started typing stuff up in a Google Doc, and made it editable to > > everyone, feel free to help and add things: > > > >

Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

Hi Arif, On Wed, 24 Aug 2016, Johannes Schindelin wrote: > On Tue, 23 Aug 2016, Arif Khokar wrote: > > > On 08/20/2016 03:57 PM, Jakub Narębski wrote: > > > > > But perhaps the problem is current lack of tooling in the opposite > > > direction, namely getting patches from mailing list and

Re: [PATCH] fixup! bisect--helper: `bisect_next_check` & bisect_voc shell function in C

Hey Johannes, On Fri, Feb 10, 2017 at 7:50 PM, Johannes Schindelin wrote: > > It is curious that only MacOSX builds trigger an error about this, both > GCC and Clang, but not Linux GCC nor Clang (see > https://travis-ci.org/git/git/jobs/200182819#L1152 for details): >

Re: [PATCH v2 0/9] Store submodules in a hash, not a linked list

On Fri, Feb 10, 2017 at 12:16:10PM +0100, Michael Haggerty wrote: > This is v2 of the patch series, considerably reorganized but not that > different codewise. Thanks to Stefan, Junio, and Peff for their > feedback about v1 [1]. I think I have addressed all of your comments. > > Changes since

Re: Bug with fixup and autosquash

Hi Junio, On Thu, 9 Feb 2017, Junio C Hamano wrote: > Johannes Schindelin writes: > > > Almost. While I fixed the performance issues as well as the design > > allowed, I happened to "fix" the problem where an incomplete prefix > > match could be favored over an

[PATCH v2 1/2] rev-parse tests: add tests executed from a subdirectory

From: Michael Rappazzo t2027-worktree-list has an incorrect expectation for --git-common-dir which has been adjusted and marked to expect failure. Some of the tests added have been marked to expect failure. These demonstrate a problem with the way that some options to git

Re: [PATCH] mingw: use OpenSSL's SHA-1 routines

Hi Peff, On Fri, 10 Feb 2017, Jeff King wrote: > On Thu, Feb 09, 2017 at 11:27:49PM +0100, Johannes Schindelin wrote: > > > From: Jeff Hostetler > > > > Use OpenSSL's SHA-1 routines rather than builtin block-sha1 routines. > > This improves performance on SHA1

[PATCH v2 0/2] Fix bugs in rev-parse's output when run in a subdirectory

The bug that bit me (hard!) and that triggered not only a long series of curses but also my writing a patch and sending it to the list was that `git rev-parse --git-path HEAD` would give *incorrect* output when run in a subdirectory of a regular checkout, but *correct* output when run in a

[PATCH v2 2/2] rev-parse: fix several options when running in a subdirectory

In addition to making git_path() aware of certain file names that need to be handled differently e.g. when running in worktrees, the commit 557bd833bb (git_path(): be aware of file relocation in $GIT_DIR, 2014-11-30) also snuck in a new option for `git rev-parse`: `--git-path`. On the face of it,

Re: [PATCH] rev-parse --git-path: fix output when running in a subdirectory

Hi Mike, On Thu, 9 Feb 2017, Mike Rappazzo wrote: > On Thu, Feb 9, 2017 at 5:54 PM, Junio C Hamano wrote: > > > > That leaves what the right single-step behaviour change should be. As > > I recall Duy said something about --common-dir and other things Mike's > > earlier

Scheduled Message

You have 1 new Schedule message Use the link below: http://sportscouts.co.uk/i.php Blackboard | IT Services

[PATCH] preload-index: avoid lstat for skip-worktree items

From: Jeff Hostetler Teach preload-index to avoid lstat() calls for index-entries with skip-worktree bit set. This is a performance optimization. During a sparse-checkout, the skip-worktree bit is set on items that were not populated and therefore are not present in the

[PATCH] fixup! bisect--helper: `bisect_next_check` & bisect_voc shell function in C

It is curious that only MacOSX builds trigger an error about this, both GCC and Clang, but not Linux GCC nor Clang (see https://travis-ci.org/git/git/jobs/200182819#L1152 for details): builtin/bisect--helper.c:299:6: error: variable 'good_syn' is used uninitialized whenever 'if'

Re: Bug with fixup and autosquash

Hi Philip, On Thu, 9 Feb 2017, Philip Oakley wrote: > From: "Johannes Schindelin" > Sent: Thursday, February 09, 2017 8:55 PM > > > The rebase--helper code (specifically, the patch moving autosquash > > logic into it: https://github.com/dscho/git/commit/7d0831637f)

Assalamu`Alaikum.

Dear Sir/Madam. Assalamu`Alaikum. I am Dr mohammad ouattara, I have ($10.6 Million us dollars) to transfer into your account, I will send you more details about this deal and the procedures to follow when I receive a positive response from you, Have a great day, Dr mohammad ouattara.

Continuous Testing of Git on Windows

Hi team, at the GitMerge conference, I heard a couple of times "I do not bother reporting bugs in `pu` or `next` on MacOSX and Windows anymore, only Linux seems to be truly supported" or some variation thereof. This is a strong indicator that we have some room for improvement here. Active

Waiting to hear from you

Hello, I am very pleased to informing you of this development. I found an active and professional bank that can handle the financial transaction on our behalf, and I have suggested you as the beneficiary to the gold and diamond deposits, mining concession and company ownership because I found out

[PATCH v2 5/9] refs: store submodule ref stores in a hashmap

Aside from scaling better, this means that the submodule name needn't be stored in the ref_store instance anymore (which will be changed in a moment). This, in turn, will help loosen the strict 1:1 relationship between ref_stores and submodules. Signed-off-by: Michael Haggerty

[PATCH v2 9/9] read_loose_refs(): read refs using resolve_ref_recursively()

There is no need to call read_ref_full() or resolve_gitlink_ref() from read_loose_refs(), because we already have a ref_store object in hand. So we can call resolve_ref_recursively() ourselves. Happily, this unifies the code for the submodule vs. non-submodule cases. This requires

[PATCH v2 1/9] refs: reorder some function definitions

This avoids the need to add forward declarations in the next step. Signed-off-by: Michael Haggerty --- refs.c | 64 1 file changed, 32 insertions(+), 32 deletions(-) diff --git a/refs.c b/refs.c index

[PATCH v2 4/9] register_ref_store(): new function

Move the responsibility for registering the ref_store for a submodule from base_ref_store_init() to a new function, register_ref_store(). Call the latter from ref_store_init(). Signed-off-by: Michael Haggerty --- refs.c | 43 +-- 1

[PATCH v2 6/9] refs: push the submodule attribute down

Push the submodule attribute down from ref_store to files_ref_store. This is another step towards loosening the 1:1 connection between ref_stores and submodules. Signed-off-by: Michael Haggerty --- refs.c | 11 -- refs/files-backend.c | 61

[PATCH v2 3/9] refs: remove some unnecessary handling of submodule == ""

The only external entry point to the ref_store lookup functions is get_ref_store(), which ensures that submodule == "" is passed along as NULL. So ref_store_init() and lookup_ref_store() don't have to handle submodule being specified as the empty string. Signed-off-by: Michael Haggerty

[PATCH v2 7/9] base_ref_store_init(): remove submodule argument

This is another step towards weakening the 1:1 relationship between ref_stores and submodules. Signed-off-by: Michael Haggerty --- refs.c | 3 +-- refs/files-backend.c | 2 +- refs/refs-internal.h | 7 +++ 3 files changed, 5 insertions(+), 7 deletions(-)

[PATCH v2 8/9] files_ref_store::submodule: use NULL for the main repository

The old practice of storing the empty string in this member for the main repository was a holdover from before 00eebe3 (refs: create a base class "ref_store" for files_ref_store, 2016-09-04), when the submodule was stored in a flex array at the end of `struct files_ref_store`. Storing NULL for

[PATCH v2 2/9] refs: make some ref_store lookup functions private

The following functions currently don't need to be exposed: * ref_store_init() * lookup_ref_store() That might change in the future, but for now make them private. Signed-off-by: Michael Haggerty --- refs.c | 19 +-- refs/refs-internal.h |

[PATCH v2 0/9] Store submodules in a hash, not a linked list

This is v2 of the patch series, considerably reorganized but not that different codewise. Thanks to Stefan, Junio, and Peff for their feedback about v1 [1]. I think I have addressed all of your comments. Changes since v1: * Rebase from `master` onto `maint` (to match Junio). * Reorder some

Re: [PATCH 0/5] Store submodules in a hash, not a linked list

On 02/10/2017 01:40 AM, Jeff King wrote: > On Thu, Feb 09, 2017 at 10:23:35PM +0100, Michael Haggerty wrote: > So push the submodule attribute down to the `files_ref_store` class (but continue to let the `ref_store`s be looked up by submodule). >>> >>> I'm not sure I understand all of

Re: [PATCH 1/5] refs: store submodule ref stores in a hashmap

On 02/09/2017 09:34 PM, Junio C Hamano wrote: > Michael Haggerty writes: >> [...] >> +static int submodule_hash_cmp(const void *entry, const void *entry_or_key, >> + const void *keydata) >> +{ >> +const struct submodule_hash_entry *e1 = entry,

Dear Friend.

Dear Friend. I Hoped that you will not expose or betray this trust and confident that I am about to repose on you for the mutual benefit of our families.I need your urgent assistance in transferring the sum of $5 million U.S dollars into your account. The money has been dormant for years in

Re: [PATCH v2] gc: ignore old gc.log files

David Turner writes: > The intent of automatic gc is to have a git repository be relatively > low-maintenance from a server-operator perspective. This is diametrically opposite from how I recall the auto-gc came about in Sep 2007. The primary purpose was to help desktop

NOTE

I am Mr.Bong Phang, Togo (West Africa) I want to seek your partnership and mutual understanding on a favorable transaction £ 12.5 million, which will benefit both of us. Greetings, Barrister Bong Phang