git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Daniel Jacques <dnj@google.com>
Cc: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	git@vger.kernel.org,
	"Johannes Schindelin" <Johannes.Schindelin@gmx.de>
Subject: Re: [PATCH v6 2/3] Makefile: add Perl runtime prefix support
Date: Mon, 19 Mar 2018 13:41:56 -0700	[thread overview]
Message-ID: <xmqqpo3zu7aj.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <CAD1RUU-K1rFaOEVXE=XZ_gu4ktmaEBGr3wtJvGJd1fivNXa21A@mail.gmail.com> (Daniel Jacques's message of "Mon, 19 Mar 2018 19:17:14 +0000")

Daniel Jacques <dnj@google.com> writes:

>> > 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.

  reply	other threads:[~2018-03-19 20:42 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-19  2:50 [PATCH v6 0/3] RUNTIME_PREFIX relocatable Git Dan Jacques
2018-03-19  2:50 ` [PATCH v6 1/3] Makefile: generate Perl header from template file Dan Jacques
2018-03-19  3:07   ` Eric Sunshine
2018-03-19  2:50 ` [PATCH v6 2/3] Makefile: add Perl runtime prefix support Dan Jacques
2018-03-19 17:14   ` Junio C Hamano
2018-03-19 17:21     ` Daniel Jacques
2018-03-19 19:12   ` Ævar Arnfjörð Bjarmason
2018-03-19 19:14     ` Daniel Jacques
2018-03-19 19:17       ` Daniel Jacques
2018-03-19 20:41         ` Junio C Hamano [this message]
2018-03-19 19:21   ` Ævar Arnfjörð Bjarmason
2018-03-19 19:47     ` Daniel Jacques
2018-03-19 21:32   ` Martin Ågren
2018-03-19 22:07     ` Daniel Jacques
2018-03-19  2:50 ` [PATCH v6 3/3] exec_cmd: RUNTIME_PREFIX on some POSIX systems Dan Jacques
2018-03-19 17:24   ` Junio C Hamano
2018-03-19 17:30     ` Daniel Jacques
2018-03-19 19:27   ` Ævar Arnfjörð Bjarmason
2018-03-19 19:38     ` Daniel Jacques
2018-03-19 17:02 ` [PATCH v6 0/3] RUNTIME_PREFIX relocatable Git Junio C Hamano
2018-03-19 19:30 ` Ævar Arnfjörð Bjarmason

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

  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=xmqqpo3zu7aj.fsf@gitster-ct.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=avarab@gmail.com \
    --cc=dnj@google.com \
    --cc=git@vger.kernel.org \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).