git@vger.kernel.org mailing list mirror (one of many)
 help / Atom feed
From: Michael Witten <mfwitten@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Johannes Schindelin <johannes.schindelin@gmx.de>,
	"Brian M. Carlson" <sandals@crustytoothpaste.net>,
	Pratik Karki <predatoramigo@gmail.com>,
	git@vger.kernel.org
Subject: Re: `--rebase-merges' still failing badly
Date: Thu, 11 Oct 2018 02:44:20 -0000
Message-ID: <9a2bd0246038424ab1cdfa68f07cdd4d-mfwitten@gmail.com> (raw)
In-Reply-To: <xmqqsh1djtij.fsf@gitster-ct.c.googlers.com>

On Thu, 11 Oct 2018 08:01:40 +0900, Junio wrote:

> Michael Witten <mfwitten@gmail.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.
>
> [...]
>
> 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.
>
> [...] I do not think that is a reason to keep "rewrite in C" waiting in
> 'pu'.

* Your logic  is appealing,  and I  nearly pursuaded  myself by  the same
  reasoning to submit my email as  a separate discussion, as you suggest.
  However, what convinced me otherwise is the following:

      The  closer you  move  the rewrite  to  a fast-forward-only  public
      branch  name, the  more  likely downstream  projects  are going  to
      set  up  new,  long-lived  releases around  this  very  useful  but
      nevertheless broken feature.

  The moment you announce a new release, there are going to be a bunch of
  people who grab that release and then  NEVER look back, and so the rest
  of us will be stuck with this problem for who knows how long.

  So, not only is this an appeal  to the authors to fix this problem, but
  its also  an appeal  to you to  make sure that the  next  major release
  includes the fix.

* Also, I say the following without irony or tongue in cheek:

      Maybe, no one  has complained  because  few people  are using  this
      feature yet, or  their commit summaries are  simplistic, or they've
      got workarounds (as I've got).

  Not  only must  this feature  be turned  on explicitly,  but `git'  has
  existed for  over a decade  *without* it;  users who are  interested in
  sophisticated management of commit history have already developed other
  ways  to achieve  the  same result  (I  know I  did),  or their  commit
  messages are  so simplistic that  the bug  is never triggered,  or they
  just plan around it by automatically running a quick search/replace for
  the offending characters or for the irritating "labels".

  If the last decade has shown  us anything, it's that git's fundamentals
  are  so good  that programmers  can get  around any  bug on  their own,
  without having to appeal to others  for help. And, what is a programmer
  if not someone who is used to making things Just Work [Damnit]?

  As an illustration,  consider the recent `break' command  that is being
  added to the repertoire of `git  rebase -i'. Hell, I (and probably many
  others) have been doing that for YEARS with:

      x false

  No need for a "new" command. I bet that 10 years from now,  people will
  *still* be using their own ways,  and will *still* be totally oblivious
  to the existence of `break'.

  That is to say, I wouldn't put much faith in the degree to which people
  report issues. The programming world has a lot of itchy backs, and just
  as many personal inventions for scratching them.

As always, thanks for taking the time to review everyone's input.

Sincerely,
Michael Witten

  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
2018-10-11  2:44     ` Michael Witten [this message]
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 \
    --in-reply-to=9a2bd0246038424ab1cdfa68f07cdd4d-mfwitten@gmail.com \
    --to=mfwitten@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=johannes.schindelin@gmx.de \
    --cc=predatoramigo@gmail.com \
    --cc=sandals@crustytoothpaste.net \
    /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

git@vger.kernel.org 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