All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Cc: Karthik Nayak <karthik.188@gmail.com>, Git <git@vger.kernel.org>,
	Christian Couder <christian.couder@gmail.com>
Subject: Re: [PATCH v2 00/10] port branch.c to use ref-filter's printing options
Date: Mon, 12 Oct 2015 11:59:15 -0700	[thread overview]
Message-ID: <xmqq37xfncak.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <vpq7fms9cjs.fsf@grenoble-inp.fr> (Matthieu Moy's message of "Mon, 12 Oct 2015 20:17:27 +0200")

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

> Karthik Nayak <karthik.188@gmail.com> writes:
>
>> On Mon, Oct 12, 2015 at 6:06 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Karthik Nayak <karthik.188@gmail.com> writes:
>>>
>>>> On Fri, Oct 9, 2015 at 11:59 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>>> ...
>>>> Also does it make sense to integrate these changes here? Or would you like to
>>>> have another series on this?
>>>
>>> I do not think you would want to ask that question, as my answer
>>> would most likely be "The most preferable would be a series to clean
>>> up the existing codepath that deals with %(align) first, on top of
>>> which everything in flight that is not yet in 'next' is rebased."
>>
>> Ah, but I might take a while to get there, So I'd rather push code which
>> is almost ready and work on that slowly, if that's ok?
>
> That's OK to me. The "most preferable way" above would lead to a cleaner
> history, but also more work for you and for me as a reviewer.

I do not think the cleanliness of the resulting history is of prime
concern.  At least, that was not where my preference came from.

If you design a new infrastructure to help refactoring early
(i.e. before adding many copies of code that need to be cleaned up
later), it would make the work of reviewing of the design of the
helper and refactoring using that helper smaller, not larger.  And
the new codepaths that use the helper would become easier to follow
(otherwise we wouldn't be doing such a refactoring in the first
place), making the reviews easier.  That is where my preference
comes from.

There _is_ a sunk-cost that has already been invested in reviewing
the older round that added code that needs to be cleaned up; there
are some parts other than the "need to be cleaned-up" parts that we
would feel confortable having in the reroll without having to
re-review them.  I do not know if that is a very high cost, though,
especially for those who have already seen the previous rounds.

Anyway, I wouldn't insist and we can go either way.

  reply	other threads:[~2015-10-12 18:59 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-08  9:17 [PATCH v2 00/10] port branch.c to use ref-filter's printing options Karthik Nayak
2015-10-08  9:17 ` [PATCH v2 01/10] ref-filter: implement %(if), %(then), and %(else) atoms Karthik Nayak
2015-10-08 18:48   ` Matthieu Moy
2015-10-10 16:22     ` Karthik Nayak
2015-10-08 19:19   ` Matthieu Moy
2015-10-10 17:12     ` Karthik Nayak
2015-10-08  9:17 ` [PATCH v2 02/10] ref-filter: implement %(if:equals=<string>) and %(if:notequals=<string>) Karthik Nayak
2015-10-08 18:51   ` Matthieu Moy
2015-10-10 17:22     ` Karthik Nayak
2015-10-08  9:17 ` [PATCH v2 03/10] ref-filter: add support for %(refname:dir) and %(refname:base) Karthik Nayak
2015-10-08  9:17 ` [PATCH v2 04/10] ref-filter: modify "%(objectname:short)" to take length Karthik Nayak
2015-10-08 18:58   ` Matthieu Moy
2015-10-10 18:15     ` Karthik Nayak
2015-10-11 16:05       ` Matthieu Moy
2015-10-11 17:44         ` Karthik Nayak
2015-10-08  9:18 ` [PATCH v2 05/10] ref-filter: adopt get_head_description() from branch.c Karthik Nayak
2015-10-08 19:01   ` Matthieu Moy
2015-10-10 18:17     ` Karthik Nayak
2015-10-08  9:18 ` [PATCH v2 06/10] ref-filter: introduce format_ref_array_item() Karthik Nayak
2015-10-08  9:18 ` [PATCH v2 07/10] ref-filter: make %(upstream:track) prints "[gone]" for invalid upstreams Karthik Nayak
2015-10-08 18:40   ` Matthieu Moy
2015-10-10 18:19     ` Karthik Nayak
2015-10-11 16:12       ` Matthieu Moy
2015-10-11 16:16         ` [PATCH 1/3] fixup: use xstrfmt instead of fixed-size buf + sprintf + xstrdup Matthieu Moy
2015-10-11 16:16           ` [PATCH 2/3] ref-filter: allow porcelain to translate messages in the output Matthieu Moy
2015-10-11 19:25             ` Karthik Nayak
2015-10-11 16:16           ` [PATCH 3/3] branch, tag: use porcelain output Matthieu Moy
2015-10-12 17:45           ` [PATCH 1/3] fixup: use xstrfmt instead of fixed-size buf + sprintf + xstrdup Junio C Hamano
2015-10-12 18:01             ` Karthik Nayak
2015-10-11 17:46         ` [PATCH v2 07/10] ref-filter: make %(upstream:track) prints "[gone]" for invalid upstreams Karthik Nayak
2015-10-11 18:10           ` Matthieu Moy
2015-10-11 19:38             ` Karthik Nayak
2015-10-08  9:18 ` [PATCH v2 08/10] ref-filter: add support for %(upstream:track,nobracket) Karthik Nayak
2015-10-08 19:17   ` Matthieu Moy
2015-10-08 19:19     ` Matthieu Moy
2015-10-13 18:13   ` Karthik Nayak
2015-10-13 18:54     ` Matthieu Moy
2015-10-13 19:09       ` Junio C Hamano
2015-10-14  6:12       ` Karthik Nayak
2015-10-08  9:18 ` [PATCH v2 09/10] branch: use ref-filter printing APIs Karthik Nayak
2015-10-13 16:31   ` Junio C Hamano
2015-10-13 17:43     ` Karthik Nayak
2015-10-08  9:18 ` [PATCH v2 10/10] branch: implement '--format' option Karthik Nayak
2015-10-08 12:27 ` [PATCH v2 00/10] port branch.c to use ref-filter's printing options Matthieu Moy
2015-10-08 13:17   ` Karthik Nayak
2015-10-08 16:09   ` Karthik Nayak
2015-10-08 17:10     ` Matthieu Moy
2015-10-08 17:28       ` Karthik Nayak
2015-10-08 18:26         ` Matthieu Moy
2015-10-08 18:35         ` Junio C Hamano
2015-10-09  8:22           ` Matthieu Moy
2015-10-09 18:29             ` Junio C Hamano
2015-10-11 12:48               ` Karthik Nayak
2015-10-11 16:21                 ` Matthieu Moy
2015-10-11 18:38                   ` Karthik Nayak
2015-10-11 19:32                     ` Matthieu Moy
2015-10-11 19:38                       ` Karthik Nayak
2015-10-12  0:36                 ` Junio C Hamano
2015-10-12 17:48                   ` Karthik Nayak
2015-10-12 18:17                     ` Matthieu Moy
2015-10-12 18:59                       ` Junio C Hamano [this message]
2015-10-12 19:07                         ` Matthieu Moy
2015-10-18 19:07                           ` Karthik Nayak
2015-10-19  4:44                             ` Junio C Hamano
2015-10-19  8:12                               ` Matthieu Moy
2015-10-20 20:53                                 ` Karthik Nayak

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=xmqq37xfncak.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=Matthieu.Moy@grenoble-inp.fr \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=karthik.188@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.