> As you know currently the checkout doesn't touch submodules, i.e.
> you have to run "git submodule update" whenever the submodule
> changes. So when you checkout a different part of history, that moved
> a submodule, this will fail as the submodule still resides at the old
> place (and may have p
On Fri, Sep 9, 2016 at 4:37 PM, Dakota Hawkins wrote:
> Any ideas on this anywhere?
>
> In my opinion if a merge can fast-forward without conflict it should
> trivially be able to non-fast-forward without conflict.
Yes, I agree. Though the submodules still have a lot of sharp edges
that you can i
Any ideas on this anywhere?
In my opinion if a merge can fast-forward without conflict it should
trivially be able to non-fast-forward without conflict.
Also, I'm not too familiar/comfortable with mailing list etiquette,
and I don't want to be a bother by continuing to ping this thread.
Thanks,
On Tue, Sep 6, 2016 at 3:00 PM, Stefan Beller wrote:
> On Fri, Sep 2, 2016 at 12:22 PM, Dakota Hawkins
> wrote:
>> Below is a simple reproduction of the issue.
>>
>> The _real_ problem is that this is how our pull request merges work,
>
> So your workflow is the problem or is the actual bug just
On Fri, Sep 2, 2016 at 12:22 PM, Dakota Hawkins wrote:
> Below is a simple reproduction of the issue.
>
> The _real_ problem is that this is how our pull request merges work,
So your workflow is the problem or is the actual bug just exposed in
your workflow?
> they're not allowed to do fast-forw
Is there any additional information I could provide that would be helpful?
Dakota
On Fri, Sep 2, 2016 at 3:22 PM, Dakota Hawkins wrote:
> Below is a simple reproduction of the issue.
>
> The _real_ problem is that this is how our pull request merges work,
> they're not allowed to do fast-forward
6 matches
Mail list logo
