Git tools for managing patchsets

Michael keybounce at gmail.com
Mon Oct 24 16:03:29 PDT 2016


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).

---
Entertaining minecraft videos
http://YouTube.com/keybounce



More information about the macports-dev mailing list