Re: [RFC PATCH 0/2] Fix scissors bug during merge conflict

Denton Liu writes: > With this fix, the message becomes the following: > > Merge branch 'master' into new > > # >8 > # Do not modify or remove the line above. > # Everything below it will be ignored. > # > #

Re: [PATCH] git-compat-util: prefer poll.h to sys/poll.h

Đoàn Trần Công Danh writes: > -#ifndef NO_SYS_POLL_H > +#if !defined(NO_POLL_H) > +#include > +#elif !defined(NO_SYS_POLL_H) > #include > #else > +/* Pull the compat stuff */ > #include > #endif The last comment would help readers who got "Huh? When NO_POLL_H and NO_SYS_POLL_H is

Re: [PATCH 0/1] Some left-over add-on for bw/config-h

On Wed, Nov 14, 2018 at 02:52:24PM +0900, Junio C Hamano wrote: > "Johannes Schindelin via GitGitGadget" > writes: > > > Back when bw/config-h was developed (and backported to Git for Windows), I > > came up with this patch. It seems to not be strictly necessary, but I like > > the safety of

Re: [PATCH 0/1] rebase: understand -C again, refactor

On Tue, Nov 13, 2018 at 04:38:24AM -0800, Johannes Schindelin via GitGitGadget wrote: > Phillip Wood reported a problem where the built-in rebase did not understand > options like -C1, i.e. it did not expect the option argument. > > While investigating how to address this best, I stumbled upon

Re: [PATCH] diff: align move detection error handling with other options

Stefan Beller writes: >Subject: Re: [PATCH] diff: align move detection error handling with other >options When sending an updated version of existing topic, please make sure you indicate as such with v$n etc. I will assume that this is to replace the patch queued on

Re: [PATCH v2 00/11] fast export and import fixes and features

On Tue, Nov 13, 2018 at 04:25:49PM -0800, Elijah Newren wrote: > This is a series of small fixes and features for fast-export and > fast-import, mostly on the fast-export side. I looked over this, and I think you've addressed all of my questions. A few quick comments: > Changes since v1 (full

Re: [PATCH 10/10] fast-export: add --always-show-modify-after-rename

On Tue, Nov 13, 2018 at 09:10:36AM -0800, Elijah Newren wrote: > > I am looking at this problem as "how do you answer question X in a > > repository". And I think you are looking at as "I am receiving a > > fast-export stream, and I need to answer question X on the fly". > > > > And that would

Re: [PATCH v3] index-pack: add ability to disable SHA-1 collision check

Ævar Arnfjörð Bjarmason writes: > Add a new core.checkCollisions setting. On by default, it can be set > to 'false' to disable the check for existing objects in sha1_object(). > ... > diff --git a/builtin/index-pack.c b/builtin/index-pack.c > index 2004e25da2..4a3508aa9f 100644 > ---

Re: [PATCH] remote-curl: die on server-side errors

