Hi Johannes,
Johannes Schindelin writes:
> Hi Sergey,
>
> On Mon, 12 Mar 2018, Sergey Organov wrote:
>
>> [...]
>>
>> Yet another consequence is that my approach will likely result in better
>> code reuse.
>
> This is a purely academic speculation. At least until somebody implements
> Phillip's
Dear Johannes,
Johannes Schindelin writes:
> Hi Sergey,
>
> On Mon, 12 Mar 2018, Sergey Organov wrote:
>
>> Johannes Schindelin writes:
>>
>> > [...]
>> >
>> > Where "easy" meant that I had to spend 1h still to figure out why
>> > using the unrebased merge parents as merge bases.
>>
>> That's
Hi Buga,
On Tue, 13 Mar 2018, Igor Djordjevic wrote:
> On 12/03/2018 11:20, Johannes Schindelin wrote:
> >
> > > > [...] and cannot introduce ambiguities when rebasing the
> > > > changes introduced by M (i.e. the "amendmendts" we talked about).
> > >
> > > Hmm, not following here, which ambigui
Hi Sergey,
On Mon, 12 Mar 2018, Sergey Organov wrote:
> Johannes Schindelin writes:
>
> > [...]
> >
> > Where "easy" meant that I had to spend 1h still to figure out why
> > using the unrebased merge parents as merge bases.
>
> That's because you try to figure out something that is not there i
Hi Sergey,
On Mon, 12 Mar 2018, Sergey Organov wrote:
> Johannes Schindelin writes:
> > Hi Sergey,
>
> [...]
>
> > That is misrepresenting what happened.
>
> No, it's you who are spreading misinformation, probably unintentional,
> but still.
Way to go, Sergey. Way to go.
> [... more of the
Hi Sergey,
On Mon, 12 Mar 2018, Sergey Organov wrote:
> [...]
>
> Yet another consequence is that my approach will likely result in better
> code reuse.
This is a purely academic speculation. At least until somebody implements
Phillip's method. Oh wait, I already started to implement it, and it
Hi Dscho,
On 12/03/2018 11:20, Johannes Schindelin wrote:
>
> > > [...] and cannot introduce ambiguities when rebasing the
> > > changes introduced by M (i.e. the "amendmendts" we talked about).
> >
> > Hmm, not following here, which ambiguities are we talking about?
>
> U1' vs U2' of course. Th
Hi Dscho,
On 11/03/2018 23:04, Igor Djordjevic wrote:
>
> I`m yet to read (and reason about) your whole (very informative)
> reply, but I just wanted to address this part first, as it might be a
> clear end-game situation already, due to a mutual agreement, all the
> rest being purely academic
Hi Johannes,
Johannes Schindelin writes:
[...]
> The biggest difference is that it is easy for me to see the motivation
> behind Phillip's strategy, whereas I am still puzzled why one would come
> up with a complicated strategy that splits merge commits and re-merges
> them later, and why it sh
Hi Buga,
Igor Djordjevic writes:
> Hi Dscho,
[...]
> I think the root of misunderstanding might be coming from the fact
> that Sergey was mainly describing a general concept (without a
> strictly defined implementation strategy, not being restricted to a
> specific one), where Phillip came up
Hi Johannes,
Johannes Schindelin writes:
> Hi Sergey,
[...]
> That is misrepresenting what happened.
No, it's you who are spreading misinformation, probably unintentional,
but still.
> First, you came up with a strategy. I pointed out shortcomings that
> implied that we cannot use it unchange
Hi Buga,
Igor Djordjevic writes:
[...]
> That said, *if* we decide we like temporary commit U1' == U2' consistency
> check (especially for non-interactive rebase, maybe), we can produce
> these after the fact for the sake of the check only.
I don't believe interactive vs. non-interactive spl
Hi Buga,
On Sun, 11 Mar 2018, Igor Djordjevic wrote:
> On 11/03/2018 16:47, Johannes Schindelin wrote:
> >
> > > Having explained all this, I realized this is the same "essentially
> > > merging the new tips into the original pretending that the new tips
> > > were not rebased but merged into up
Hi Dscho,
I`m yet to read (and reason about) your whole (very informative)
reply, but I just wanted to address this part first, as it might be a
clear end-game situation already, due to a mutual agreement, all the
rest being purely academic, interesting, but not any more (that)
important to di
Hi Dscho,
On 11/03/2018 16:47, Johannes Schindelin wrote:
>
> > > > Phillip's method is essentially merging the new tips into the original
> > > > merge, pretending that the new tips were not rebased but merged into
> > > > upstream.
> > >
> > > [...]
> > >
> > > Here`s a starting point, two comm
Hi Buga,
On Fri, 9 Mar 2018, Igor Djordjevic wrote:
> On 08/03/2018 20:58, Igor Djordjevic wrote:
> >
> > > Phillip's method is essentially merging the new tips into the original
> > > merge, pretending that the new tips were not rebased but merged into
> > > upstream.
> >
> > [...]
> >
> > He
Hi Buga,
On Thu, 8 Mar 2018, Igor Djordjevic wrote:
> On 07/03/2018 15:08, Johannes Schindelin wrote:
> >
> > > > Didn't we settle on Phillip's "perform successive three-way merges
> > > > between the original merge commit and the new tips with the old tips
> > > > as base" strategy?
> > >
> > >
On 08/03/2018 20:58, Igor Djordjevic wrote:
>
> > Phillip's method is essentially merging the new tips into the original
> > merge, pretending that the new tips were not rebased but merged into
> > upstream.
>
> [...]
>
> Here`s a starting point, two commits A and B, merged into M:
>
> (3) ---A
On 08/03/2018 21:27, Igor Djordjevic wrote:
>
> > git merge-recursive U1' -- M U2'
> > tree="$(git write-tree)"
> > # in case of original merge being octopus, we would continue like:
> > # git merge-recursive $tree -- M U3'
> > # tree="$(git write-tree)"
> > # git merge-rec
On 08/03/2018 20:58, Igor Djordjevic wrote:
>
> git merge-recursive U1' -- M U2'
> tree="$(git write-tree)"
> # in case of original merge being octopus, we would continue like:
> # git merge-recursive $tree -- M U3'
> # tree="$(git write-tree)"
> # git merge-rec
Hi Johannes,
On 07/03/2018 15:08, Johannes Schindelin wrote:
>
> > > Didn't we settle on Phillip's "perform successive three-way merges
> > > between the original merge commit and the new tips with the old tips
> > > as base" strategy?
> >
> > It seems you did, dunno exactly why.
>
> That is not
Hi Sergey,
On Wed, 7 Mar 2018, Sergey Organov wrote:
> Johannes Schindelin writes:
> >
> > On Wed, 7 Mar 2018, Sergey Organov wrote:
> >
> >> Johannes Schindelin writes:
> >>
> >> > On Tue, 6 Mar 2018, Sergey Organov wrote:
> >> >
> >> >> This is v2 of my "Rebasing merges" proposal.
> >> >
> >
Hi Johannes,
Johannes Schindelin writes:
> Hi Sergey,
>
> On Wed, 7 Mar 2018, Sergey Organov wrote:
>
>> Johannes Schindelin writes:
>>
>> > On Tue, 6 Mar 2018, Sergey Organov wrote:
>> >
>> >> This is v2 of my "Rebasing merges" proposal.
>> >
>> > Didn't we settle on Phillip's "perform success
Hi Sergey,
On Wed, 7 Mar 2018, Sergey Organov wrote:
> Johannes Schindelin writes:
>
> > On Tue, 6 Mar 2018, Sergey Organov wrote:
> >
> >> This is v2 of my "Rebasing merges" proposal.
> >
> > Didn't we settle on Phillip's "perform successive three-way merges
> > between the original merge comm
Hi Johannes,
Johannes Schindelin writes:
> Hi Sergey,
>
> On Tue, 6 Mar 2018, Sergey Organov wrote:
>
>> This is v2 of my "Rebasing merges" proposal.
>
> Didn't we settle on Phillip's "perform successive three-way merges between
> the original merge commit and the new tips with the old tips as b
Hi Sergey,
On Tue, 6 Mar 2018, Sergey Organov wrote:
> This is v2 of my "Rebasing merges" proposal.
Didn't we settle on Phillip's "perform successive three-way merges between
the original merge commit and the new tips with the old tips as base"
strategy? It has the following advantages:
- it is
26 matches
Mail list logo