On Tue, Oct 04, 2016 at 11:08:33AM -0700, Stefan Beller wrote:
> On Tue, Oct 4, 2016 at 11:04 AM, Junio C Hamano wrote:
> > Jeff King writes:
> >
> >> Actually, I like that a bit better. It would not cover the case where
> >> you have not actually checked out
On Tue, Oct 4, 2016 at 11:04 AM, Junio C Hamano wrote:
> Jeff King writes:
>
>> Actually, I like that a bit better. It would not cover the case where
>> you have not actually checked out any of the submodules (or at least not
>> called "submodule init", I
On Tue, Oct 4, 2016 at 11:00 AM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> +static void preset_submodule_default(void)
>> +{
>> + if (file_exists(".gitmodules"))
>
> Don't we need to see if we are in a bare repository?
See discussion with
Jeff King writes:
> Actually, I like that a bit better. It would not cover the case where
> you have not actually checked out any of the submodules (or at least not
> called "submodule init", I guess?). But arguably that is a sign that the
> auto-recurse behavior should not be
Junio C Hamano writes:
> Stefan Beller writes:
>
>> +static void preset_submodule_default(void)
>> +{
>> +if (file_exists(".gitmodules"))
>
> Don't we need to see if we are in a bare repository?
>
>> +recurse_submodules =
Stefan Beller writes:
> +static void preset_submodule_default(void)
> +{
> + if (file_exists(".gitmodules"))
Don't we need to see if we are in a bare repository?
> + recurse_submodules = RECURSE_SUBMODULES_CHECK;
> + else
> +
On Tue, Oct 04, 2016 at 10:48:51AM -0700, Stefan Beller wrote:
> > This does seem like a reasonable heuristic. I wonder if you want to
> > confirm that we actually have a worktree (and are in it) before looking
> > at file_exists(). It's unlikely that looking at ".gitmodules" in a bare
> > repo
On Tue, Oct 4, 2016 at 10:34 AM, Jeff King wrote:
> On Tue, Oct 04, 2016 at 09:40:36AM -0700, Stefan Beller wrote:
>
>> >> Why should we even have a default different from today's? If most
>> >> repositories don't have submodules enabled at all, we can just let
>> >> those working
On Tue, Oct 04, 2016 at 09:40:36AM -0700, Stefan Beller wrote:
> >> Why should we even have a default different from today's? If most
> >> repositories don't have submodules enabled at all, we can just let
> >> those working with submodules enabled to toggle their configuration
> >> and that is
When working with submodules, it is easy to forget to push the submodules.
The setting 'check', which checks if any existing submodule is present on
at least one remote of the submodule remotes, is designed to prevent this
mistake.
Flipping the default to check for submodules is safer than the
Stefan Beller writes:
> I guess we can postpone it until 3.0, though I currently think it is not a big
> issue as it helps avoiding "bugs in your workflow".
>
> On the other hand if you really want to push out the superproject without
> the submodules, you need to adapt your
On Thu, Aug 18, 2016 at 7:09 AM, Heiko Voigt wrote:
> On Wed, Aug 17, 2016 at 02:14:11PM -0700, Stefan Beller wrote:
>> On Wed, Aug 17, 2016 at 2:05 PM, Junio C Hamano wrote:
>> > Stefan Beller writes:
> [...]
>> >> Flipping the default
On Wed, Aug 17, 2016 at 2:05 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> If working with submodules, there are more reports of missing submodules
>> rather than the desire to push the superproject without the submodules
>> to be pushed out.
>
> I
Stefan Beller writes:
> If working with submodules, there are more reports of missing submodules
> rather than the desire to push the superproject without the submodules
> to be pushed out.
I do not know how you are counting the "more reports" part of that
assertion, but it
When working with submodules, it is easy to forget to push the submodules.
Change the default to 'check' if any existing submodule is present on at
least one remote of the submodule remotes.
This doesn't affect you if you do not work with submodules.
If working with submodules, there are more
15 matches
Mail list logo