On 2016-10-26, at 12:25 AM, Joshua Root <j...@macports.org> wrote: > On 2016-10-25 10:03 , Michael wrote: >> >> On 2016-10-24, at 2:57 PM, Marko Käning <mk-macpo...@posteo.net> wrote: >> >>> Hi folks, >>> >>> when I read only the first two paragraphs of this thread... >>> >>> On 24 Oct 2016, at 18:37 , Michael <keybou...@gmail.com> wrote: >>>> So since MacPorts is moving to git, and from what I saw in the "how to use >>>> git" docs you mentioned, you apparently want people to work with patchsets >>>> rebased onto the current head from upstream. >>>> >>>> As I was thinking about that, I realized that you lose your history of the >>>> patchset in the process. >>> >>> ... I already got the shivers! My goodness, how much did I enjoy the ease >>> of Mercurial! Loosing history because of a patch set?! >>> :-/ >>> >>> Well, but I think what you, Michael, are describing, is only needed if you >>> work with many patches which aren’t really committed to any repository. >> >> Actually, it's something else. It's the tracking of the history of changes >> when those changes get rebased. >> >> This is not about the port files; those work just fine. This is about the >> patchsets needed to port a program to OS X. >> >> If I have a set of patches to port version 1 of a program to OS X, what >> happens when version 2 of the program comes out? >> >> If you just rebase the patches onto version 2's code, then there is no >> connection between the patches for v1 and v2; there's no good way to compare >> how your patches for version 1 compared to the patches for version 2, or >> version 3. Etc. >> >> The answer is, that there are now two good methods for doing this. Git for >> Windows has one method (in fairness, I did not understand it, it seems >> mostly manual, but has been developed/improved over years), and the >> just-released git-series has a second one (based around extensions to normal >> git commands). > > The real work of updating patchsets (which are effectively the same thing as > a branch) can't really be automated. You have to resolve the conflicts > manually because you have to understand what the patches are actually doing. > > The parts that can be automated are handled by a tool like quilt. It looks > like git-series does something similar but handled more like a real git > branch. > > - Josh
Interesting that you mention "Quilt". There is another tool -- Stacked Git -- that is modeled after Quilt. (I have never used either, and cannot comment) --- Entertaining minecraft videos http://YouTube.com/keybounce _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
