On Wed, Aug 14, 2019 at 09:40:40AM -0700, Junio C Hamano wrote:
> > but it feels odd to me. Even if the submodule is not currently checked
> > out, we'd presumably still want to do the recursive fetch as long as we
> > have a repo under $GIT_DIR/modules?
>
> ... which means that we are not intere
"Paolo Pettinato (ppettina)" writes:
> Thanks for the reply!
>
> On 14/08/2019 17:40, Junio C Hamano wrote:
>> Why is the user mucking with
>> that directory in the first place, and isn't the flagging of the
>> situation as an error, done with 26f80ccf ("submodule: migrate
>> get_next_submodule
Thanks for the reply!
On 14/08/2019 17:40, Junio C Hamano wrote:
> Why is the user mucking with
> that directory in the first place, and isn't the flagging of the
> situation as an error, done with 26f80ccf ("submodule: migrate
> get_next_submodule to use repository structs", 2018-11-28), a
> bu
Jeff King writes:
> Because you created a file in the uninitialized submodule directory, it
> fools the is_empty_dir() check. It seems like there should be a more
> robust way to check whether the submodule is initialized. Maybe:
>
> diff --git a/submodule.c b/submodule.c
> index 77ace5e784..748e
On Wed, Aug 14, 2019 at 09:57:50AM +, Paolo Pettinato (ppettina) wrote:
> The issue happens when fetching an updated ref from a remote, and that
> ref updates a submodule which is not checked out but whose folder is dirty.
>
> Steps to reproduce (on *nix) with repositories on GitHub:
> [...]
5 matches
Mail list logo
