Note: I'm not talking about rebasing merges anymore in this thread, but I thought there was a useful how-we're-communicating subthread that's worth addressing to see if we can make that part work better... On Mon, Feb 27, 2023 at 9:17 AM Sergey Organov <sorganov@xxxxxxxxx> wrote: > > Elijah Newren <newren@xxxxxxxxx> writes: > > > On Sun, Feb 26, 2023 at 1:29 AM Sergey Organov <sorganov@xxxxxxxxx> wrote: > >> > >> Elijah Newren <newren@xxxxxxxxx> writes: > >> > >> > On Sat, Feb 25, 2023 at 7:15 AM Sergey Organov <sorganov@xxxxxxxxx> wrote: > >> >> > >> >> Elijah Newren <newren@xxxxxxxxx> writes: > >> >> > >> >> > On Fri, Feb 24, 2023 at 2:06 PM Sergey Organov <sorganov@xxxxxxxxx> wrote: > >> >> >> > >> >> >> Elijah Newren <newren@xxxxxxxxx> writes: > >> >> > >> >> [...] > >> >> > >> >> > Please, go read at least [1] to see Johannes comments about how the > >> >> > prior proposals don't work beyond simple cases. [...] > >> Except the method discussed does achieve exactly that according to the > >> evidence gathered at the time of debates, and here is confirmation (from > >> Johannes himself) from the reference you provided: > > > > I'm glad you read it. :-) > > In fact I didn't read it, I rather re-read it ;-) > > (I'm in the CC list there, so it should not have been a surprise I did > read it then.) I knew you were on the CC, I just didn't believe at the time that you could have read that email and still claimed that "As for Dscho results specifically, I've got an impression that he never needed rebasing of merges in the first place", so I assumed you had skipped that email or only lightly skimmed it. I'm still quite surprised, but clearly my assumption that you read the email was wrong. Sorry about that. > >> Setting this back into perspective, in comparison to blind re-merge, > >> that fails to keep user changes even when no conflicts at all exist, and > >> even when it's applied at the same place in the history, the discussed > >> method is a *huge* step forward, especially if re-merge is kept as a > >> fallback strategy. > > > > The use of superlatives and asterisks doesn't change my opinion; I'm > > still skeptical that the given strategy is overall a step forward, let > > alone a large one. > > You just repeat saying the same thing, without any further arguments? > OK, thank you for your opinion anyway. That exactly mirrors how I've felt about your emails in this thread. You are right that I'm not going into detail either...but why would I? * I'm not trying to convince you to implement these ideas or change your own implementation, especially since: * You've previously said you aren't even planning on working on this[1]. Of course, you can easily ask why I would think you might provide details when I was not providing any. Well, from my viewpoint: * You did say you were hoping someone else would work on this problem[1,2,& end of this email], and I've expressed interest in working on the problem space. * If you want someone to work on your ideas, using your particular favored approach, for free, then you need to convince them that your approach is worth investing in * I have read the old proposals, in detail, and stated I don't believe in them. * You didn't try to address my concerns beyond simply reasserting that the ideas in the original proposals were good, and seemed to be more interested in discrediting or minimizing my concerns (e.g. asking why I "hated diffs from merge to either parent") than in learning about or addressing them. I think your intentions are good (you're trying to solve a big problem in Git), I'm just a little worried about the execution (e.g. brushing aside my concerns so folks won't pay attention to them while actively recruiting eager contributors, with the plan to send them down what I believe is a dead-end path). If it was just you going down this path, I wouldn't be so concerned. Personally, I pursue a *lot* of my own bad ideas, and learn in the process that they were bad. Also, if you showed some willingness to entertain that I might be right that the old proposals are bad, and could communicate that to new contributors and let them decide, I would have dropped out of the thread sooner and just let you do your thing. The way you've responded in this thread doesn't seem unique to our interactions; it reminds me of an interaction you had with Junio at [3]. He suggested there were some code issues. You could have asked what they were and maybe learned how to improve things. Or maybe you could have learned that he just had a specific misunderstanding which could have been corrected if you asked some questions to find out what he was thinking. Instead, you simply asserted that things were fine and dismissed his concerns. I think it was a lost opportunity. Now, it's fully possible here that I've misunderstood your purpose; if so, I apologize. The above was the understanding I was working off of; maybe knowing that will help you understand my responses. [1] stated in final paragraph of https://lore.kernel.org/git/87zgkh9buq.fsf@xxxxxxxxxxx/ [2] hinted at in final paragraph of https://lore.kernel.org/git/87bklilnvp.fsf@xxxxxxxxxxx/ [3] https://lore.kernel.org/git/87wna3jwx8.fsf@xxxxxxxxxxx/ > > (I do agree we have a huge problem and thus that a huge step forward > > theoretically could be taken, I just don't see this as it.) > > It works. Really. > > > But I've stated that more than enough, and no one is producing patches > > on this topic right now, so I'll drop out of this thread. > > OK, I participate only in hope that there will be somebody who actually > cares enough to implement it. Maybe it will be me, maybe not, and I > already got it that neither you nor the original author of git-rebase > are interested. Correct, I'm not interested in implementing it that particular way, though I will be implementing it in what I feel is the right way. Anyway, I hope something I said above helps in some way. Even if not, I wish you the best of luck on your efforts.
