Re: [PATCH/RFC] gitweb: Great subroutines renaming

Jakub Narebski <jnareb@gmail.com> writes:

Well, since "git diff master next -- gitweb/" reports empty, the question should not matter at this moment ;-).

Here are my preferences, as a general guideline:

 * If it is a general clean-up (e.g. changing a function
   signature declared in cache.h to tighten constness), I would
   prefer two patches; one to apply on "master", and another one
   created by assuming:

    - your first patch for "master" is accepted;
    - resulting "master" (with your first patch applied) will be
      merged into "next";

   Then the other patch is to clean-up the remaining stuff
   introduced between "master" and "next" (e.g. the function
   whose signature you changed in the first patch may have more
   call sites in "next" you may need to fix them up).

   If you know the specific topic I internally have (you can
   tell them by looking at the merge commits on "next"),
   separating the remainder patch into one per topic would be
   even nicer, but that is probably too much work to ask from
   contributors.

   Most of the time I can do this split myself, though, so it is
   Ok to send a patch to fix things up only in "master", and
   have me find out that it breaks "next", at that time I may
   fix things up myself similarly or I may ask you to send in a
   separete patch in similar spirit to fix up things in "next".

 * If it is a new series, I would prefer things be based on
   "master", unless you use some feature (either internal or
   external) that only exists in "next" or in "pu".

 * If it is a follow-up on stuff still in "next", obviously
   basing the patch on "master" is not possible.

 * If you have independent fix even though we have stuff that
   touch the same general area in "next", it is very much
   preferable if it applies to "master".  A critical fix for
   "next" that does not apply to "master" is taking the fix
   hostage to whatever is in "next".

 * If you need to base on "next", telling me why (i.e. "this
   uses such and such function which are not in master") helps
   me identify which topic I internally have to base a topic to
   house your series in.

 * If you need to base on "pu", think twice.  You will be taken
   hostage by whatever you are basing on (this is the same if
   you base on something in "next", but "pu" is for stuff of
   even more dubious merits than "next").  On the other hand,
   your new series may turn out to be the killer application for
   the feature that was earlier felt not-so-useful and help it
   (and your series) merged to "next".