On Tue, Nov 13, 2018 at 07:49:15PM -0500, Jeff King wrote: > Yes, the packet_read_line_buf() interface will both advance the buf > pointer and decrement the length. So if we want to "peek", we have to > do so with a copy (there's a peek function if you use the packet_reader > interface, but that

Re: [PATCH v4 0/7] fixes for unqualified push

Thanks for an update; will replace.

报名参展中国展团、拓展日本的促销礼品市场

尊敬的 市场经理, Zhejiang Wuchuan Industrial Co., Ltd 您好！这里是日本国际促销礼品&营销展Marketing & Sales Promotino Expo展会主办方。 日本国际促销礼品&营销展是日本最大的促销礼品及营销展。 2019年展会将汇聚650家展商和44,000名专业观众。 本展在日本已经有10年的历史，为了满足日本当地买家对产品新颖，价格低廉的需求， 自2016年开始正式接受国际买家报名，国际展商数目日益增加。 本邮件是推荐您报名参加展会的中国展团，以进一步拓展日本的促销礼品市场。

Re: [PATCH] push: change needlessly ambiguous example in error

"Junio C Hamano" wrote: > > Where 'topic' is a tracking branch of 'origin/master' (I use > > push.default=upstream). I only recently discovered that I could push to > > 'HEAD" to do the same thing. So one ulterior motive is to make that more > > prominent. [...] > Do we consider the current

Re: [PATCH 0/1] Some left-over add-on for bw/config-h

"Johannes Schindelin via GitGitGadget" writes: > Back when bw/config-h was developed (and backported to Git for Windows), I > came up with this patch. It seems to not be strictly necessary, but I like > the safety of falling back to the Git directory when no common directory is > configured (for

Re: What's cooking in git.git (Nov 2018, #04; Tue, 13)

Ævar Arnfjörð Bjarmason writes: >> * ab/dynamic-gettext-poison (2018-11-09) 2 commits >> - Makefile: ease dynamic-gettext-poison transition >> - i18n: make GETTEXT_POISON a runtime option >> >> On hold. >> The tip one may be controversial, but at least it would get me going. >> cf. > > So

Re: [PATCH] git-compat-util: prefer poll.h to sys/poll.h

"brian m. carlson" writes: >> - t1308.23 is failing because musl `fopen` is success when open directory >> in readonly mode. POSIX allows this behavior: >> http://pubs.opengroup.org/onlinepubs/7908799/xsh/fopen.html >> [EISDIR] >> The named file is a directory and mode requires write access. > >

[RFC PATCH 1/2] commit: don't add scissors line if one exists

If commit.cleanup = scissors is specified, don't produce a scissors line if one already exists in the commit message. Signed-off-by: Denton Liu --- builtin/commit.c | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/builtin/commit.c b/builtin/commit.c index

[RFC PATCH 2/2] merge: add scissors line on merge conflict

This fixes a bug where the scissors line is placed after the Conflicts: section, in the case where a merge conflict occurs and merge.cleanup = scissors. Signed-off-by: Denton Liu --- builtin/merge.c | 16 1 file changed, 16 insertions(+) diff --git a/builtin/merge.c

[RFC PATCH 0/2] Fix scissors bug during merge conflict

I discovered a bug in Git a while ago where if one is using commit.cleanup = scissors, if making a commit after a merge conflict, the scissors line will be placed after the `Conflicts:` section. As a result, a careless Git user (e.g. me) may accidentally commit the `Conflicts:` section. Here is a

Re: [PATCH 5/5] tests: explicitly use `git.exe` on Windows

"Johannes Schindelin via GitGitGadget" writes: > diff --git a/Makefile b/Makefile > index bbfbb4292d..5df0118ce9 100644 > --- a/Makefile > +++ b/Makefile > @@ -2590,6 +2590,7 @@ GIT-BUILD-OPTIONS: FORCE > @echo NO_UNIX_SOCKETS=\''$(subst ','\'',$(subst > ','\'',$(NO_UNIX_SOCKETS)))'\'

Re: [PATCH 4/5] tests: do not require Git to be built when testing an installed Git

"Johannes Schindelin via GitGitGadget" writes: > From: Johannes Schindelin > > We really only need the test helpers in that case, but that is not what > we test for. So let's skip the test for now when we know that we want to > test an installed Git. True, but... hopefully we are making sure

Re: [PATCH 2/5] tests: respect GIT_TEST_INSTALLED when initializing repositories

"Johannes Schindelin via GitGitGadget" writes: > From: Johannes Schindelin > > It really makes very, very little sense to use a different git > executable than the one the caller indicated via setting the environment > variable GIT_TEST_INSTALLED. Makes perfect sense. Shouldn't we be asking

Re: [PATCH 3/5] t/lib-gettext: test installed git-sh-i18n if GIT_TEST_INSTALLED is set

"Johannes Schindelin via GitGitGadget" writes: > From: Johannes Schindelin > > It makes very, very little sense to test the built git-sh-i18n when the > user asked specifically to test another one. > > Signed-off-by: Johannes Schindelin > --- Yup. Makes sense. > t/lib-gettext.sh | 7

Re: [PATCH 1/5] tests: fix GIT_TEST_INSTALLED's PATH to include t/helper/

"Johannes Schindelin via GitGitGadget" writes: > From: Johannes Schindelin > > We really need to be able to find the test helpers... Really. This > change was forgotten when we moved the test helpers into t/helper/ Yeah, it is unfortunate that more and more things have internal whitebox test

Re: [PATCH] git-compat-util: prefer poll.h to sys/poll.h

"brian m. carlson" writes: > On Wed, Nov 14, 2018 at 08:10:43AM +0700, Đoàn Trần Công Danh wrote: >> POSIX specifies that is the correct header for poll(2) >> whereas is only needed for some old libc. >> >> Let's follow the POSIX way by default. >> >> This effectively eliminates musl's

Re: [PATCH] push: change needlessly ambiguous example in error

Ævar Arnfjörð Bjarmason writes: >> This "git push origin HEAD" is IMHO less common. It may confuse users. >> Or users may learn it and be happy thanks to your message. I don't know. > > I was hoping for the latter. I'm slightly embarrassed to say that for > the entire time I've been using git

Re: [PATCH v4] commit: add a commit.allowEmpty config variable

Ævar Arnfjörð Bjarmason writes: > Agreed. I'm happy to see the test for-loop gone as I noted in > https://public-inbox.org/git/87d0rm7zeo@evledraar.gmail.com/ but as > noted in that v3 feedback the whole "why would anyone want this?" > explanation is still missing, and this still smells like

Re: [PATCH] Makefile: add pending semantic patches

SZEDER Gábor writes: >> > inifinite recursion)? Or are they "correct but not immediately >> > necessary" (e.g. because calling read_cache() does not hurt until >> > that function gets removed, so rewriting the callers to call >> > read_index() with _index may be correct but not immediately >> >

[PATCH v6 11/12] sha256: add an SHA-256 implementation using libgcrypt

Generally, one gets better performance out of cryptographic routines written in assembly than C, and this is also true for SHA-256. In addition, most Linux distributions cannot distribute Git linked against OpenSSL for licensing reasons. Most systems with GnuPG will also have libgcrypt, since it

[PATCH v6 09/12] commit-graph: convert to using the_hash_algo

Instead of using hard-coded constants for object sizes, use the_hash_algo to look them up. In addition, use a function call to look up the object ID version and produce the correct value. For now, we use version 1, which means to use the default algorithm used in the rest of the repository.

[PATCH v6 02/12] sha1-file: provide functions to look up hash algorithms

There are several ways we might refer to a hash algorithm: by name, such as in the config file; by format ID, such as in a pack; or internally, by a pointer to the hash_algos array. Provide functions to look up hash algorithms based on these various forms and return the internal constant used for

[PATCH v6 10/12] Add a base implementation of SHA-256 support

SHA-1 is weak and we need to transition to a new hash function. For some time, we have referred to this new function as NewHash. Recently, we decided to pick SHA-256 as NewHash. The reasons behind the choice of SHA-256 are outlined in the thread starting at [1] and in the commit history for the

[PATCH v6 12/12] hash: add an SHA-256 implementation using OpenSSL

We already have OpenSSL routines available for SHA-1, so add routines for SHA-256 as well. On a Core i7-6600U, this SHA-256 implementation compares favorably to the SHA1DC SHA-1 implementation: SHA-1: 157 MiB/s (64 byte chunks); 337 MiB/s (16 KiB chunks) SHA-256: 165 MiB/s (64 byte chunks); 408

[PATCH v6 08/12] t/helper: add a test helper to compute hash speed

Add a utility (which is less for the testsuite and more for developers) that can compute hash speeds for whatever hash algorithms are implemented. This allows developers to test their personal systems to determine the performance characteristics of various algorithms. Signed-off-by: brian m.

[PATCH v6 03/12] hex: introduce functions to print arbitrary hashes

Currently, we have functions that turn an arbitrary SHA-1 value or an object ID into hex format, either using a static buffer or with a user-provided buffer. Add variants of these functions that can handle an arbitrary hash algorithm, specified by constant. Update the documentation as well.

[PATCH v6 00/12] Base SHA-256 implementation

This series provides a functional SHA-256 implementation and wires it up, along with some housekeeping patches to make it suitable for testing. Changes from v5: * Remove inclusion of "git-compat-util.h" in header. * Remove "inline" from definition of hash_to_hex_algop_r. * Switch perl invocations

[PATCH v6 06/12] t: make the sha1 test-tool helper generic

Since we're going to have multiple hash algorithms to test, it makes sense to share as much of the test code as possible. Convert the sha1 helper for the test-tool to be generic and move it out into its own module. This will allow us to share most of this code with our NewHash implementation.

[PATCH v6 05/12] t: add basic tests for our SHA-1 implementation

We have in the past had some unfortunate endianness issues with some SHA-1 implementations we ship, especially on big-endian machines. Add an explicit test using the test helper to catch these issues and point them out prominently. This test can also be used as a staging ground for people

[PATCH v6 04/12] cache: make hashcmp and hasheq work with larger hashes

In 183a638b7d ("hashcmp: assert constant hash size", 2018-08-23), we modified hashcmp to assert that the hash size was always 20 to help it optimize and inline calls to memcmp. In a future series, we replaced many calls to hashcmp and oidcmp with calls to hasheq and oideq to improve inlining

[PATCH v6 07/12] sha1-file: add a constant for hash block size

There is one place we need the hash algorithm block size: the HMAC code for push certs. Expose this constant in struct git_hash_algo and expose values for SHA-1 and for the largest value of any hash. Signed-off-by: brian m. carlson --- cache.h | 4 hash.h | 3 +++ sha1-file.c | 2

[PATCH v6 01/12] sha1-file: rename algorithm to "sha1"

The transition plan anticipates us using a syntax such as "^{sha1}" for disambiguation. Since this is a syntax some people will be typing a lot, it makes sense to provide a short, easy-to-type syntax. Omitting the dash doesn't create any ambiguity; however, it does make the syntax shorter and

Re: [PATCH v5 02/12] sha1-file: provide functions to look up hash algorithms

On 14/11/2018 02:11, brian m. carlson wrote: > On Wed, Nov 14, 2018 at 12:11:07AM +, Ramsay Jones wrote: >> >> >> On 13/11/2018 18:42, Derrick Stolee wrote: >>> On 11/4/2018 6:44 PM, brian m. carlson wrote: +int hash_algo_by_name(const char *name) +{ +    int i; +    if

Re: rebase-in-C stability for 2.20

Ævar Arnfjörð Bjarmason writes: > According to Junio's calendar we're now 2 days from 2.20-rc0. We have > the js/rebase-autostash-detach-fix bug I reported sitting in "pu" still, > and then this. > > I see we still have rebase.useBuiltin in the code as an escape hatch, > but it's undocumented. >

Re: [PATCH 3/3] index: do not warn about unrecognized extensions

Jonathan Nieder writes: > We cannot change the past, but for index extensions of the future, > there is a straightforward improvement: silence that message except > when tracing. This way, the message is still available when > debugging, but in everyday use it does not show up so (once most Git

Re: [PATCH 2/3] ieot: default to not writing IEOT section

Ben Peart writes: > Why introduce a new setting to disable writing the IEOT extension > instead of just using the existing index.threads setting? But index.threads is about what the reader does, not about the writer who does not even know who will be reading the resulting index, no?

Re: [PATCH] Makefile: use CXXFLAGS for linking fuzzers

Josh Steadmon writes: > OSS-Fuzz only provides one set of CXXFLAGS for use on both compiling > project C++ project files as well linking the fuzzers themselves. So in > the event that Git ever added any C++ sources, they would need to use > the same set of CXXFLAGS. OK. > Given that, do you

Re: [PATCH v3 1/1] protocol: advertise multiple supported versions

SZEDER Gábor writes: >> +if (tmp_allowed_versions[0] != config_version) >> +for (int i = 1; i < nr_allowed_versions; i++) > > We don't do C99 yet, thus the declaration of a loop variable like this > is not allowed and triggers compiler errors. I thought we did a weather-balloon

Re: [PATCH v3 1/1] protocol: advertise multiple supported versions

Josh Steadmon writes: > On 2018.11.13 13:01, Junio C Hamano wrote: >> stead...@google.com writes: >> >> > Currently the client advertises that it supports the wire protocol >> > version set in the protocol.version config. However, not all services >> > support the same set of protocol versions.

Re: Re* [PATCH v3 1/1] protocol: advertise multiple supported versions

Stefan Beller writes: > "Nobody reads documentation any more, we have too much of it." Maybe, but spelling it out and writing it down, you can point at it (or hope that other people point at it without making a bad or incorrect rephrase). > I would have hoped to have a .cocci patch in the bad

[PATCH v4 1/1] protocol: advertise multiple supported versions

Currently the client advertises that it supports the wire protocol version set in the protocol.version config. However, not all services support the same set of protocol versions. For example, git-receive-pack supports v1 and v0, but not v2. If a client connects to git-receive-pack and requests

[PATCH v4 0/1] Advertise multiple supported proto versions

Fix several bugs identified in v3, clarify commit message, and clean up extern keyword in protocol.h. Josh Steadmon (1): protocol: advertise multiple supported versions builtin/archive.c| 3 + builtin/clone.c | 4 ++ builtin/fetch-pack.c | 4 ++ builtin/fetch.c

Re: [PATCH v5 02/12] sha1-file: provide functions to look up hash algorithms

On Wed, Nov 14, 2018 at 12:11:07AM +, Ramsay Jones wrote: > > > On 13/11/2018 18:42, Derrick Stolee wrote: > > On 11/4/2018 6:44 PM, brian m. carlson wrote: > >> +int hash_algo_by_name(const char *name) > >> +{ > >> +    int i; > >> +    if (!name) > >> +    return GIT_HASH_UNKNOWN; > >>

Re: [PATCH] git-compat-util: prefer poll.h to sys/poll.h

On Wed, Nov 14, 2018 at 08:10:43AM +0700, Đoàn Trần Công Danh wrote: > POSIX specifies that is the correct header for poll(2) > whereas is only needed for some old libc. > > Let's follow the POSIX way by default. > > This effectively eliminates musl's warning: > > warning redirecting

Re: [PATCH 1/3] eoie: default to not writing EOIE section

Jonathan Nieder writes: > 1. Using multiple versions of Git on a single machine. For example, > some IDEs bundle a particular version of Git, which can be a > different version from the system copy, or on a Mac, /usr/bin/git > quickly goes out of sync with the Homebrew git in >

[PATCH] git-compat-util: prefer poll.h to sys/poll.h

POSIX specifies that is the correct header for poll(2) whereas is only needed for some old libc. Let's follow the POSIX way by default. This effectively eliminates musl's warning: warning redirecting incorrect #include to Signed-off-by: Đoàn Trần Công Danh --- t0028, t1308.23,

Re: [PATCH v5 02/12] sha1-file: provide functions to look up hash algorithms

On Tue, Nov 13, 2018 at 07:45:41PM +0100, Duy Nguyen wrote: > On Tue, Nov 13, 2018 at 7:42 PM Derrick Stolee wrote: > > > > On 11/4/2018 6:44 PM, brian m. carlson wrote: > > > +int hash_algo_by_name(const char *name) > > > +{ > > > + int i; > > > + if (!name) > > > + return

Re: [PATCH v5 02/12] sha1-file: provide functions to look up hash algorithms

On Wed, Nov 14, 2018 at 12:42:45AM +, Ramsay Jones wrote: > BTW, if you were puzzling over the 3rd symbol from sha1-file.o > (which I wasn't counting in the 4 symbols above! ;-) ), then I > believe that is because Jeff's commit 3a2e08245c ("object-store: > provide helpers for

Re: [PATCH] remote-curl: die on server-side errors

On Tue, Nov 13, 2018 at 02:25:40PM -0800, Josh Steadmon wrote: > > The magic "4" here and in the existing "version 2" check is because we > > are expecting pkt-lines. The original conditional always calls > > packed_read_line_buf() and will complain if we didn't actually get a > > pkt-line. > >

Re: [PATCH v3 1/1] protocol: advertise multiple supported versions

On Tue, Nov 13, 2018 at 03:03:47PM -0800, Josh Steadmon wrote: > > > + for (int i = 1; i < nr_allowed_versions; i++) > > > > We don't do C99 yet, thus the declaration of a loop variable like this > > is not allowed and triggers compiler errors. > Sorry about that. Will fix in v4. Out of

Re: [PATCH v5 02/12] sha1-file: provide functions to look up hash algorithms

On 14/11/2018 00:11, Ramsay Jones wrote: > > > On 13/11/2018 18:42, Derrick Stolee wrote: >> On 11/4/2018 6:44 PM, brian m. carlson wrote: >>> +int hash_algo_by_name(const char *name) >>> +{ >>> +    int i; >>> +    if (!name) >>> +    return GIT_HASH_UNKNOWN; >>> +    for (i = 1; i <

Re: rebase-in-C stability for 2.20

On Tue, Nov 13, 2018 at 1:52 PM Ævar Arnfjörð Bjarmason wrote: > According to Junio's calendar we're now 2 days from 2.20-rc0. We have > the js/rebase-autostash-detach-fix bug I reported sitting in "pu" still, > and then this. > > I see we still have rebase.useBuiltin in the code as an escape

[PATCH v2 10/11] fast-export: add a --show-original-ids option to show original names

Knowing the original names (hashes) of commits can sometimes enable post-filtering that would otherwise be difficult or impossible. In particular, the desire to rewrite commit messages which refer to other prior commits (on top of whatever other filtering is being done) is very difficult without

[PATCH v2 05/11] fast-export: move commit rewriting logic into a function for reuse

Logic to replace a filtered commit with an unfiltered ancestor is useful elsewhere; put it into a function we can call. Signed-off-by: Elijah Newren --- builtin/fast-export.c | 37 ++--- 1 file changed, 22 insertions(+), 15 deletions(-) diff --git

[PATCH v2 11/11] fast-export: add --always-show-modify-after-rename

I wanted a way to gather all the following information efficiently (with as few history traversals as possible): * Get all blob sizes * Map blob shas to filename(s) they appeared under in the history * Find when files and directories were deleted (and whether they were later reinstated,

[PATCH v2 00/11] fast export and import fixes and features

This is a series of small fixes and features for fast-export and fast-import, mostly on the fast-export side. Changes since v1 (full range-diff below): - used {tilde} in asciidoc documentation to avoid subscripting and escaping problems - renamed ABORT/ERROR enum values to help avoid

[PATCH v2 06/11] fast-export: when using paths, avoid corrupt stream with non-existent mark

If file paths are specified to fast-export and multiple refs point to a commit that does not touch any of the relevant file paths, then fast-export can hit problems. fast-export has a list of additional refs that it needs to explicitly set after exporting all blobs and commits, and when it tries

[PATCH v2 03/11] fast-export: use value from correct enum

ABORT and ERROR happen to have the same value, but come from differnt enums. Use the one from the correct enum, and while at it, rename the values to avoid such problems. Signed-off-by: Elijah Newren --- builtin/fast-export.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-)

[PATCH v2 01/11] git-fast-import.txt: fix documentation for --quiet option

Signed-off-by: Elijah Newren --- Documentation/git-fast-import.txt | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt index e81117d27f..7ab97745a6 100644 --- a/Documentation/git-fast-import.txt +++

[PATCH v2 04/11] fast-export: avoid dying when filtering by paths and old tags exist

If --tag-of-filtered-object=rewrite is specified along with a set of paths to limit what is exported, then any tags pointing to old commits that do not contain any of those specified paths cause problems. Since the old tagged commit is not exported, fast-export attempts to rewrite such tags to an

[PATCH v2 09/11] fast-import: remove unmaintained duplicate documentation

fast-import.c has started with a comment for nine and a half years re-directing the reader to Documentation/git-fast-import.txt for maintained documentation. Instead of leaving the unmaintained documentation in place, just excise it. Signed-off-by: Elijah Newren --- fast-import.c | 154

[PATCH v2 08/11] fast-export: add --reference-excluded-parents option

git filter-branch has a nifty feature allowing you to rewrite, e.g. just the last 8 commits of a linear history git filter-branch $OPTIONS HEAD~8..HEAD If you try the same with git fast-export, you instead get a history of only 8 commits, with HEAD~7 being rewritten into a root commit. There

[PATCH v2 07/11] fast-export: ensure we export requested refs

If file paths are specified to fast-export and a ref points to a commit that does not touch any of the relevant paths, then that ref would sometimes fail to be exported. (This depends on whether any ancestors of the commit which do touch the relevant paths would be exported with that same ref

[PATCH v2 02/11] git-fast-export.txt: clarify misleading documentation about rev-list args

Signed-off-by: Elijah Newren --- Documentation/git-fast-export.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/git-fast-export.txt b/Documentation/git-fast-export.txt index ce954be532..fda55b3284 100644 --- a/Documentation/git-fast-export.txt +++

[PATCH 21/23] commit: prepare free_commit_buffer and release_commit_memory for any repo

Pass the object pool to free_commit_buffer and release_commit_memory, such that we can eliminate access to 'the_repository'. Also remove the TODO in release_commit_memory, as commit->util was removed in 9d2c97016f (commit.h: delete 'util' field in struct commit, 2018-05-19) Signed-off-by: Stefan

[PATCH 18/23] submodule: use submodule repos for object lookup

This converts the 'show_submodule_header' function to use the repository API properly, such that the submodule objects are not added to the main object store. Signed-off-by: Stefan Beller --- submodule.c | 73 ++--- 1 file changed, 58

[PATCH 22/23] path.h: make REPO_GIT_PATH_FUNC repository agnostic

git_pathdup uses the_repository internally, but the macro REPO_GIT_PATH_FUNC is specifically made for arbitrary repositories. Switch to repo_git_path which works on arbitrary repositories. Signed-off-by: Stefan Beller --- path.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 20/23] commit-graph: convert remaining functions to handle any repo

Convert all functions to handle arbitrary repositories in commit-graph.c that are used by functions taking a repository argument already. Notable exclusion is write_commit_graph and its local functions as that only works on the_repository. Signed-off-by: Stefan Beller --- commit-graph.c | 40

[PATCH 23/23] t/helper/test-repository: celebrate independence from the_repository

dade47c06c (commit-graph: add repo arg to graph readers, 2018-07-11) brought more independence from the_repository to the commit graph, however it was not completely independent of the_repository, as the previous patches show. To ensure we're not accessing the_repository by accident, we'd ideally

[PATCH 02/23] packfile: allow has_packed_and_bad to handle arbitrary repositories

has_packed_and_bad is not widely used, so just migrate it all at once. Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano --- packfile.c | 5 +++-- packfile.h | 2 +- sha1-file.c | 2 +- 3 files changed, 5 insertions(+), 4 deletions(-) diff --git a/packfile.c b/packfile.c index

[PATCH 17/23] pretty: prepare format_commit_message to handle arbitrary repositories

Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano --- contrib/coccinelle/the_repository.pending.cocci | 10 ++ pretty.c| 15 --- pretty.h| 7 ++- 3 files changed, 24 insertions(+),

[PATCH 16/23] commit: prepare logmsg_reencode to handle arbitrary repositories

Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano --- commit.h| 8 contrib/coccinelle/the_repository.pending.cocci | 9 + pretty.c| 13 +++-- 3 files changed, 24 insertions(+), 6

[PATCH 14/23] commit: prepare get_commit_buffer to handle any repo

Signed-off-by: Stefan Beller --- commit.c| 8 +--- commit.h| 7 ++- contrib/coccinelle/the_repository.pending.cocci | 8 3 files changed, 19 insertions(+), 4 deletions(-) diff --git a/commit.c

[PATCH 07/23] commit: allow parse_commit* to handle any repo

Just like the previous commit, parse_commit and friends are used a lot and are found in new patches, so we cannot change their signature easily. Re-introduce these function prefixed with 'repo_' that take a repository argument and keep the original as a shallow macro. Signed-off-by: Stefan

[PATCH 19/23] submodule: don't add submodule as odb for push

In push_submodule(), because we do not actually need access to objects in the submodule, do not invoke add_submodule_odb(). (for_each_remote_ref_submodule() does not require access to those objects, and the actual push is done by spawning another process, which handles object access by itself.)

[PATCH 08/23] commit-reach.c: allow paint_down_to_common to handle any repo

As the function is file local and not widely used, migrate it all at once. Signed-off-by: Stefan Beller --- commit-reach.c | 15 +-- 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/commit-reach.c b/commit-reach.c index 9f79ce0a22..67c2e43d5e 100644 --- a/commit-reach.c

[PATCH 05/23] object-store: prepare has_{sha1, object}_file to handle any repo

Signed-off-by: Stefan Beller --- .../coccinelle/the_repository.pending.cocci | 30 +++ object-store.h| 22 ++ sha1-file.c | 15 ++ 3 files changed, 56 insertions(+), 11 deletions(-) diff

[PATCH 15/23] commit: prepare repo_unuse_commit_buffer to handle any repo

Signed-off-by: Stefan Beller --- commit.c| 6 -- commit.h| 7 ++- contrib/coccinelle/the_repository.pending.cocci | 8 3 files changed, 18 insertions(+), 3 deletions(-) diff --git a/commit.c

[PATCH 06/23] object: parse_object to honor its repository argument

In 8e4b0b6047 (object.c: allow parse_object to handle arbitrary repositories, 2018-06-28), we forgot to pass the repository down to the read_object_file. Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano --- object.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff

[PATCH 12/23] commit-reach: prepare get_merge_bases to handle any repo

Similarly to previous patches, the get_merge_base functions are used often in the code base, which makes migrating them hard. Implement the new functions, prefixed with 'repo_' and hide the old functions behind a wrapper macro. Signed-off-by: Stefan Beller --- commit-reach.c

[PATCH 04/23] object-store: prepare read_object_file to deal with any repo

As read_object_file is a widely used function (which is also regularly used in new code in flight between master..pu), changing its signature is painful is hard, as other series in flight rely on the original signature. It would burden the maintainer if we'd just change the signature. Introduce

[PATCH 13/23] commit-reach: prepare in_merge_bases[_many] to handle any repo

Signed-off-by: Stefan Beller --- commit-reach.c | 15 +-- commit-reach.h | 12 ++-- contrib/coccinelle/the_repository.pending.cocci | 17 + 3 files changed, 36 insertions(+), 8 deletions(-)

[PATCH 11/23] commit-reach.c: allow get_merge_bases_many_0 to handle any repo

Signed-off-by: Stefan Beller --- commit-reach.c | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/commit-reach.c b/commit-reach.c index 81015830cb..b3b1f62aba 100644 --- a/commit-reach.c +++ b/commit-reach.c @@ -216,7 +216,8 @@ static int remove_redundant(struct

[PATCH 03/23] object-store: allow read_object_file_extended to read from any repo

read_object_file_extended is not widely used, so migrate it all at once. Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano --- object-store.h | 5 +++-- sha1-file.c| 11 ++- streaming.c| 2 +- 3 files changed, 10 insertions(+), 8 deletions(-) diff --git

[PATCH 09/23] commit-reach.c: allow merge_bases_many to handle any repo

Signed-off-by: Stefan Beller --- commit-reach.c | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/commit-reach.c b/commit-reach.c index 67c2e43d5e..a53b31e6a2 100644 --- a/commit-reach.c +++ b/commit-reach.c @@ -95,7 +95,9 @@ static struct commit_list

[PATCH 10/23] commit-reach.c: allow remove_redundant to handle any repo

Signed-off-by: Stefan Beller --- commit-reach.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/commit-reach.c b/commit-reach.c index a53b31e6a2..81015830cb 100644 --- a/commit-reach.c +++ b/commit-reach.c @@ -156,7 +156,7 @@ struct commit_list

[PATCHv3 00/23] Bring more repository handles into our code base

This resends origin/sb/more-repo-in-api. Unlike the previous resend (v2), this is not rebased to a newer base. This doesn't contain the patch for pending semantic changes, as that seems to go in its own topic branch. Please have a look at the last 4 patches specifically as they were new in the

[PATCH 01/23] sha1_file: allow read_object to read objects in arbitrary repositories

Allow read_object (a file local functon in sha1_file) to handle arbitrary repositories by passing the repository down to oid_object_info_extended. Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano --- sha1-file.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff

Re: [PATCH v5 02/12] sha1-file: provide functions to look up hash algorithms

On 13/11/2018 18:42, Derrick Stolee wrote: > On 11/4/2018 6:44 PM, brian m. carlson wrote: >> +int hash_algo_by_name(const char *name) >> +{ >> +    int i; >> +    if (!name) >> +    return GIT_HASH_UNKNOWN; >> +    for (i = 1; i < GIT_HASH_NALGOS; i++) >> +    if (!strcmp(name,

Re: rebase-in-C stability for 2.20

> But maybe I'm being overly paranoid. What do those more familiar with > this think? I am not too worried, * as rebase is a main porcelain, that is even hard to use in a script. so any failures are not deep down in some automation, but when found exposed quickly (and hopefully reported). *

Re: [PATCH 02/10] git-fast-export.txt: clarify misleading documentation about rev-list args

On Tue, Nov 13, 2018 at 3:39 PM Jonathan Nieder wrote: > Elijah Newren wrote: > > Actually, no, it actually needs to be inconsistent. > > > > Different Input Choices (neither backslashed, both backslashed, then just > > one): > > master~9 and master~10 > > master\~9 and master\~10 > >

Re: git-scm.com GUI client links

+git@vger.kernel.org, git-secur...@googlegroups.com -> bcc Paul J Sanchez wrote: > On Nov 13, 2018, at 2:25 PM, Stefan Beller wrote: >> The link seems to be https://aurees.com/ ? >> >> They seem to have >> https://aurees.com/legal/license-agreement >> which is a hilarious read: >> >> You agree

  1   2   3   >