On Fri, 2016-08-26 at 10:35 -0700, Stefan Beller wrote:
> > a) read_gitfile on /.git
> > b) if read_gitfile succeeds, use it's contents, otherwise use
> > /.git for next steps
> > c) check if the resulting file is a git directory, we're fine.. we
> > found a gitdir, so stop.
> > d) otherwise, empt
On Thu, Aug 25, 2016 at 3:46 PM, Jacob Keller wrote:
> On Thu, Aug 25, 2016 at 3:38 PM, Junio C Hamano wrote:
>> Jacob Keller writes:
>>
>>> So we should support the gitlink to a repository stored at
>>> without stuff inside the .git/modules, and we should support submodule
>>> gitlinks with a
On Thu, Aug 25, 2016 at 3:38 PM, Junio C Hamano wrote:
> Jacob Keller writes:
>
>> So we should support the gitlink to a repository stored at
>> without stuff inside the .git/modules, and we should support submodule
>> gitlinks with a proper .gitmodules setup. I don't think we should
>> die() bu
Jacob Keller writes:
> So we should support the gitlink to a repository stored at
> without stuff inside the .git/modules, and we should support submodule
> gitlinks with a proper .gitmodules setup. I don't think we should
> die() but we should error properly so I will introduce a _gently()
> va
On Thu, Aug 25, 2016 at 1:46 PM, Stefan Beller wrote:
> On Thu, Aug 25, 2016 at 1:39 PM, Jacob Keller wrote:
>> On Tue, Aug 23, 2016 at 10:47 AM, Stefan Beller wrote:
>>> On Tue, Aug 23, 2016 at 10:25 AM, Junio C Hamano wrote:
I am not so sure about that. If there is an existing place tha
On Thu, Aug 25, 2016 at 1:39 PM, Jacob Keller wrote:
> On Tue, Aug 23, 2016 at 10:47 AM, Stefan Beller wrote:
>> On Tue, Aug 23, 2016 at 10:25 AM, Junio C Hamano wrote:
>>> I am not so sure about that. If there is an existing place that is
>>> buggy, shouldn't we fix that, instead of spreading
On Tue, Aug 23, 2016 at 10:47 AM, Stefan Beller wrote:
> On Tue, Aug 23, 2016 at 10:25 AM, Junio C Hamano wrote:
>> I am not so sure about that. If there is an existing place that is
>> buggy, shouldn't we fix that, instead of spreading the same bug
>> (assuming that it is a bug in the first pla
On Tue, Aug 23, 2016 at 10:25 AM, Junio C Hamano wrote:
> I am not so sure about that. If there is an existing place that is
> buggy, shouldn't we fix that, instead of spreading the same bug
> (assuming that it is a bug in the first place, which I do not have a
> strong opinion on, at least not y
On Tue, Aug 23, 2016 at 10:25 AM, Junio C Hamano wrote:
> I am not so sure about that. If there is an existing place that is
> buggy, shouldn't we fix that, instead of spreading the same bug
> (assuming that it is a bug in the first place, which I do not have a
> strong opinion on, at least not y
Stefan Beller writes:
> On Mon, Aug 22, 2016 at 4:43 PM, Jacob Keller
> wrote:
>> From: Jacob Keller
>>
>> A few suggestions from Stefan in regards to falling back to
>> .git/modules/ being a bad idea. I've chosen I think to avoid using
>> die() as we just stick with the current path if we can
On Mon, Aug 22, 2016 at 6:00 PM, Stefan Beller wrote:
> On Mon, Aug 22, 2016 at 4:43 PM, Jacob Keller
> wrote:
>> From: Jacob Keller
>>
>> A few suggestions from Stefan in regards to falling back to
>> .git/modules/ being a bad idea. I've chosen I think to avoid using
>> die() as we just stick
On Mon, Aug 22, 2016 at 4:43 PM, Jacob Keller wrote:
> From: Jacob Keller
>
> A few suggestions from Stefan in regards to falling back to
> .git/modules/ being a bad idea. I've chosen I think to avoid using
> die() as we just stick with the current path if we can't find its name.
Which makes the
From: Jacob Keller
A few suggestions from Stefan in regards to falling back to
.git/modules/ being a bad idea. I've chosen I think to avoid using
die() as we just stick with the current path if we can't find its name.
I think this should be safe since we already do this today. The new flow
only c
13 matches
Mail list logo
