Hi Johannes,
Johannes Schindelin writes:
> Hi Sergey,
>
[...]
> In the parlance of your RFC v2, where you start with this history (which I
> translated into the left-to-right notation that is used in pretty much all
> of Git's own documentation about interactive
Hi Johannes,
Johannes Schindelin writes:
> Hi Sergey,
>
> On Wed, 28 Mar 2018, Sergey Organov wrote:
>
>> Johannes Schindelin writes:
>>
>> > I use rebase every day. I use the Git garden shears every week. If you
>> > do not trust my
Hi Johannes,
Johannes Schindelin writes:
> Hi Sergey,
>
> On Fri, 30 Mar 2018, Sergey Organov wrote:
>
>> Could we please agree to stop using backward compatibility as an
>> objection in the discussion of the --recreate-merges feature?
>
> No.
>
> The expectation of
Hi Sergey,
On Wed, 28 Mar 2018, Sergey Organov wrote:
> Johannes Schindelin writes:
>
> > I use rebase every day. I use the Git garden shears every week. If you
> > do not trust my experience with these things, nothing will convince
> > you.
>
> Unfortunately you
Hi Sergey,
On Fri, 30 Mar 2018, Sergey Organov wrote:
> Could we please agree to stop using backward compatibility as an
> objection in the discussion of the --recreate-merges feature?
No.
The expectation of users as to what a `pick` is has not changed just
because you wish it would.
That is
Hi Johannes,
Johannes Schindelin writes:
> Hi,
>
> On Thu, 29 Mar 2018, Sergey Organov wrote:
>
>> Jacob Keller writes:
>>
>> > I care about the general compatibility of the rebase todo list
>> > regardless of which options you enabled on the
Hi,
On Thu, 29 Mar 2018, Sergey Organov wrote:
> Jacob Keller writes:
>
> > I care about the general compatibility of the rebase todo list
> > regardless of which options you enabled on the command line to
> > generate it.
>
> It's a good thing in general, yes.
Jacob Keller writes:
> On Wed, Mar 28, 2018 at 4:29 AM, Sergey Organov wrote:
>
>> Jacob Keller writes:
>>
>> > On Tue, Mar 27, 2018 at 10:57 PM, Sergey Organov
>> wrote:
>> >>
>> >> Hi Johannes,
>> >>
>>
Jacob Keller writes:
> On Tue, Mar 27, 2018 at 10:57 PM, Sergey Organov wrote:
>>
>> Hi Johannes,
>>
>> Johannes Schindelin writes:
[...]
> I'm pretty sure the fact has already been accepted, as he did indeed
> implement
Jacob Keller writes:
> On Tue, Mar 27, 2018 at 10:57 PM, Sergey Organov wrote:
>>
>> Hi Johannes,
>>
>> Johannes Schindelin writes:
>> > Hi Sergey,
>> >
>>
>> [...]
>>
>> >> >> Reusing existing concepts where possible
Hi Johannes,
Johannes Schindelin writes:
> Hi Sergey,
>
[...]
>> >> Reusing existing concepts where possible doesn`t have this problem.
>> >
>> > Existing concepts are great. As long as they fit the requirements of
>> > the new scenarios. In this case, `pick` does
Hi Johannes,
Johannes Schindelin writes:
> Hi Sergey,
[...]
> But I'll stop here. Even my account how there are conceptual differences
> between the changes in merge vs non-merge commits (the non-merge commit
> *introduces* changes, the merge commit *reconciles
Hi Sergey,
On Tue, 27 Mar 2018, Sergey Organov wrote:
> Johannes Schindelin writes:
>
> > On Tue, 13 Mar 2018, Igor Djordjevic wrote:
> >
> >> On 12/03/2018 11:46, Johannes Schindelin wrote:
> >> >
> >> > > Sometimes one just needs to read the manual, and I don`t
Hi Sergey,
On Tue, 27 Mar 2018, Sergey Organov wrote:
> Johannes Schindelin writes:
> >
> > On Tue, 13 Mar 2018, Igor Djordjevic wrote:
> >
> >> On 12/03/2018 13:56, Sergey Organov wrote:
> >> >
> >> > > > I agree with both of you that `pick ` is inflexible
> >> > >
Hi Johannes,
Johannes Schindelin writes:
> Hi Buga,
>
> On Tue, 13 Mar 2018, Igor Djordjevic wrote:
>
>> On 12/03/2018 11:46, Johannes Schindelin wrote:
>> >
>> > > Sometimes one just needs to read the manual, and I don`t really
>> > > think this is a ton
Hi Johannes,
Johannes Schindelin writes:
> Hi Buga,
>
> On Tue, 13 Mar 2018, Igor Djordjevic wrote:
>
>> On 12/03/2018 13:56, Sergey Organov wrote:
>> >
>> > > > I agree with both of you that `pick ` is inflexible
>> > > > (not to say just plain wrong), but I never
Hi Sergey,
On Wed, 14 Mar 2018, Sergey Organov wrote:
> Igor Djordjevic writes:
>
> > On 07/03/2018 08:26, Johannes Schindelin wrote:
>
> [...]
>
> >> Second side note: if we can fast-forward, currently we prefer that,
> >> and I think we should keep that
Hi Buga,
On Tue, 13 Mar 2018, Igor Djordjevic wrote:
> On 12/03/2018 11:46, Johannes Schindelin wrote:
> >
> > > Sometimes one just needs to read the manual, and I don`t really
> > > think this is a ton complicated, but just something we didn`t really
> > > have before (real merge rebasing), so
Hi Buga,
On Tue, 13 Mar 2018, Igor Djordjevic wrote:
> On 12/03/2018 13:56, Sergey Organov wrote:
> >
> > > > I agree with both of you that `pick ` is inflexible
> > > > (not to say just plain wrong), but I never thought about it like
> > > > that.
> > > >
> > > > If we are to extract further
Igor Djordjevic writes:
> Hi Sergey,
>
> On 19/03/2018 06:44, Sergey Organov wrote:
>>
>> > > > > > Second side note: if we can fast-forward, currently we prefer
>> > > > > > that, and I think we should keep that behavior with -R, too.
>> > > > >
>> > > > > I agree.
Hi Sergey,
On 19/03/2018 06:44, Sergey Organov wrote:
>
> > > > > > Second side note: if we can fast-forward, currently we prefer
> > > > > > that, and I think we should keep that behavior with -R, too.
> > > > >
> > > > > I agree.
> > > >
> > > > I'm admittedly somewhat lost in the discussion,
Igor Djordjevic writes:
> On 15/03/2018 00:11, Igor Djordjevic wrote:
>>
>> > > > Second side note: if we can fast-forward, currently we prefer
>> > > > that, and I think we should keep that behavior with -R, too.
>> > >
>> > > I agree.
>> >
>> > I'm admittedly
On 15/03/2018 00:11, Igor Djordjevic wrote:
>
> > > > Second side note: if we can fast-forward, currently we prefer
> > > > that, and I think we should keep that behavior with -R, too.
> > >
> > > I agree.
> >
> > I'm admittedly somewhat lost in the discussion, but are you
> > talking
Hi Sergey,
On 15/03/2018 07:00, Sergey Organov wrote:
>
> > > Thinking about it I've got an idea that what we actually need is
> > > --no-flatten flag that, when used alone, will just tell "git rebase" to
> > > stop flattening history, and which will be implicitly imposed by
> > >
Hi Buga,
Igor Djordjevic writes:
> On 14/03/2018 15:24, Sergey Organov wrote:
[...]
>> Thinking about it I've got an idea that what we actually need is
>> --no-flatten flag that, when used alone, will just tell "git rebase" to
>> stop flattening history, and which
On 14/03/2018 15:24, Sergey Organov wrote:
>
> > > Second side note: if we can fast-forward, currently we prefer that, and I
> > > think we should keep that behavior with -R, too.
> >
> > I agree.
>
> I'm admittedly somewhat lost in the discussion, but are you talking
> fast-forward on
Igor Djordjevic writes:
> Hi Dscho,
>
> On 07/03/2018 08:26, Johannes Schindelin wrote:
[...]
>> Second side note: if we can fast-forward, currently we prefer that, and I
>> think we should keep that behavior with -R, too.
>
> I agree.
I'm admittedly somewhat lost
Hi Buga,
Igor Djordjevic writes:
[...]
> I don`t know, I`m thinking if we are looking at todo list from
> different perspectives - to you, it seems to be a sequence of
> commands to create something new (yes, from something that already
> exists, but that`s
Hi Dscho,
On 12/03/2018 11:46, Johannes Schindelin wrote:
>
> > Sometimes one just needs to read the manual, and I don`t really think
> > this is a ton complicated, but just something we didn`t really have
> > before (real merge rebasing), so it requires a moment to grasp the
> > concept.
>
>
On 12/03/2018 13:56, Sergey Organov wrote:
>
> > > I agree with both of you that `pick ` is inflexible
> > > (not to say just plain wrong), but I never thought about it like that.
> > >
> > > If we are to extract further mentioned explicit old:new merge
> > > parameter mapping to a separate
Hi Dscho,
On 12/03/2018 11:37, Johannes Schindelin wrote:
>
> > If we are to extract further mentioned explicit old:new merge
> > parameter mapping to a separate discussion point, what we`re
> > eventually left with is just replacing this:
> >
> > merge -R -C
> >
> > ... with this:
> >
>
Hi Johannes,
Johannes Schindelin writes:
> Hi Buga,
>
> On Sun, 11 Mar 2018, Igor Djordjevic wrote:
>
>> I agree with both of you that `pick ` is inflexible
>> (not to say just plain wrong), but I never thought about it like that.
>>
>> If we are to extract further
Hi Buga,
I just have two thoughts to contribute as answer, so please excuse the
heavily cut quoted text:
On Sun, 11 Mar 2018, Igor Djordjevic wrote:
> Sometimes one just needs to read the manual, and I don`t really think
> this is a ton complicated, but just something we didn`t really have
>
Hi Buga,
On Sun, 11 Mar 2018, Igor Djordjevic wrote:
> I agree with both of you that `pick ` is inflexible
> (not to say just plain wrong), but I never thought about it like that.
>
> If we are to extract further mentioned explicit old:new merge
> parameter mapping to a separate discussion
Hi Dscho,
On 11/03/2018 13:11, Johannes Schindelin wrote:
>
> > > I did wonder about using 'pick ' for rebasing merges
> > > and keeping 'merge ...' for recreating them but I'm not sure if that
> > > is a good idea. It has the advantage that the user cannot specify the
> > > wrong parents for
Hi Dscho,
On 11/03/2018 13:08, Johannes Schindelin wrote:
>
> > Hmm, funny enough, `pick ` was something I though about
> > originally, too, feeling that it might make more sense in terms on
> > what`s really going on, but I guess I wanted it incorporated into
> > `--recreate-merges` too much
Hi Dscho,
On 11/03/2018 13:00, Johannes Schindelin wrote:
>
> > I actually like `pick` for _rebasing_ merge commits, as `pick` is
> > already used for rebasing non-merge commits, too, so it feels natural.
>
> Phillip is right, though: this would repeat the design mistake of
>
Hi Buga,
On Thu, 8 Mar 2018, Igor Djordjevic wrote:
> On 08/03/2018 16:16, Igor Djordjevic wrote:
> >
> > > Unless we reimplement the octopus merge (which works quite a bit
> > > differently from the "rebase merge commit" strategy, even if it is
> > > incremental, too), which has its own
Hi Jake,
On Thu, 8 Mar 2018, Jacob Keller wrote:
> On Thu, Mar 8, 2018 at 3:20 AM, Phillip Wood
> wrote:
> > I did wonder about using 'pick ' for rebasing merges
> > and keeping 'merge ...' for recreating them but I'm not sure if that
> > is a good idea. It has the
Hi Buga,
On Thu, 8 Mar 2018, Igor Djordjevic wrote:
> On 08/03/2018 12:20, Phillip Wood wrote:
> >
> > I did wonder about using 'pick ' for rebasing merges
> > and keeping 'merge ...' for recreating them but I'm not sure if that
> > is a good idea. It has the advantage that the user cannot
Hi Buga,
On Thu, 8 Mar 2018, Igor Djordjevic wrote:
> On 08/03/2018 13:16, Phillip Wood wrote:
> >
> > > I did wonder about using 'pick ' for rebasing merges
> > > and keeping 'merge ...' for recreating them but I'm not sure if that
> > > is a good idea. It has the advantage that the user
Hi Junio,
On Thu, 8 Mar 2018, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> >> If we are talking about a drastic change, a few more days may not be
> >> sufficient, but we are not in a hurry, as this already sounds like a
> >> 2.18 material anyway.
> >
> >
On 08/03/2018 16:16, Igor Djordjevic wrote:
>
> > Unless we reimplement the octopus merge (which works quite a bit
> > differently from the "rebase merge commit" strategy, even if it is
> > incremental, too), which has its own challenges: if there are merge
> > conflicts before merging the last
On Thu, Mar 8, 2018 at 3:20 AM, Phillip Wood wrote:
> On 07/03/18 07:26, Johannes Schindelin wrote:
>> Hi Buga,
>>
>> On Tue, 6 Mar 2018, Igor Djordjevic wrote:
>>
>>> On 06/03/2018 19:12, Johannes Schindelin wrote:
>> And I guess being consistent is pretty
On 08/03/2018 13:16, Phillip Wood wrote:
>
> > Side note: I wonder whether we really need to perform the additional check
> > that ensures that the refers to the rewritten version of the
> > original merge commit's parent.
> >
> > [...]
>
> Oops that was referring to the first side note. I
Hi Phillip and Johannes,
On 08/03/2018 12:20, Phillip Wood wrote:
>
> I did wonder about using 'pick ' for rebasing merges and
> keeping 'merge ...' for recreating them but I'm not sure if that is a
> good idea. It has the advantage that the user cannot specify the wrong
> parents for the merge
Hi Dscho,
On 07/03/2018 08:26, Johannes Schindelin wrote:
>
> > So, it could be something like:
> >
> > merge -C deadbee 123abc:cafecafe 234bcd:bedbedbed
>
> I like where this is heading, too, but I do not think that we can do this
> on a per-MERGE_HEAD basis. The vast majority of merge
On 08/03/18 11:20, Phillip Wood wrote:
> On 07/03/18 07:26, Johannes Schindelin wrote:
>> Hi Buga,
>>
>> On Tue, 6 Mar 2018, Igor Djordjevic wrote:
>>
>>> On 06/03/2018 19:12, Johannes Schindelin wrote:
>> And I guess being consistent is pretty important, too - if you add new
>>
On 07/03/18 07:26, Johannes Schindelin wrote:
> Hi Buga,
>
> On Tue, 6 Mar 2018, Igor Djordjevic wrote:
>
>> On 06/03/2018 19:12, Johannes Schindelin wrote:
>>>
> And I guess being consistent is pretty important, too - if you add new
> content during merge rebase, it should always show
Johannes Schindelin writes:
>> If we are talking about a drastic change, a few more days may not be
>> sufficient, but we are not in a hurry, as this already sounds like a
>> 2.18 material anyway.
>
> It is not at all a drastic change. It will actually make the
Hi Junio,
On Wed, 7 Mar 2018, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> >> OK, does this mean we want to wait before merging the "recreate
> >> merge" topic down to 'next'? For more than a few weeks, it has been
> >> slated for 'next'.
> >
> > Maybe a
Johannes Schindelin writes:
>> OK, does this mean we want to wait before merging the "recreate
>> merge" topic down to 'next'? For more than a few weeks, it has been
>> slated for 'next'.
>
> Maybe a few more days.
> ...
> I want to discuss this in the other
Hi Buga,
On Tue, 6 Mar 2018, Igor Djordjevic wrote:
> On 06/03/2018 19:12, Johannes Schindelin wrote:
> >
> > > > And I guess being consistent is pretty important, too - if you add new
> > > > content during merge rebase, it should always show up in the merge,
> > > > period.
> > >
> > > Yes,
Hi Junio,
On Tue, 6 Mar 2018, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> >> I don't think its possible to guess the semantics of the original merge
> >> as users can use custom merge strategies and amend the result. It would
> >> be possible to detect
Johannes Schindelin writes:
>> I don't think its possible to guess the semantics of the original merge
>> as users can use custom merge strategies and amend the result. It would
>> be possible to detect and unamended '-s ours' merge but special casing
>> that may end
On 06/03/2018 19:12, Johannes Schindelin wrote:
>
> > > And I guess being consistent is pretty important, too - if you add new
> > > content during merge rebase, it should always show up in the merge,
> > > period.
> >
> > Yes, that should make it easy for the user to know what to expect from
>
Hi Phillip & Buga,
On Tue, 6 Mar 2018, Phillip Wood wrote:
> On 02/03/18 23:33, Igor Djordjevic wrote:
> >
> > [...]
> > Otherwise, I would be interested to learn how context/semantics
> > guessing could provide a better default action (without introducing
> > more complexity for might not be
On 02/03/18 23:33, Igor Djordjevic wrote:
> Hi Phillip,
>
>> On Fri, Mar 2, 2018 at 4:36 AM, Phillip Wood wrote:
>>>
It is interesting to think what it means to faithfully rebase a '-s
ours' merge.
>>>
>>> I should have explained that I mean is a faithful rebase one that
>>> adheres to
Hi Igor,
Igor Djordjevic writes:
[...]
> Now, not to get misinterpreted to pick sides in "(re)create" vs
> "rebase" merge commit discussion, I just think these two (should) have
> a different purpose, and actually having both inside interactive rebase
> is what
On 02/03/2018 19:14, Igor Djordjevic wrote:
>
> > > It is interesting to think what it means to faithfully rebase a '-s
> > > ours' merge. In your example the rebase does not introduce any new
> > > changes into branch B that it doesn't introduce to branch A. Had it
> > > added a fixup to branch
Hi Phillip,
> On Fri, Mar 2, 2018 at 4:36 AM, Phillip Wood wrote:
> >
> > > It is interesting to think what it means to faithfully rebase a '-s
> > > ours' merge.
> >
> > I should have explained that I mean is a faithful rebase one that
> > adheres to the semantics of '-s ours' (i.e. ignores
Hi Phillip,
On 02/03/2018 17:00, Jacob Keller wrote:
>
> > It is interesting to think what it means to faithfully rebase a '-s
> > ours' merge. In your example the rebase does not introduce any new
> > changes into branch B that it doesn't introduce to branch A. Had it
> > added a fixup to
On Fri, Mar 2, 2018 at 4:36 AM, Phillip Wood wrote:
> On 02/03/18 11:17, Phillip Wood wrote:
>>
>> On 02/03/18 01:16, Igor Djordjevic wrote:
>>>
>>> Hi Sergey,
>>>
>>> On 01/03/2018 06:39, Sergey Organov wrote:
>> (3) ---X1---o---o---o---o---o---X2
>>
On Fri, Mar 2, 2018 at 3:17 AM, Phillip Wood wrote:
>
> It is interesting to think what it means to faithfully rebase a '-s
> ours' merge. In your example the rebase does not introduce any new
> changes into branch B that it doesn't introduce to branch A. Had it
>
On 02/03/18 11:17, Phillip Wood wrote:
>
> On 02/03/18 01:16, Igor Djordjevic wrote:
>>
>> Hi Sergey,
>>
>> On 01/03/2018 06:39, Sergey Organov wrote:
>>>
> (3) ---X1---o---o---o---o---o---X2
>|\ |\
>| A1---A2---A3---U1 | A1'--A2'--A3'--U1'
On 02/03/18 01:16, Igor Djordjevic wrote:
>
> Hi Sergey,
>
> On 01/03/2018 06:39, Sergey Organov wrote:
>>
(3) ---X1---o---o---o---o---o---X2
|\ |\
| A1---A2---A3---U1 | A1'--A2'--A3'--U1'
| \ |
66 matches
Mail list logo