From: Junio C Hamano <email@example.com> To: Michael Witten <firstname.lastname@example.org> Cc: Johannes Schindelin <email@example.com>, "Brian M. Carlson" <firstname.lastname@example.org>, Pratik Karki <email@example.com>, firstname.lastname@example.org Subject: Re: `--rebase-merges' still failing badly Date: Thu, 11 Oct 2018 08:01:40 +0900 Message-ID: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> Michael Witten <email@example.com> writes: > On Wed, 10 Oct 2018 14:43:46 +0900, Junio wrote: > >> We haven't seen much complaints and breakages reported against the >> two big "rewrite in C" topics around "rebase"; perhaps it is a good >> time to merge them to 'next' soonish to cook them for a few weeks >> before moving them to 'master'? > > In my opinion, the `--rebase-merges' feature has been broken since the > beginning, and the builtin version should be fixed before it is moved > ahead. I'll omit the remainder of the message not because I disagree with your suggested improvements to "rebase-merges" (that conversation should happen primarily with Dscho), but because I need to react to the above three lines. If "rebase-merges" has been broken since the beginning, as long as the "rewrite in C" topics around "rebase" do not make it even worse, I do not think it is a good move to block the topics moving forward. If the feature were so broken that it is not practically useful, then people wouldn't be using it in the versions of Git before the rewrite, so it won't harm anybody if the same feature in the rewritten version is equally (or even more severely) broken, as long as the other parts of the feature works at least equally well compared to the older version. We are not in the business of hostage taking. What *should* block the rewrited version is a regression, i.e. something that used to work well no longer works or works differently in such a way that established workflows need to be adjusted. In any case, suggestions to improve "rebase-merges" is a very much welcome thing to be discussed on the list, so thanks for raising the issue. What I wanted to say is that I do not think that is a reason to keep "rewrite in C" waiting in 'pu'.
next prev parent reply index Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-10-10 5:43 What's cooking in git.git (Oct 2018, #01; Wed, 10) Junio C Hamano 2018-10-10 7:59 ` Ævar Arnfjörð Bjarmason 2018-10-10 15:06 ` Jeff King 2018-10-10 12:57 ` builtin stash/rebase, was " Johannes Schindelin 2018-10-10 13:19 ` Junio C Hamano 2018-10-11 2:18 ` Junio C Hamano 2018-10-10 13:04 ` js/mingw-wants-vista-or-above, " Johannes Schindelin 2018-10-10 13:13 ` Junio C Hamano 2018-10-10 13:58 ` Phillip Wood 2018-10-11 1:54 ` Junio C Hamano 2018-10-11 22:40 ` Junio C Hamano 2018-10-11 22:59 ` [PATCH] diff.c: die on unknown color-moved ws mode Stefan Beller 2018-10-11 23:01 ` Stefan Beller 2018-10-12 1:22 ` Junio C Hamano 2018-10-11 23:06 ` What's cooking in git.git (Oct 2018, #01; Wed, 10) Stefan Beller 2018-10-12 0:51 ` Junio C Hamano 2018-10-12 9:59 ` Phillip Wood 2018-10-12 13:36 ` Junio C Hamano 2018-10-16 13:38 ` Phillip Wood 2018-10-16 17:13 ` Stefan Beller 2018-10-10 14:18 ` Thomas Gummerer 2018-10-11 1:40 ` Junio C Hamano 2018-10-10 18:51 ` `--rebase-merges' still failing badly Michael Witten 2018-10-10 19:00 ` Michael Witten 2018-10-10 23:01 ` Junio C Hamano [this message] 2018-10-11 2:44 ` Michael Witten 2018-10-12 9:11 ` Johannes Schindelin 2018-10-10 18:55 ` What's cooking in git.git (Oct 2018, #01; Wed, 10) Stefan Beller 2018-10-11 2:00 ` Junio C Hamano 2018-10-10 20:38 ` Tim Schumacher 2018-10-10 21:25 ` Johannes Sixt 2018-10-11 1:53 ` Junio C Hamano 2018-10-11 11:16 ` Derrick Stolee 2018-10-14 12:21 ` Duy Nguyen
Reply instructions: You may reply publically 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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ /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
email@example.com mailing list mirror (one of many) Archives are clonable: git clone --mirror https://public-inbox.org/git git clone --mirror http://ou63pmih66umazou.onion/git git clone --mirror http://czquwvybam4bgbro.onion/git git clone --mirror http://hjrcffqmbrq6wope.onion/git Newsgroups are available over NNTP: nntp://news.public-inbox.org/inbox.comp.version-control.git nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git nntp://news.gmane.org/gmane.comp.version-control.git note: .onion URLs require Tor: https://www.torproject.org/ or Tor2web: https://www.tor2web.org/ AGPL code for this site: git clone https://public-inbox.org/ public-inbox