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
>> to end up supportin
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 (although I have been working
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 detached and linked sub
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 license files (COPYI
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
> --- a/git-rebase--interactive.sh
> +++
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 characters,
> that f
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 current mode as a descr
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 aid a submodule
> hea
> 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
> pa
Greetings,
I have a business proposal I would love to discuss with you. please reply me
for more details
Yours Sincerely,
miss.melisa.mehmet
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
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 steps the questions
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
>> Failed: 6)
>
> These are
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 and see if they make sense?
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:
6)
These are series
t5601
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 spare the mailing list anoth
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
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 extensions too.
Moving it to cor
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 exit
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 ++-
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.
Sig
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 685e776a65..60c689383a 1006
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 @@ const char *get_superpro
$ 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
https://public-inbox.org/git/xmqq4lq6hmp2.fsf...@gitster.mtv.cor
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 t
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
> > +++ b/builtin/index-pack.c
> > @@ -222,6
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 of
**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 error
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 ev
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.
Exactly that, yes. I often
>> +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?
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.
> Signed-off-by: Adam Dinwoodie
>
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 firs
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 firs
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 the
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 into a cache. Also,
power us
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 practice of `git format-
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 semi-regularly go back and change
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 com
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
+++ b/git-rebase--interactive.sh
@@ -722,7 +7
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.
Signed-off
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 Jako
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* [mail
43 matches
Mail list logo
