I'm using the Pharo 6.1 image with the Pharo Launcher. I have committed
changes to several local github repos through Iceberg. I would like to be
able to clone a new 6.1 image and load all the locally committed packages.
I have "Share repositories between images" checked in both images, and the
pa
Evan Donahue wrote
> I have "Share repositories between images" checked in both images
What that option does is look in a standard shared location for the clone of
a particular repo in the form {{shareRoot}}/{{username}}/{{repoName}} (e.g.
~/MySharedRoot/seandenigris/Magritte3) instead of making a
Evan Donahue wrote:
> I have "Share repositories between images" checked in both images,
Share repositories at the moment just provides a shared location on disk
where the repositories are located. That is only useful if you are very
disciplined about stashing and switching to the branch needed
hi,
> On 4 Jun 2018, at 12:57, Stephan Eggermont wrote:
>
> Evan Donahue wrote:
>> I have "Share repositories between images" checked in both images,
>
> Share repositories at the moment just provides a shared location on disk
> where the repositories are located. That is only useful if you a
> P7 will force you to be in the right branch or you will not be able to do…
> almost anything :)
> you can have two (or ten) images opened at once and work on them, but at a
> moment you will need to “repair” each image to commit.
So are we saying that the easiest and less complicated option is
Esteban Lorenzano
wrote:
.
> P7 will force you to be in the right branch or you will not be able to
> do… almost anything :)
> you can have two (or ten) images opened at once and work on them, but at
> a moment you will need to “repair” each image to commit.
Ah, nice. How is that guarded against
> but I’m trying to understand what is the easiest option to avoid
gotcha’s (that more advanced guys can better cope with)
I guess the question is whether you want to handle conflict resolutions
directly with git, or through iceberg.
I've been using separate clones for each image for a long time
> On 4 Jun 2018, at 18:59, Tim Mackinnon wrote:
>
>> P7 will force you to be in the right branch or you will not be able to do…
>> almost anything :)
>> you can have two (or ten) images opened at once and work on them, but at a
>> moment you will need to “repair” each image to commit.
>
> S
On 5 June 2018 at 00:59, Tim Mackinnon wrote:
> > P7 will force you to be in the right branch or you will not be able to
> do… almost anything :)
> > you can have two (or ten) images opened at once and work on them, but at
> a moment you will need to “repair” each image to commit.
>
> So are we s
> Am 04.06.2018 um 19:26 schrieb Stephan Eggermont :
>
> Esteban Lorenzano
> wrote:
> .
>> P7 will force you to be in the right branch or you will not be able to
>> do… almost anything :)
>> you can have two (or ten) images opened at once and work on them, but at
>> a moment you will need to
> Am 04.06.2018 um 15:59 schrieb Esteban Lorenzano :
>
> hi,
>
>> On 4 Jun 2018, at 12:57, Stephan Eggermont wrote:
>>
>> Evan Donahue wrote:
>>> I have "Share repositories between images" checked in both images,
>>
>> Share repositories at the moment just provides a shared location on di
Norbert Hartl wrote:
>> Am 04.06.2018 um 19:26 schrieb Stephan Eggermont :
>> Ah, nice. How is that guarded against concurrent access, live-lock &
>> dead-lock?
>>
> Usually git supports that out of the box. I hope libgit does not do anything
> different.
https://danluu.com/file-consistency/
ht
> Am 05.06.2018 um 09:03 schrieb Stephan Eggermont :
>
> Norbert Hartl wrote:
>>> Am 04.06.2018 um 19:26 schrieb Stephan Eggermont :
>>> Ah, nice. How is that guarded against concurrent access, live-lock &
>>> dead-lock?
>>>
>> Usually git supports that out of the box. I hope libgit does not
On Tue, Jun 5, 2018 at 8:20 AM, Norbert Hartl wrote:
>
>
> > Am 04.06.2018 um 15:59 schrieb Esteban Lorenzano :
> >
> > hi,
> >
> >> On 4 Jun 2018, at 12:57, Stephan Eggermont wrote:
> >>
> >> Evan Donahue wrote:
> >>> I have "Share repositories between images" checked in both images,
> >>
> >>
Norbert Hartl wrote:
> Ok, but where is the problem?
- needs to work on different filesystems, with tricky behavior
- git itself did not get the behavior right
- git used to be non-reentrant. Did that change?
Stephan
> Am 05.06.2018 um 16:13 schrieb Stephan Eggermont :
>
> Norbert Hartl wrote:
>
>> Ok, but where is the problem?
>
> - needs to work on different filesystems, with tricky behavior
> - git itself did not get the behavior right
> - git used to be non-reentrant. Did that change?
>
Ok, now we k
2018-06-05 16:24 GMT+02:00 Norbert Hartl :
>
>
>> Am 05.06.2018 um 16:13 schrieb Stephan Eggermont :
>>
>> Norbert Hartl wrote:
>>
>>> Ok, but where is the problem?
>>
>> - needs to work on different filesystems, with tricky behavior
>> - git itself did not get the behavior right
>> - git used to
17 matches
Mail list logo
