Git development
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Jari Aalto <jari.aalto@cante.net>, git@vger.kernel.org
Subject: Re: [PATCH] git-rebase.sh: Use POSIX/Susv command substitution instead of backticks
Date: Tue, 05 Feb 2008 18:03:43 -0800	[thread overview]
Message-ID: <7vve526dts.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <7vhcgm7vdx.fsf@gitster.siamese.dyndns.org> (Junio C. Hamano's message of "Tue, 05 Feb 2008 16:59:06 -0800")

Junio C Hamano <gitster@pobox.com> writes:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> And then you have to do it for all scripts in one go.  Mind you, it is not 
>> really complicated: just one call to perl.
>
> Please do not do this.  If other people have pending changes,
> "cleanup for clean-up's sake" would create conflicts for no good
> reason.
>
> There are only two cases such a clean-up patch is good:
>
>  (1) When the maintainer is not yet accepting any patches after
>      a release-freeze and there is no pending patches from the
>      community, and/or if you can convince people with pending
>      patches to rebase on top of the clean-up because the
>      current codebase is so unmaintainably bad, then a
>      whole-tree clean-up patch should go in before anything
>      else, forcing everybody to rebase on top of it;
>
>  (2) If you will be working on the code in an area, you may want
>      to have the first one in the series a "pure clean-up and
>      nothing else" of the whole area, and then build your real
>      changes on top.  You still need to coordinate with people
>      whose patches may get hit by your clean-ups, but you have
>      to do this anyway because you will have conflicts from your
>      "real changes".
>
> Any other "clean-up patch" would result in a not-so-appreciated
> code churn.  Please don't encourage it.

Just to make sure Jari does not get a wrong idea,

My "Please don't" is meant against Johannes's "Do it all if you
do it".

If Jari did the patch as the first step of making real changes
to "git rebase" (making -i not forcing -m, perhaps), it is the
right thing to have a clean-up patch as a preparatory step,
before starting the real work in later patches in the series.
And such a clean-up patch should not inflict useless code churn
on other commands.

So a single patch only to git-rebase is acceptable if that is
what Jari is planning to do: preparatory clean-up before
bringing a real improvement in.

  reply	other threads:[~2008-02-06  2:04 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-05 22:08 [PATCH] git-rebase.sh: Use POSIX/Susv command substitution instead of backticks Jari Aalto
2008-02-05 22:27 ` Johannes Schindelin
2008-02-05 22:53   ` Jari Aalto
2008-02-05 23:06     ` Johannes Schindelin
2008-02-06  0:59       ` Junio C Hamano
2008-02-06  2:03         ` Junio C Hamano [this message]
2008-02-06  9:23       ` Ralf Wildenhues

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=7vve526dts.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=jari.aalto@cante.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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox