Git tools for managing patchsets

[Lawrence Velázquez]

> On Oct 24, 2016, at 7:03 PM, Michael <keybounce at gmail.com> wrote:
> 
>> On 2016-10-24, at 2:57 PM, Marko Käning <mk-macports at posteo.net> wrote:
>> 
>> 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.

The history is tracked by the MacPorts repository.

> This is not about the port files; those work just fine. This is about
> the patchsets needed to port a program to OS X.

There is no difference.

> 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?

The maintainer adjusts the patches for v2, adds some new ones, removes
ones that are no longer needed, and commits the new set of patches to
the repository. No history is lost.

> If you just rebase the patches onto version 2's code, then there is no
> connection between the patches for v1 and v2

Yes, there is. They are linked by the MacPorts repository history.

> there's no good way to compare how your patches for version 1 compared
> to the patches for version 2, or version 3. Etc.

Diff between the commit that updates the port to v2, and its immediate
parent.

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

Not seeing how either of those tools applies to us.

vq