Jonathan Nieder writes:
> The thread I am replying to appears to be where the patch comes from
> but I have some memories of more recent discussion that I'm not
> finding.
>
> More context:
> https://public-inbox.org/git/xmqqshd8i3ze@gitster.mtv.corp.google.com/
> says
>
> * sb/submodule-rec
On Tue, Nov 21, 2017 at 2:47 PM, Jonathan Nieder wrote:
> Hi,
>
> Stefan Beller wrote:
>> On Tue, Nov 21, 2017 at 2:34 PM, Jonathan Nieder wrote:
>
>>> Stefan, do you know what thread I should look at to find the current
>>> state of this patch? I've had it applied locally for a long time.
>>
>>
Hi,
Stefan Beller wrote:
> On Tue, Nov 21, 2017 at 2:34 PM, Jonathan Nieder wrote:
>> Stefan, do you know what thread I should look at to find the current
>> state of this patch? I've had it applied locally for a long time.
>
> It was "Undecided" for some time, then Junio kicked it back to pu,
On Tue, Nov 21, 2017 at 2:34 PM, Jonathan Nieder wrote:
> Stefan Beller wrote:
>>> Junio C Hamano writes:
>
Also, while I do agree with you that the problem exists, it is
unclear why this patch is a solution and not a hack that sweeps a
problem under the rug.
It is unclea
Stefan Beller wrote:
>> Junio C Hamano writes:
>>> Also, while I do agree with you that the problem exists, it is
>>> unclear why this patch is a solution and not a hack that sweeps a
>>> problem under the rug.
>>>
>>> It is unclear why this "silently detach HEAD without telling the
>>> user" is
Stefan Beller writes:
> So I took a step back and wrote about different proposals where
> we want to go long term. See below. This will help us
> figuring out how to approach this bug correctly.
Thanks for writing this.
> RFC: A new type of symbolic refs
>
> A symbolic ref can currently only po
On Mon, Jul 24, 2017 at 3:23 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Also, while I do agree with you that the problem exists, it is
>> unclear why this patch is a solution and not a hack that sweeps a
>> problem under the rug.
>>
>> It is unclear why this "silently detach HEAD wit
Junio C Hamano writes:
> Also, while I do agree with you that the problem exists, it is
> unclear why this patch is a solution and not a hack that sweeps a
> problem under the rug.
>
> It is unclear why this "silently detach HEAD without telling the
> user" is a better solution than erroring ou
Jonathan Nieder writes:
> Yikes. Yes, this bug looks problematic. Thanks for working on it.
>
>> I improved the commit message laying out the current state of affairs,
>> arguing that any future plan should not weigh in as much as the current
>> possible data loss.
>
> Can you elaborate on what
Stefan Beller writes:
>> Are you saying
>> the current behavior of updating whatever branch HEAD is on (which,
>> don't get me wrong, is a wrong behavior that needs fixing) bypassed
>> the reflog?
>
> No, I am not saying that.
> I am saying that updating an unrelated branch (which is dragged int
On Mon, Jul 24, 2017 at 11:03 AM, Jonathan Nieder wrote:
> Hi,
>
> Stefan Beller wrote:
>
>> When a submodule is on a branch and in its superproject you run a
>> recursive checkout, the branch of the submodule is updated to what the
>> superproject checks out. This is very unexpected in the curren
Hi,
Stefan Beller wrote:
> When a submodule is on a branch and in its superproject you run a
> recursive checkout, the branch of the submodule is updated to what the
> superproject checks out. This is very unexpected in the current model of
> Git as e.g. 'submodule update' always detaches the sub
When a submodule is on a branch and in its superproject you run a
recursive checkout, the branch of the submodule is updated to what the
superproject checks out. This is very unexpected in the current model of
Git as e.g. 'submodule update' always detaches the submodule HEAD.
Despite having plans
When a submodule is on a branch and in its superproject you run a recursive
checkout, the branch of the submodule is updated to what the superproject
checks out. This is very unexpected. Instead detach the HEAD when updating
it.
Signed-off-by: Stefan Beller
---
submodule.c | 3 ++-
14 matches
Mail list logo