Daniel Jacques <[email protected]> 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.
