git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Elijah Newren <newren@gmail.com>
To: Sergey Organov <sorganov@gmail.com>
Cc: Edmundo Carmona Antoranz <eantoranz@gmail.com>,
	Junio C Hamano <gitster@pobox.com>,
	Git List <git@vger.kernel.org>
Subject: Re: [RFC] introducing git replay
Date: Mon, 18 Apr 2022 09:27:54 -0700	[thread overview]
Message-ID: <CABPp-BGQSN2iRWco4pQCVKA3AM6J0L0vyFMnYdrOgK0Pa26tWw@mail.gmail.com> (raw)
In-Reply-To: <87lew226iw.fsf@osv.gnss.ru>

Hi Sergey,

On Mon, Apr 18, 2022 at 12:30 AM Sergey Organov <sorganov@gmail.com> wrote:
>
> Elijah Newren <newren@gmail.com> writes:
>
[...]
> > Replaying merges is something I've put a little thought into, so allow
> > me to provide some pointers that may help.  Merges need special
> > handling for replaying, and in my opinion, doing either just a new
> > merge of the new trees (what rebase --rebase-merges does), or just
> > reusing existing trees (what you proposed to start this thread) are
> > both suboptimal, though the former is likely to just be annoying and
> > require potentially unnecessary user refixing,
>
> It silently drops user changes as well, and that's the worst thing about
> it, not annoyance.

Yes, I mentioned that later in the email, but omitted it in the
summary you highlight here just because the fixed-tree case was so
much more likely to do it.  Anyway, sorry for the inaccuracy in the
summarized version.

> > whereas the latter can silently discard changes or reintroduce
> > discarded changes and could be dangerous. More details on both of
> > these...
>
> Please consider yet another option:

I linked to where I had given another option.

> https://public-inbox.org/git/87r2oxe3o1.fsf@javad.com/
>
> that at least is safe with respect to user changes.

If you read the suggestion I made (which I'll reinclude here at [1]),
you'll note that I read the old thread you link to with both your and
Phillips' suggestions.  I dug into them with some examples, and came
to the conclusion that we needed something better, as I briefly
commented when proposing my suggested alternative (at [1]).  I
appreciate your suggestion and the time you put into it, but based on
my earlier investigation, I believe my suggestion would be a better
way of preserving user changes in merges and I'll be implementing it.
The fact that Martin (in this thread) independently came up with the
same basic idea and implemented it in jj (though he apparently has
some further tweaks around the object model) and it works well
suggests to me that the idea has some real world testing too that
gives me further confidence in the idea.

[1] https://lore.kernel.org/git/CABPp-BGW39_5r8Lbt3ymR+F_=hWJcf=2e7O75vFNJ=3CEL5s=g@mail.gmail.com/

  reply	other threads:[~2022-04-18 16:28 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-13 16:43 [RFC] introducing git replay Edmundo Carmona Antoranz
2022-04-13 17:05 ` Junio C Hamano
2022-04-15 18:46   ` Edmundo Carmona Antoranz
2022-04-15 20:33     ` Junio C Hamano
2022-04-16  5:35       ` Edmundo Carmona Antoranz
2022-04-16  6:39         ` Junio C Hamano
2022-04-16  7:02           ` Edmundo Carmona Antoranz
2022-04-17  5:05         ` Elijah Newren
2022-04-17  5:37           ` Edmundo Carmona Antoranz
2022-04-17 17:22             ` Martin von Zweigbergk
2022-04-18  7:04               ` Edmundo Carmona Antoranz
2022-04-18  7:29           ` Sergey Organov
2022-04-18 16:27             ` Elijah Newren [this message]
2022-04-18 17:33               ` Sergey Organov
2022-04-20 11:27               ` Tao Klerks
2022-04-21  2:33                 ` Elijah Newren
2022-04-13 17:26 ` rsbecker
2022-04-13 17:30   ` Edmundo Carmona Antoranz
2022-04-13 17:44     ` Edmundo Carmona Antoranz
2022-04-13 17:44 ` Phillip Susi
2022-04-13 17:49   ` Edmundo Carmona Antoranz
2022-04-13 19:07     ` Ævar Arnfjörð Bjarmason
2022-04-13 17:48 ` Junio C Hamano
2022-04-13 17:56   ` Edmundo Carmona Antoranz
2022-04-13 20:06   ` Eric Sunshine

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CABPp-BGQSN2iRWco4pQCVKA3AM6J0L0vyFMnYdrOgK0Pa26tWw@mail.gmail.com \
    --to=newren@gmail.com \
    --cc=eantoranz@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=sorganov@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).