Re: [RFD] Long term plan with submodule refs?

On Wed, Nov 8, 2017 at 4:10 PM, Stefan Beller wrote: >> The relationship is indeed currently useful, but if the long term plan >> is to strongly discourage detached submodule HEAD, then I would think >> that these patches are in the wrong direction. (If the long term plan is

Re: [RFD] Long term plan with submodule refs?

Jonathan Tan writes: > What if, in the submodule, we have a new ref backend that mirrors the > superproject? When initializing the submodule, its original refs are not > cloned at all, but instead virtual refs are used. > ... > These rules seem straightforward to me

Re: [RFD] Long term plan with submodule refs?

Stefan Beller writes: >> The relationship is indeed currently useful, but if the long term plan >> is to strongly discourage detached submodule HEAD, then I would think >> that these patches are in the wrong direction. (If the long term plan is >> to end up supporting both

Re: [PATCH/RFC] Replace Free Software Foundation address in license notices

Todd Zullinger writes: > The mailing address for the FSF has changed over the years. Rather than > updating the address across all files, refer readers to gnu.org, as the > GNU GPL documentation now suggests for license notices. The mailing > address is retained in the full

Re: [PATCH] rebase -i: fix comment typo

Adam Dinwoodie writes: > Signed-off-by: Adam Dinwoodie > --- > git-rebase--interactive.sh | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh > index 2563dc52d..437815669 100644

Re: Bug - Status - Space in Filename

Joseph Strauss writes: > I believe I have found a bug in the way git status -s lists filenames. > > According to the documentation: > The fields (including the ->) are separated from each other by a single > space. If a filename contains whitespace or other nonprintable

Re: [PATCH 2/3] merge-base: return fork-point outside reflog

Michael J Gruber writes: > It seems the consensus was that current functionality is as designed but > not necessarily as expected, and another mode "--fork-base" (that does > what I suggested as "fix") would meet these expectations. I would reuse > the documentation of the

Re: [RFD] Long term plan with submodule refs?

On Wed, 8 Nov 2017 16:10:07 -0800 Stefan Beller wrote: I thought of a possible alternative and how it would work. > Possible data models and workflow implications > == > In the following different data models are presented, which

[RFD] Long term plan with submodule refs?

> The relationship is indeed currently useful, but if the long term plan > is to strongly discourage detached submodule HEAD, then I would think > that these patches are in the wrong direction. (If the long term plan is > to end up supporting both detached and linked submodule HEAD, then these >

Urgent response !!!

Greetings, I have a business proposal I would love to discuss with you. please reply me for more details Yours Sincerely, miss.melisa.mehmet

Re: Test failures on 'pu' branch

On 08/11/17 22:34, Ramsay Jones wrote: > > > On 08/11/17 20:36, Stefan Beller wrote: >> On Wed, Nov 8, 2017 at 12:28 PM, Ramsay Jones >> wrote: >> >>> t5300-pack-object.sh (Wstat: 256 Tests: 40 >>> Failed: 2) >> >>> t5500-fetch-pack.sh

Re: [RFC PATCH 0/4] git-status reports relation to superproject

On Wed, 8 Nov 2017 11:55:05 -0800 Stefan Beller wrote: > $ git -c status.superprojectinfo status > HEAD detached at v2.15-rc2 > superproject is 6 commits behind HEAD 7070ce2..5e6d0fb > nothing to commit, working tree clean > > How cool is that? > > This series side

Re: Test failures on 'pu' branch

On 08/11/17 20:36, Stefan Beller wrote: > On Wed, Nov 8, 2017 at 12:28 PM, Ramsay Jones > wrote: > >> t5300-pack-object.sh (Wstat: 256 Tests: 40 >> Failed: 2) > >> t5500-fetch-pack.sh (Wstat: 256 Tests: 355

Re: [PATCH 1/9] extension.partialclone: introduce partial clone extension

On 11/8/2017 4:51 PM, Jonathan Tan wrote: On Wed, 8 Nov 2017 15:32:21 -0500 Jeff Hostetler wrote: Thanks Jonathan. I moved my version of part 2 on top of yesterday's part 1. There are a few changes between my version and yours. Could you take a quick look at them

Re: Test failures on 'pu' branch

On 11/8/2017 3:36 PM, Stefan Beller wrote: On Wed, Nov 8, 2017 at 12:28 PM, Ramsay Jones wrote: t5300-pack-object.sh (Wstat: 256 Tests: 40 Failed: 2) t5500-fetch-pack.sh (Wstat: 256 Tests: 355 Failed:

Re: [PATCH 1/9] extension.partialclone: introduce partial clone extension

On Wed, 8 Nov 2017 15:32:21 -0500 Jeff Hostetler wrote: > Thanks Jonathan. > > I moved my version of part 2 on top of yesterday's part 1. > There are a few changes between my version and yours. Could > you take a quick look at them and see if they make sense? > (I'll

Re: Test failures on 'pu' branch

On Wed, Nov 8, 2017 at 12:28 PM, Ramsay Jones wrote: > t5300-pack-object.sh (Wstat: 256 Tests: 40 > Failed: 2) > t5500-fetch-pack.sh (Wstat: 256 Tests: 355 > Failed: 6) These are series > t5601-clone.sh

Re: [PATCH 1/9] extension.partialclone: introduce partial clone extension

On 11/6/2017 2:16 PM, Jonathan Tan wrote: On Mon, 6 Nov 2017 12:32:45 -0500 Jeff Hostetler wrote: Yes, that is a point I wanted to ask about. I renamed the extensions.partialclone that you created and then I moved your remote..blob-max-bytes setting to be in

Test failures on 'pu' branch

Hi Junio, You are probably already aware, but just in case, the 'pu' branch fails the testsuite for me as follows: $ tail -18 ptest-out Test Summary Report --- t5300-pack-object.sh (Wstat: 256 Tests: 40 Failed: 2) Failed tests: 36-37 Non-zero

[PATCH 2/4] submodule.c: factor start_ls_files_dot_dot out of get_superproject_working_tree

We'll reuse the code of the factored out function shortly, when exploring the superproject for another aspect. Instead of knowing the root of the superproject we'll find out about the gitlink value. Signed-off-by: Stefan Beller --- submodule.c | 53

[PATCH 4/4] git-status: report reference to superproject

In a submodule the position of HEAD in relation to the gitlink pointer in the superproject may be of interest. Introduce a config option `status.superprojectInfo` that when enabled will report the relation between HEAD and the commit pointed to by the gitlink in the index of the superproject.

[PATCH 1/4] remote, revision: factor out exclusive counting between two commits

Signed-off-by: Stefan Beller --- remote.c | 40 +--- revision.c | 45 + revision.h | 7 +++ 3 files changed, 53 insertions(+), 39 deletions(-) diff --git a/remote.c b/remote.c index

[PATCH 3/4] submodule.c: get superprojects gitlink value

Signed-off-by: Stefan Beller --- submodule.c | 27 +++ submodule.h | 6 ++ 2 files changed, 33 insertions(+) diff --git a/submodule.c b/submodule.c index 4fcb64469e..68b123eb13 100644 --- a/submodule.c +++ b/submodule.c @@ -2074,6 +2074,33 @@

[RFC PATCH 0/4] git-status reports relation to superproject

$ git -c status.superprojectinfo status HEAD detached at v2.15-rc2 superproject is 6 commits behind HEAD 7070ce2..5e6d0fb nothing to commit, working tree clean How cool is that? This series side steps the questions raised in

Re: What's cooking in git.git (Nov 2017, #03; Wed, 8)

On 11/08, Junio C Hamano wrote: > 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

Re: [PATCH 02/14] clone, fetch-pack, index-pack, transport: partial clone

On Friday 03 November 2017 at 01:32 pm -0700, Jonathan Tan wrote: > On Thu, 2 Nov 2017 20:31:17 + > Jeff Hostetler wrote: > > diff --git a/builtin/index-pack.c b/builtin/index-pack.c > > index a0a35e6..31cd5ba 100644 > > --- a/builtin/index-pack.c > > +++

RE: Bug - Status - Space in Filename

I believe I have found a bug in the way git status -s lists filenames. According to the documentation: The fields (including the ->) are separated from each other by a single space. If a filename contains whitespace or other nonprintable characters, that field will be quoted in the manner

Invalid memory access in `git apply`

**Resending as it seems that the attachments caused the last email to wind up in a black hole** There seems to be bug in the `git apply` that leads to out-of-bounds memory access when --ignore-space-change is combined with --inaccurate-eof and applying a patch. On occasion, this can lead to

Re: [RFC PATCH] rebisect: add script for easier bisect log editing

On Wednesday 08 November 2017 at 05:15 pm +0100, Christian Couder wrote: > >> +git bisect replay "$GIT_BISECT_LOG_TMP" > >> +rm -f "$GIT_BISECT_LOG_TMP" > > While at it, is there a reason for the -f option above? I was following the lead of git-bisect.sh, which has used `rm -f` for such things

Re: [RFC PATCH] rebisect: add script for easier bisect log editing

On Wednesday 08 November 2017 at 05:12 pm +0100, Christian Couder wrote: > On Wed, Nov 8, 2017 at 2:59 PM, Adam Dinwoodie wrote: > > +git bisect reset HEAD > > I guess that using "reset HEAD" could be cheaper than just "reset" and > that's the reason you are using it.

Re: [RFC PATCH] rebisect: add script for easier bisect log editing

>> +git bisect replay "$GIT_BISECT_LOG_TMP" >> +rm -f "$GIT_BISECT_LOG_TMP" While at it, is there a reason for the -f option above?

Re: [RFC PATCH] rebisect: add script for easier bisect log editing

On Wed, Nov 8, 2017 at 2:59 PM, Adam Dinwoodie wrote: > Add a short script, vaguely inspired by `git rebase --interactive`, to > ease the process described in the `git bisect` documentation of saving > off a bisect log, editing it, then replaying it. Nice idea. >

Re: [RFC] fastindex: parallelize index load

This is an RFC because it works but I've not done the code cleanup, added tests, support in the update-index command to add/remove it, etc. As a result, there is no reason to point out all the places I'm not currently following the git coding style. :) I wanted to get feedback on the concept

Re: [RFC] fastindex: parallelize index load

This is an RFC because it works but I've not done the code cleanup, added tests, support in the update-index command to add/remove it, etc. As a result, there is no reason to point out all the places I'm not currently following the git coding style. :) I wanted to get feedback on the concept

[RFC] fastindex: parallelize index load

This patch will address the CPU cost of loading the index by adding additional data to the index that will allow us to multi-thread the loading and conversion of cache entries. It accomplishes this by adding an (optional) index extension that is a table of offsets to blocks of cache entries in

Re: [PATCH v2 0/6] Partial clone part 1: object filtering

On 11/7/2017 7:54 PM, Junio C Hamano wrote: Jonathan Tan writes: I can see some use for this parameter - for example, when doing a report for statistical purposes (percentage of objects missing, for example) or for a background task that downloads missing objects

Re: [PATCH v2] doc/SubmittingPatches: correct subject guidance

On Wed, Nov 8, 2017 at 8:47 AM, Adam Dinwoodie wrote: > The examples and common practice for adding markers such as "RFC" or > "v2" to the subject of patch emails is to have them within the same > brackets as the "PATCH" text, not after the closing bracket. Further, > the

[RFC PATCH] rebisect: add script for easier bisect log editing

Add a short script, vaguely inspired by `git rebase --interactive`, to ease the process described in the `git bisect` documentation of saving off a bisect log, editing it, then replaying it. Signed-off-by: Adam Dinwoodie --- When I'm bisecting, I find I need to

[PATCH v2] doc/SubmittingPatches: correct subject guidance

The examples and common practice for adding markers such as "RFC" or "v2" to the subject of patch emails is to have them within the same brackets as the "PATCH" text, not after the closing bracket. Further, the practice of `git format-patch` and the like, as well as what appears to be the more

[PATCH] rebase -i: fix comment typo

Signed-off-by: Adam Dinwoodie --- git-rebase--interactive.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh index 2563dc52d..437815669 100644 --- a/git-rebase--interactive.sh +++

[PATCH] doc/SubmittingPatches: correct subject guidance

The examples and common practice for adding markers such as "RFC" or "v2" to the subject of patch emails is to have them within the same brackets as the "PATCH" text. Update the description to match this behaviour, rather than asserting such markers should be after the closing bracket.

Re: [PATCH 2/3] merge-base: return fork-point outside reflog

Ekelhart Jakob venit, vidit, dixit 08.11.2017 09:52: > Thank you for all the effort to fix this issue. Unfortunately, we are still > suffering from this and our workaround just stopped being sufficient. > > We were wondering if there is any way to tell when this fix will be released? > > BR

RE: [PATCH 2/3] merge-base: return fork-point outside reflog

Thank you for all the effort to fix this issue. Unfortunately, we are still suffering from this and our workaround just stopped being sufficient. We were wondering if there is any way to tell when this fix will be released? BR Jakob -Original Message- From: Junio C Hamano *EXTERN*