Git tools for managing patchsets

Michael keybounce at gmail.com
Wed Oct 26 08:54:23 PDT 2016


On 2016-10-26, at 12:25 AM, Joshua Root <jmr at macports.org> wrote:

> On 2016-10-25 10:03 , Michael wrote:
>> 
>> On 2016-10-24, at 2:57 PM, Marko Käning <mk-macports at posteo.net> wrote:
>> 
>>> Hi folks,
>>> 
>>> when I read only the first two paragraphs of this thread...
>>> 
>>> On 24 Oct 2016, at 18:37 , Michael <keybounce at 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



More information about the macports-dev mailing list