Jakob Jarmar writes:
> git stash push does not recursively stash submodules, but if
> submodule.recurse is set, it may recursively reset --hard them. Having
> only the destructive action recurse is likely to be surprising
> behaviour, and unlikely to be desirable, so the easiest fix
> I've got someone to test this with the latest 2.23.0 version on archlinux.
>
> It is still happening:
>
> git clone --depth=1 --recurse-submodules --origin upstream
> https://github.com/git-for-windows/git;
> git -C git config --get submodule.active
> expected tr
ProtonMail Secure Email.
I've got someone to test this with the latest 2.23.0 version on archlinux.
It is still happening:
git clone --depth=1 --recurse-submodules --origin upstream
https://github.com/git-for-windows/git;
git -C git config --get submodule.active
expected true, got .
Anything more I need to add to help this get solved?
Sent with ProtonMail Secure Email.
git stash push does not recursively stash submodules, but if
submodule.recurse is set, it may recursively reset --hard them. Having
only the destructive action recurse is likely to be surprising
behaviour, and unlikely to be desirable, so the easiest fix should be to
ensure that the call to git
On Sat, Oct 12, 2019 at 10:46:36AM +0900, Junio C Hamano wrote:
> > + git init sub &&
> > + (
> > + cd sub &&
> > + test_commit sub_file
> > + ) &&
> > + git init main &&
> > + (
> > + cd main &&
> > + git submodule add ../sub &&
> > + tes
Jakob Jarmar writes:
> diff --git a/t/t3906-stash-submodule.sh b/t/t3906-stash-submodule.sh
> index d7219d6f8f..83106fa958 100755
> --- a/t/t3906-stash-submodule.sh
> +++ b/t/t3906-stash-submodule.sh
> @@ -1,6 +1,6 @@
> #!/bin/sh
>
> -test_description='stas
git stash push does not recursively stash submodules, but if
submodule.recurse is set, it may recursively reset --hard them. Having
only the destructive action recurse is likely to be surprising
behaviour, and unlikely to be desirable, so the easiest fix should be to
ensure that the call to git
Jakob Jarmar writes:
> git stash push does not recursively stash submodules, but if
> submodule.recurse is set, it may recursively reset --hard them. Having
> only the destructive action recurse is likely to be surprising
> behaviour, and unlikely to be desirable, so the easiest fix
git stash push does not recursively stash submodules, but if
submodule.recurse is set, it may recursively reset --hard them. Having
only the destructive action recurse is likely to be surprising
behaviour, and unlikely to be desirable, so the easiest fix should be to
ensure that the call to git
git stash push does not recursively stash submodules, but if
submodule.recurse is set, it may recursively reset --hard them. Having
only the destructive action recurse is likely to be surprising
behaviour, and unlikely to be desirable, so the easiest fix should be to
ensure that the call to git
Hello,
I think I have found a bug in the implementation of `git checkout
—recurse-submodules $branch` in the case of nested submodules. When I add a
submodule that has submodules in a feature branch of the main project, checkout
the master branch and then checkout my feature branch again, the
On Tue, Sep 17, 2019 at 6:56 PM Matheus Tavares
wrote:
>
> When grepping with --recurse-submodules, the object directory of the
> submodule is added to the in-memory alternates list. This makes git need
> to watch out for more packfiles which might bring bad consequences for
Thanks.
@@ -90,7 +90,7 @@ of the superproject, the setting there will override the one
found in
.gitmodules.
Both settings can be overridden on the command line by using the
-"--ignore-submodule" option. The 'git submodule' commands are not
+"--ignore-submodules" option. Th
When grepping with --recurse-submodules, the object directory of the
submodule is added to the in-memory alternates list. This makes git need
to watch out for more packfiles which might bring bad consequences for
memory and performance.
Now that raw_object_store is a member of the struct
Robert Schmidt-Cisternas writes:
> However, when cloning a repo with submodules, the variable is cleared
GIT_OBJECT_DIRECTORY applies to the source object store, not the
target object store---clearing is very much intentional, I think.
An operation like clone, fetch and push can involve
Hi,
In the pursuit of optimizing meta-repo workflows, I wanted to use
GIT_OBJECT_DIRECTORY to specify a single objects directory used by all
repos and submodules on a workstation.
The idea being that many metarepos will contain similar sets of
submodules, and objects can be reused, thus
I've observed that when merging a branch, and there's a submodule
conflict, sometimes Git will prompt a suggested resolution like so:
```
Failed to merge submodule Core (not fast-forward)
Found a possible merge resolution for the submodule:
If this is correct simply add it to the index for exampl
TEGER('j', "jobs", &max_children_for_submodules,
+ { OPTION_CALLBACK, 'j', "jobs", NULL, N_("jobs"),
+ N_("number of parallel tasks to run while fetching"),
+ PARSE_OPT_OPTARG, &parse_jobs_arg },
These changes re
iated objects"), TAGS_SET),
>> OPT_SET_INT('n', NULL, &tags,
>> N_("do not fetch all tags (--no-tags)"), TAGS_UNSET),
>> -OPT_INTEGER('j', "jobs", &max_children_for_submodules,
>> +{ OPTION_CALLBACK, &
--no-tags)"), TAGS_UNSET),
> - OPT_INTEGER('j', "jobs", &max_children_for_submodules,
> + { OPTION_CALLBACK, 'j', "jobs", NULL, N_("jobs"),
> + N_("number of parallel tasks to run while fetching"),
&g
jobs to be used when fetching from
multiple remotes as well.
This patch simply changes the --jobs argument parsing code to set both
max_children_for_{submodules,fetch}, as well as noting this new behavior
in the documentation.
Signed-off-by: Palmer Dabbelt
---
I very much miss in this
multiple remotes as well.
This patch simply changes the --jobs argument parsing code to set both
max_children_for_{submodules,fetch}, as well as noting this new behavior
in the documentation.
That's a sensible, if overly careful, transition plan. This patch
cannot be queued together wit
simply changes the --jobs argument parsing code to set both
> max_children_for_{submodules,fetch}, as well as noting this new behavior
> in the documentation.
That's a sensible, if overly careful, transition plan. This patch
cannot be queued together with the other four, though, for
ll.
>
> This patch simply changes the --jobs argument parsing code to set both
> max_children_for_{submodules,fetch}, as well as noting this new behavior
> in the documentation.
>
> Signed-off-by: Palmer Dabbelt
> ---
I very much miss in this description a reflection of my ana
both
max_children_for_{submodules,fetch}, as well as noting this new behavior
in the documentation.
Signed-off-by: Palmer Dabbelt
---
Documentation/fetch-options.txt | 4
builtin/fetch.c | 21 ++---
2 files changed, 22 insertions(+), 3 deletions(-)
diff --git
On Tue, 6 Aug 2019 17:54:20 +0200
Mateusz Loskot wrote:
> On Tue, 6 Aug 2019 at 16:04, Jason Sewall wrote:
> >
> > Submodules are great, and I used them at work. The problem is, people
> > wind up cloning my repos without --recursive and then nothing works
> > for th
On Tue, 6 Aug 2019 at 16:04, Jason Sewall wrote:
>
> Submodules are great, and I used them at work. The problem is, people
> wind up cloning my repos without --recursive and then nothing works
> for them, because the submodules weren't populated and those
> ultimately are nee
Submodules are great, and I used them at work. The problem is, people
wind up cloning my repos without --recursive and then nothing works
for them, because the submodules weren't populated and those
ultimately are needed to build my code.
I can see why --recursive isn't the default for
for your response.
> >
> > I really hope the change Brandon made is not a project decision. At least,
> > it does seem to me like a bug.
> >
Since I'm the one who originally implemented the --recurse-submodules
feature to git grep back in
0281e487f (grep: optional
Running git-grep with --recurse-submodules results in a cached grep for
the submodules even when --cached is not used. This makes all
modifications in submodules' tracked files be always ignored when
grepping. Solve that making git-grep respect the cached option when
invoking grep_cache() i
On Wed, Jul 31, 2019 at 12:57 PM Junio C Hamano wrote:
>
> Christian Couder writes:
>
> > On Tue, Jul 30, 2019 at 10:04 PM Junio C Hamano wrote:
> >>
> >> Matheus Tavares writes:
> >
> >> > @@ -598,7 +599,8 @@ static int grep_tree(struct grep_opt *opt, const
> >> > struct pathspec *pathspec,
>
Christian Couder writes:
> On Tue, Jul 30, 2019 at 10:04 PM Junio C Hamano wrote:
>>
>> Matheus Tavares writes:
>
>> > @@ -598,7 +599,8 @@ static int grep_tree(struct grep_opt *opt, const
>> > struct pathspec *pathspec,
>> > free(data);
>> > } else if (recur
Running git-grep with --recurse-submodules results in a cached grep for
the submodules even when --cached is not used. This makes all
modifications in submodules' tracked files be always ignored when
grepping. Solve that making git-grep respect the cached option when
invoking grep_cache() i
>
> hit |= grep_submodule(opt, pathspec, &entry.oid,
> base->buf, base->buf + tn_len,
> 1 /* ignored */);
>
> ... is a reasonable way to write it.
Right, thanks.
>
On Tue, Jul 30, 2019 at 10:04 PM Junio C Hamano wrote:
>
> Matheus Tavares writes:
> > @@ -598,7 +599,8 @@ static int grep_tree(struct grep_opt *opt, const struct
> > pathspec *pathspec,
> > free(data);
> > } else if (recurse_submodules && S_ISGITLINK(entry.m
is a reasonable way to write it.
> diff --git a/t/t7814-grep-recurse-submodules.sh
> b/t/t7814-grep-recurse-submodules.sh
> index a11366b4ce..946f91fa57 100755
> --- a/t/t7814-grep-recurse-submodules.sh
> +++ b/t/t7814-grep-recurse-submodules.sh
> @@ -408,4 +408,25 @@ tes
Running git-grep with --recurse-submodules results in a cached grep for
the submodules even when --cached is not used. This makes all
modifications in submodules' tracked files be always ignored when
grepping. Solve that making git-grep respect the cached option when
invoking grep_cache() i
On Tue, Jul 16, 2019 at 3:09 PM Daniel Zaoui wrote:
>
> Hi Matheus,
Hi, Daniel
I'm sorry, your last message went to my spam folder for some reason :(
> Thank you for your response.
>
> I really hope the change Brandon made is not a project decision. At least, it
> does seem to me like a bug.
>
> When cloning a repo with a --filter and with --recurse-submodules
> enabled, the partial clone filter only applies to the top-level repo.
> This can lead to unexpected bandwidth and disk usage for projects which
> include large submodules.
>
> Fix this by plumbing the --filter
When cloning a repo with a --filter and with --recurse-submodules
enabled, the partial clone filter only applies to the top-level repo.
This can lead to unexpected bandwidth and disk usage for projects which
include large submodules.
Fix this by plumbing the --filter argument from git-clone
information is never propagated
to the submodules. All the submodules are always initialized in a
detached head state and there is no way to change this behavior nor to
propagate the traced branch information to submodules.
* Workaround script
I managed to workaround this bug by dropping the re
Hi Matheus,
Thank you for your response.
I really hope the change Brandon made is not a project decision. At least, it
does seem to me like a bug.
How do you recommend me to solve this issue? Is there some place where I can
check if some bug ticket has been created on this matter? I didn't fin
[cC:ing Brandon via his current email address, as per .mailmap]
On Wed, 10 Jul 2019, Matheus Tavares Bernardino wrote:
> On Mon, Jul 8, 2019 at 5:22 AM Daniel Zaoui wrote:
> >
> > Hi guys,
>
> Hi, Daniel
>
> > I work with submodules and use git grep a lot.
&
On Mon, Jul 8, 2019 at 5:22 AM Daniel Zaoui wrote:
>
> Hi guys,
Hi, Daniel
> I work with submodules and use git grep a lot.
>
> I noted that when it is invoked used with --recurse-submodules, the result is
> not as expected for the submodules. I get submodules results as i
Hi guys,
I work with submodules and use git grep a lot.
I noted that when it is invoked used with --recurse-submodules, the result is
not as expected for the submodules. I get submodules results as if no files
were modified (like --cached option) although I would expect results taking
into
omehow intended (so there is a good reason for such a
behavior)?
- is there a good/quick way to figure out "parent path as known to git"
similarly as ls-tree behaves, but for "ls-files" (i.e. a worktree, which might
have submodules renamed but not yet committed etc)?
Thank you in
When using `git clone --recurse-submodules` there was previously no way to
pass a `--remote` switch to the implicit `git submodule update` command for
any use case where you want the submodules to be checked out on their
remote-tracking branch rather than with the SHA-1 recorded in the
On Fri, May 17, 2019 at 12:50 AM Ben Avison wrote:
>
> On 16/05/2019 12:31, Duy Nguyen wrote:
> > On Tue, May 14, 2019 at 2:46 AM Ben Avison wrote:
> >>
> >> When using `git clone --recurse-submodules` there was previously no way to
> >> pass a `--remote
On 16/05/2019 12:31, Duy Nguyen wrote:
On Tue, May 14, 2019 at 2:46 AM Ben Avison wrote:
When using `git clone --recurse-submodules` there was previously no way to
pass a `--remote` switch to the implicit `git submodule update` command for
any use case where you want the submodules to be
On Tue, May 14, 2019 at 2:46 AM Ben Avison wrote:
>
> When using `git clone --recurse-submodules` there was previously no way to
> pass a `--remote` switch to the implicit `git submodule update` command for
> any use case where you want the submodules to be checked out on their
>
. Would you prefer I edit the line above it as well? I simply assumed
that was the way it was preferred to perform the test for some reason.
+test_expect_success 'check the default is --no-remote-submodules' '
+ test_when_finished "rm -rf super_clone" &&am
I see you copied this from code above the context, but to check a bool
variable just use "if (var)" not "if (var == 1)".
> +test_expect_success 'check the default is --no-remote-submodules' '
> + test_when_finished "rm -rf super_clone&
When using `git clone --recurse-submodules` there was previously no way to
pass a `--remote` switch to the implicit `git submodule update` command for
any use case where you want the submodules to be checked out on their
remote-tracking branch rather than with the SHA-1 recorded in the
internal API than anything.
The change here is to stop the internal parser from accidentally
interpret options that belong to the foreach's command. The "--" and
first non-recognized argument should be handled correctly by the front
parser.
The exact behavior of this front parser,
Hi Robin,
On Fri, 12 Apr 2019, Robin H. Johnson wrote:
> Looking at git-rebase--preserve-merges.sh for this message, I think that
> should be a separate patch to make it respect --quiet.
Please note that `git rebase --preserve-merges` will be deprecated as of
the next Git version (see https://gi
On Fri, Apr 12, 2019 at 2:09 PM Robin H. Johnson wrote:
> > -- 8< --
> (snip patch, please add my DCO signed-off-by)
> Tested-by: Robin H. Johnson
> Signed-off-by: Robin H. Johnson
> > -- 8< --
> >
> > I'm a bit reluctant to follow up with a proper patch because I can't
> > digest the t5572-subm
ased and updated detached HEAD.
Successfully rebased and updated detached HEAD.
$ git pull --rebase --recurse-submodules=yes --quiet >/dev/null
$
===
Looking at git-rebase--preserve-merges.sh for this message, I think that
should be a separate patch to make it respect --quiet.
> -- 8< --
(
Initially reported for GFW on version 2.20.1, I have tested with Linux Mint
Mate 19.1 Tessa which by default uses git version 2.17.1
It produces a config file with the relevant submodule entries looking like this:
[submodule]
active = .
[submodule "Submodule/Path"]
full bisect to prove it yet.
>
> On Sat, Jan 20, 2018 at 05:57:29AM +, Robin H. Johnson wrote:
> > Somewhere between 2.13.6 & 2.14.1 there's an output regression. I
> > haven't done a bisect to trace it down further yet.
> >
> > Specifically, --r
n output regression. I
> haven't done a bisect to trace it down further yet.
>
> Specifically, --rebase --recurse-submodules=yes seems to cause --quiet
> to not be effective anymore.
>
> Full commandline:
> $ git pull --rebase --recurse-submodules --quiet
>
> In 2.
llent
fast-export tool [1]. I.e., now I have Git repositories for all the
sub-repos and a parent Git project including all those as Git
submodules.
So what's left is the "un-submoduling" part. Of course, I've searched
the net for solutions. The best one I've found is thi
rs when
comparing binary files"),
PARSE_OPT_NOARG, diff_opt_textconv),
+ OPT_CALLBACK_F(0, "ignore-submodules", options, N_(""),
+ N_("ignore changes to submodules in the diff
generation"),
On Fri, 1 Feb 2019 at 15:00, Ole Pinto wrote:
>
> Adding a worktree from a working copy with submodules doesn't work.
>
> In the config file I have
> [submodule]
> recurse = true
>
FYI, https://git-scm.com/docs/git-worktree#_bugs
"Multiple checkout i
Adding a worktree from a working copy with submodules doesn't work.
In the config file I have
[submodule]
recurse = true
It that's not present, I don't find the problem.
# Preparation
$ git --version
git version 2.20.1
$ cd /tmp/
$ git init main_repo
Initia
rs when
comparing binary files"),
PARSE_OPT_NOARG, diff_opt_textconv),
+ OPT_CALLBACK_F(0, "ignore-submodules", options, N_(""),
+ N_("ignore changes to submodules in the diff
generation"),
basically makes it possible
to create secondary worktrees in either supermodules or submodules. The
user will be required to turn on extensions.worktreeConfig and this is
something I'll need to work on, to make the transition smoother.
Note that while it works, it's not really optimal bec
Jonathan Nieder writes:
> That said, it's better than nothing at all, which is why Marc proposes
> making it not attempt to check out the submodules right away, instead
> permitting the user to make the best of things.
OK. Then I do agree with the hardcoded "--no-rec
reporting. Can you describe the error message when it fails
here?
[...]
IOW, at the point in that script where we call "git checkout -f", if
we changed it to "git checkout --recurse-submodules -f", what breaks
and why? Shouldn't it succeed instead?
I think that's a
'external/submodule' failed: No such file or directory
error: Submodule 'external/submodule' could not be updated.
error: Submodule 'external/submodule' cannot checkout new HEAD.
fatal: Could not reset index file to revision 'HEAD'.
I had assumed that th
The new workdir is empty before the checkout, so attempts to recurse into
a non-existent submodule directory fail.
Signed-off-by: Marc Branchaud
---
Changed to use --no-recurse-submodules instead of -c submodule.recurse=false,
as Jonathan suggested.
M.
contrib/workdir/git-new
Hi,
Stefan Beller wrote:
> Internally we have rolled out this as an experiment for
> "submodules replacing the repo tool[1]".
Thanks again for writing and explaining it. Here's an updated
version, basically identical (just rebased). "git range-diff" shows
mo
> ---
>>
>> Thanks for reporting. Can you describe the error message when it fails
>> here?
[...]
> IOW, at the point in that script where we call "git checkout -f", if
> we changed it to "git checkout --recurse-submodules -f", what breaks
> and why
ails
> here?
>
>> Until the worktree command supports submodules I've gone back to using the
>> git-new-workdir script, but it fails if my config has
>> submdodule.recurse=true.
>
> Oh, dear. In general, the project does a better job at supporting "git
>
e worktree command supports submodules I've gone back to using the
> git-new-workdir script, but it fails if my config has
> submdodule.recurse=true.
Oh, dear. In general, the project does a better job at supporting "git
worktree" than "git new-workdir", but I don&#
The new workdir is empty before the checkout, so attempts to recurse into
a non-existent submodule directory fail.
Signed-off-by: Marc Branchaud
---
Until the worktree command supports submodules I've gone back to using the
git-new-workdir script, but it fails if my confi
On Fri, Jan 4, 2019 at 5:51 PM Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
> > Uninitialized submodules have nothing valueable for us to be worried
> > about. They are just SHA-1. Let "worktree remove" and "worktree move"
> > continue in this c
Uninitialized submodules have nothing valueable for us to be worried
about. They are just SHA-1. Let "worktree remove" and "worktree move"
continue in this case so that people can still use multiple worktrees
on repos with optional submodules that are never populated, like
sh
Nguyễn Thái Ngọc Duy writes:
> Uninitialized submodules have nothing valueable for us to be worried
> about. They are just SHA-1. Let "worktree remove" and "worktree move"
> continue in this case so that people can still use multiple worktrees
> on repos with op
Hello,
I believe we found a reproducible bug in git checkout
--recurse-submodules command. Documentation says, that this command
should not overwrite unstaged changes in submodules unless -f is
given. In reality local changes can be accidentally overwritten even
without -f flag.
I reproduced the
Uninitialized submodules have nothing valueable for us to be worried
about. They are just SHA-1. Let "worktree remove" and "worktree move"
continue in this case so that people can still use multiple worktrees
on repos with optional submodules that are never populated, like
sh
On Sun, Dec 16, 2018 at 7:12 AM Nguyễn Thái Ngọc Duy wrote:
> Uninitialized submodules have nothing valueable for us to be worried
> about. They are just SHA-1. Let "worktree remove" and "worktree move"
> continue in this case so that people can still use multi
Uninitialized submodules have nothing valueable for us to be worried
about. They are just SHA-1. Let "worktree remove" and "worktree move"
continue in this case so that people can still use multiple worktrees
on repos with optional submodules that are never populated, like
sh
uple days before the 2.19 release we had a bug report about
broken submodules[1] and reverted[2] the commits leading up to them.
The behavior of said bug fixed itself by taking a different approach[3],
specifically by a weaker enforcement of having `core.worktree` set in a
submodule [4].
The rever
ways from the origin.
> builtin/fetch used to only inspect submodules when they were fetched
> "on-demand", as in either on/off case it was clear whether the submodule
> needs to be fetched. However to know whether we need to try fetching the
> object id
> Keep the properties introduced in 10f5c52656 (submodule: avoid
> auto-discovery in prepare_submodule_repo_env(), 2016-09-01), by fixating
> the git directory of the submodule.
This is to avoid the autodetection of the Git repository, making it less
error-prone; looks good to me.
On Fri, Oct 26, 2018 at 1:41 PM Jonathan Tan wrote:
>
> > But this default fetch is not sufficient, as a newly fetched commit in
> > the superproject could point to a commit in the submodule that is not
> > in the default refspec. This is common in workflows like Gerrit's.
> > When fetching a Gerr
Currently when git-fetch is asked to recurse into submodules, it dispatches
a plain "git-fetch -C " (with some submodule related options
such as prefix and recusing strategy, but) without any information of the
remote or the tip that should be fetched.
But this default fetch is not suff
Keep the properties introduced in 10f5c52656 (submodule: avoid
auto-discovery in prepare_submodule_repo_env(), 2016-09-01), by fixating
the git directory of the submodule.
Signed-off-by: Stefan Beller
---
submodule.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/
On Thu, Nov 15, 2018 at 4:31 PM Michael Forney wrote:
>
> On 2018-11-15, Stefan Beller wrote:
> > On Thu, Nov 15, 2018 at 1:33 PM Michael Forney wrote:
> >> Well, currently the submodule config can be disabled in diff_flags by
> >> setting override_submodule_config=1. However, I'm thinking it ma
mat = DIFF_FORMAT_CALLBACK;
>> rev.diffopt.format_callback = update_callback;
>> rev.diffopt.format_callback_data = &data;
>> - rev.diffopt.flags.override_submodule_config = 1;
>
> This line partially reverts 5556808, taking 02f2f56bc377c28
> into
On Thu, Nov 15, 2018 at 1:33 PM Michael Forney wrote:
>
> On 2018-11-15, Stefan Beller wrote:
> > On Wed, Nov 14, 2018 at 10:05 PM Michael Forney
> > wrote:
> >> Looking at ff6f1f564c, I don't really see anything that might be
> >> related to git-add, git-reset, or git-diff, so I'm guessing that
On 2018-11-15, Michael Forney wrote:
> Here is a work-in-progress diff that seems to have the correct
> behavior in all cases I tried.
I was hoping that gmail wouldn't mess with the whitespace, but apparently
it has, sorry about that. Let me try again.
---
builtin/add.c | 1 -
diff-lib.c|
On 2018-11-15, Stefan Beller wrote:
> On Wed, Nov 14, 2018 at 10:05 PM Michael Forney
> wrote:
>> Looking at ff6f1f564c, I don't really see anything that might be
>> related to git-add, git-reset, or git-diff, so I'm guessing that this
>> only worked before because the submodule config wasn't get
e a look through that series.
>
> Interesting. If I build git from master after reverting 55568086, I do
> indeed observe the issue it claims to fix (unable to add ignored
> submodules). However, if I build from 9ef23f91fc (the immediate parent
> of 55568086), I do not see the issue.
>
&
> I have a git repository which contains a number of submodules that
> refer to external repositories. Some of these repositories need to
> patched in some way, so patches are stored alongside the submodules,
> and are applied when building. This mostly works fine, but causes
> sub
/submodule-config-cleanup', 2017-08-26)
>> to understand why it happened in the context would be a good start.
>
> Thanks, that's a good idea. I'll take a look through that series.
Interesting. If I build git from master after reverting 55568086, I do
indeed observe the issue i
On 2018-10-25, Stefan Beller wrote:
> On Thu, Oct 25, 2018 at 11:03 AM Michael Forney
> wrote:
>>
>> On 2018-03-16, Michael Forney wrote:
>> > Hi,
>> >
>> > In the past few months have noticed some confusing behavior with
>> > ignored submod
> But this default fetch is not sufficient, as a newly fetched commit in
> the superproject could point to a commit in the submodule that is not
> in the default refspec. This is common in workflows like Gerrit's.
> When fetching a Gerrit change under review (from refs/changes/??), the
> commits in
On Thu, Oct 25, 2018 at 6:59 PM Junio C Hamano wrote:
>
> Stefan Beller writes:
>
> >> In this series I am addressing the comments by Stefan Beller about the
> >> tests in patch 9.
> >>
> >> If the new tests look OK, I'd say we try moving the series to "next" and
> >> see what happens?
> >
> > So
1 - 100 of 2548 matches
Mail list logo
