Git tools for managing patchsets

[Ryan Schmidt]

On Oct 24, 2016, at 12:29, Michael <keybounce at gmail.com> wrote:
> 
> 
>> On 2016-10-24, at 10:25 AM, Clemens Lang <cal at macports.org> wrote:
>> 
>> Hi,
>> 
>>> On Mon, Oct 24, 2016 at 09:37:37AM -0700, Michael 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.
>> 
>> If I understand this correctly, this is a problem that applies to
>> repositories of source code, not repositories of build description
>> files. The way we currently keep patches for our ports is putting them
>> next to the Portfiles in what will be the macports-ports Git repository.
>> Consequently, we already have the history of these patchfiles.
>> 
>> As an example, let's consider the yubico-c-client port. It's defined in
>> MacPorts in
>> security/yubico-c-client/Portfile
>> The patches to be applied to the source code of yubico-c-client are
>> under version control in
>> security/yubico-c-client/files
>> which already gives us a history of the patches.
> 
> My understanding -- and maybe this is my error here -- is that your patches have to be constantly rebased onto the current version every time the upstream releases a new version.
> 
> When you rebase, you have new commits, and a new history. So the history of how your patchset has changed over time resets at each rebase at each new upstream release.
> 
> That is my understanding of the issue; if this is wrong, then I'm trying to solve a non-existent problem.
> 
> (And if you don't have that problem, please tell me how you are using rebase and not losing history :-). 

The way that we handle patches in a port's files directory won't change just because we move from svn to git. Or maybe I don't understand what you're saying.