Discussion:
Makefile.am and patch orthogonality
Anton Shepelev
2017-06-21 20:47:32 UTC
Permalink
Hello, all

Contextual diff-files a very good means of collabo-
rative development whenever they are used with
source code, but I have a problem with .am files.
If two patches should add new source files to the
same directory, they will also have to modify ac-
cordingly the Makefile.am that lists the sources for
that location, and that is *very* likely to cause a
conflict.

What should you recommend to prevent Makefile.am
from becoming the bottleneck of collaborative devel-
opment and patch isolation?

I am especially interested in this file:

https://sourceforge.net/p/dosbox/code-0/HEAD/tree/dosbox/trunk/src/gui/Makefile.am

How can two (or more) patches add new files to
libgui_a_SOURCES independently of one another?
--
Please, do not forward replies to my e-mail.
Nick Bowler
2017-06-22 03:01:09 UTC
Permalink
Contextual diff-files a very good means of collaborative development
whenever they are used with source code, but I have a problem with
.am files. If two patches should add new source files to the same
directory, they will also have to modify accordingly the Makefile.am
that lists the sources for that location, and that is *very* likely
to cause a conflict.
True, but the resolution is normally trivial.
What should you recommend to prevent Makefile.am from becoming the
bottleneck of collaborative development and patch isolation?
Since patch/diff work line-by-line, a common way to reduce merge
conflicts in this kind of a list is to have one filename per line.
A convention to keep the list sorted can help as then new files
aren't always added to the end.

You can also setup a custom merge handler in git.

Cheers,
Nick
Anton Shepelev
2017-06-22 10:26:15 UTC
Permalink
Post by Nick Bowler
Contextual diff-files a very good means of collab-
orative development whenever they are used with
source code, but I have a problem with .am files.
If two patches should add new source files to the
same directory, they will also have to modify ac-
cordingly the Makefile.am that lists the sources
for that location, and that is *very* likely to
cause a conflict.
True, but the resolution is normally trivial.
Trivial but manual, which some maintainers dislike
so much as to accept only those patches as do not
conflict with one another.
Post by Nick Bowler
What should you recommend to prevent Makefile.am
from becoming the bottleneck of collaborative de-
velopment and patch isolation?
Since patch/diff work line-by-line, a common way to
reduce merge conflicts in this kind of a list is to
have one filename per line. A convention to keep
the list sorted can help as then new files aren't
always added to the end.
That was my idea as well, but if the changes are not
separated by the context range they will still con-
flict. Thanks for the advice, I will try to per-
suade the maintainersto do at least that.
Post by Nick Bowler
You can also setup a custom merge handler in git.
I do not maintain the project, so I can't.
--
Please, do not forward replies to the list to my e-mail.
Loading...