All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sergey Organov <sorganov@gmail.com>
To: Elijah Newren <newren@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 10:29:59 +0300	[thread overview]
Message-ID: <87lew226iw.fsf@osv.gnss.ru> (raw)
In-Reply-To: <CABPp-BE=H-OcvGNJKm2zTvV3jEcUV0L=6W76ctpwOewZg56FKg@mail.gmail.com> (Elijah Newren's message of "Sat, 16 Apr 2022 22:05:46 -0700")

Elijah Newren <newren@gmail.com> writes:

> On Fri, Apr 15, 2022 at 10:41 PM Edmundo Carmona Antoranz
> <eantoranz@gmail.com> wrote:
>>
>> On Fri, Apr 15, 2022 at 10:33 PM Junio C Hamano <gitster@pobox.com> wrote:
>> >
>> > It would be wonderful if a single command like replay can be used to
>> > say "In the old history master..seen I have bunch of merges.  master
>> > used to be M but now it is at N.  Rebuild M..S on top of N _but_
>> > with a bit of twist.  Some of the topics in M...S may have been
>> > merged to 'master' between M..N and the replayed history on top of N
>> > does not want to have a merge from such 'already graduated' topics.
>> > Many topics are updated, either by adding a new commit on top or
>> > completely rewritten, and we want an updated tip of these topic
>> > branches, not the old tip that I merged when I created M..S chain,
>> > when replaying the history on top of N."
>> >
>> > That kind of operation is quite different from what "rebase" does,
>> > and deserves to be under a different name.
>> >
>>
>> Let me work a little bit on your workflow to see what I can do.
>
> 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.

> 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:

https://public-inbox.org/git/87r2oxe3o1.fsf@javad.com/

that at least is safe with respect to user changes.

-- Sergey Organov

  parent reply	other threads:[~2022-04-18  7:33 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 [this message]
2022-04-18 16:27             ` Elijah Newren
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

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

  git send-email \
    --in-reply-to=87lew226iw.fsf@osv.gnss.ru \
    --to=sorganov@gmail.com \
    --cc=eantoranz@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=newren@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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.