Re: [PATCH v6 2/3] Makefile: add Perl runtime prefix support

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 19, 2018, 20:41 UTC
Message-ID: <xmqqpo3zu7aj.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <CAD1RUU-K1rFaOEVXE=XZ_gu4ktmaEBGr3wtJvGJd1fivNXa21A@mail.gmail.com>

Daniel Jacques <dnj@google.com> writes:

Show 7 quoted lines

>> > The merge conflict becomes a tad easier to deal with, also makes sense
>> > to have gitexecdir after infodir since that's the order we're listing
>> > these in just a few lines earlier, and this is otherwise (mostly)
>> > consistent.
>
> Actually as a quick follow-up question: for these patch sets, is it best
> for me to have them based off of "master", "next", or a different branch?

When you are cooperating with somebody else, e.g. in this case you are planning your changes to work well with the ab/install-symlinks topic, there are three choices, I think.

 (1) Build your topic on 'master'.  From time to time (and
     especially before sending it out to the list), do a trial merge
     of your topic to 'master', 'next' and 'pu' to see how badly it
     interacts with the other topic.

     If the conflicts are not too bad, and if it makes sense for
     your topic to graduate without the other topic being in
     'master', then this is the preferrable approach.

 (2) Build your topic on top of the other's topic.  When the other
     branch gets updated (either by rerolling if it is not yet on
     'next', or by adding a follow up commit), you may need to
     rebase before sending an update.

     As long as you can live without new stuff added to 'master'
     since the other's topic forked from 'master', this is probably
     the second best option.  It definitely is worse than (1) as
     you'd need to rebase on top of other's work, which will become
     impossible once your topic hits 'next'.

 (3) Make a merge of the other's topic into 'master', and then build
     your topic on top of the result.  Keep the updates from the
     other's topic to the minimum once you start working on your
     topic to simplify the task to update your topic.  From time to
     time, do a trial merge to 'master', 'next' and 'pu' to ensure
     you are compatible with the updates made to the other's topic
     since you forked from them.

     As long as the other's topic is already fairly stable, and if
     you need to depend on new stuff added to 'master' since the
     other's topic forked from 'master', this is a workable
     approach.

I suspect that (1) is fine in this case. As to the reordering of gitexecdir_relative thing Ævar mentioned, I agree that such a change is good because the order of the lines in the result makes more sense.

Thanks.