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 any of the submodules (or at least n
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 guess?). But arguably that is a sign that
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; instead of checking the file, we rathe
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 kicking in anyway.
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 = RECURSE_SUBMODULES_CHECK;
>> +else
>> +rec
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
> + recurse_submodules = RECURSE_SUBMODUL
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 wo
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 with submodules
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 a
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 behavior (i.e. set an
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 to check for submodules is safer
>> >> than the current def
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 do not know how you are counting the "m
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 is very likely that i
13 matches
Mail list logo
