Re:The Not-Forking Tool
by s_gourichon on Sunday June 13, 2021 @01:22PM
(#27494347)
Calling it "not forking" (saying what it's not) instead of what it is adds some unnecessary cognitive burden. (It might be hard to find a good name, still.)
The overall kind of situation it offers to solve is somehow familiar, the questions are relevant. But the way the tool works is unclear. Hints about what it does are in the last section of "Why Not Just Use Git/Fossil/Other VCS?" part.
It might be just me, but perl + "fossil instead of git" skews my bayesian expectations.
Gut feeling is: perhaps the tool was used for a long time, grew organically from a local hack.
Reworking that page in clear sections might be best. Most information is already there, just it would be nice to reorder in very clear sections:
* what problem developers face (is there, in the beginning, not in its own section)
* existing solutions, and for each how it falls short (only hints in "why not..." near the end, mixed with examples)
The idea is that you can have a set of files/folders in your repository that map to an external repository, and you can contribute updates, and also receive updates back and from the external repository by filtering a temporary branch, and then rebasing the changes.
I looked through the documentation and I see you have "Git rebase cannot solve the Not-Forking problem space. Neither can Git submodules."
Could you elaborate on why you think git submodules cannot achieve this?
My understanding of git submodules is that they offer a solution to this problem of external repository sync, although in a not very convenient way.
Re:The Not-Forking Tool
by twic on Sunday June 13, 2021 @02:43PM
(#27495115)
I have read this article, and have no idea at all how the tool actually works.
My guess is that your project contains some sort of pointer to the upstream (a URL for a Git repo or a tarball download, say), plus patches to be applied to it. The tool pulls the upstream and then applies the patches.
If so, in this respect, it is rather like MacPorts, where a portfile specifies the information needed to fetch, checksum, extract, patch, and then build and install a package:
<rant>I wish Debian would stop shipping hacked versions upstream projects. I mean, not stop completely; but to me it seems to be a cultural problem, a bit like NIH. It looks like makework.</rant>
Multiple upstream dependencies: that's a different problem.
Well, your test-and-build system should pull in the latest dependencies on commit, and run the test suite. If tests fail because of incompatible upstream version changes, then you have to pin one or both of the upstream versions, until the incompatibility is resolved.
Not ideal. What if you have 250 upstream dependencies, like Node.js developers have to deal with every day?
Re:The Not-Forking Tool
by pabs3 on Sunday June 13, 2021 @09:34PM
(#27498391)
Debian's patches are generally out of necessity in order to use or support the upstream software in a sane way. Within Debian there is a culture of always sending patches upstream and most of the time patches not being upstream has a reason; for example there could be an unreasonable CLA, upstream might have gone proprietary, upstream might not accept external patches, upstream might not be (very) responsive etc.
I don't mean to knock the Debian maintainers. I have chosen to rely on Debian for at least a couple of decades. I was only bitching because Debian is still my friend (I bitch at my girlfriend too).
Myself and others are always happy to help new people find a way to help out, the #debian-mentors or #debian-welcome IRC channels or the debian-mentors mailing list are good places for that.
The overall kind of situation it offers to solve is somehow familiar, the questions are relevant. But the way the tool works is unclear. Hints about what it does are in the last section of "Why Not Just Use Git/Fossil/Other VCS?" part.
It might be just me, but perl + "fossil instead of git" skews my bayesian expectations.
Gut feeling is: perhaps the tool was used for a long time, grew organically from a local hack.
Reworking that page in clear sections might be best. Most information is already there, just it would be nice to reorder in very clear sections:
* what problem developers face (is there, in the beginning, not in its own section)
* existing solutions, and for each how it falls short (only hints in "why not..." near the end, mixed with examples)
* the principle of the solution to be put forth here (this part is mostly missing, probably a case of https://en.wikipedia.org/wiki/Curse_of_knowledge )
* how this tool is used in practice. This is missing and would be best served with simple but real-worldish examples
Hope this helps.
Since I'm not sure upstream author will see this, reported there as https://lumosql.org/src/not-forking/tktview/f99ea3a437d0a77c...
The idea is that you can have a set of files/folders in your repository that map to an external repository, and you can contribute updates, and also receive updates back and from the external repository by filtering a temporary branch, and then rebasing the changes.
I looked through the documentation and I see you have "Git rebase cannot solve the Not-Forking problem space. Neither can Git submodules."
Could you elaborate on why you think git submodules cannot achieve this?
My understanding of git submodules is that they offer a solution to this problem of external repository sync, although in a not very convenient way.
My guess is that your project contains some sort of pointer to the upstream (a URL for a Git repo or a tarball download, say), plus patches to be applied to it. The tool pulls the upstream and then applies the patches.
If so, in this respect, it is rather like MacPorts, where a portfile specifies the information needed to fetch, checksum, extract, patch, and then build and install a package:
https://guide.macports.org/chunked/reference.phases.html
Multiple upstream dependencies: that's a different problem.
Well, your test-and-build system should pull in the latest dependencies on commit, and run the test suite. If tests fail because of incompatible upstream version changes, then you have to pin one or both of the upstream versions, until the incompatibility is resolved.
Not ideal. What if you have 250 upstream dependencies, like Node.js developers have to deal with every day?
I don't mean to knock the Debian maintainers. I have chosen to rely on Debian for at least a couple of decades. I was only bitching because Debian is still my friend (I bitch at my girlfriend too).
BTW, there are lots of ways to help Debian if you have the time/inclination to get involved.
https://www.debian.org/intro/help
Myself and others are always happy to help new people find a way to help out, the #debian-mentors or #debian-welcome IRC channels or the debian-mentors mailing list are good places for that.