A few months ago, I started using a graciously provided Linux laptop with a standard install of the Gramps 5.1.5 version. I had been using a heavily patched instance of the same version on a dying Windows 10 laptop.
Is there a way to compare a patched version against the standard download to flag all the changes? (I anticipate some difficulties since the AIO installer archive’s internal arrangement is likely different than where files are eventually installed.)
I’d like to be able to generate a checklist of the patches that had been worth so much effort over time.
The enhancement patches will be needed when I update to the 5.1.6 version. (And some may not make it into 5.2)
I’ve thought about this for myself, and have concluded that I should create my own github repository and use all of its features for tracking my changes. This would also encourage me to contribute any worthwhile changes I may eventually make. But I haven’t done so yet.
There are many ways, and if you have a Windows machine, or partition, my advice is just the same as Nick’s, and use WinMerge. It may work with Wine too, but I haven’t tested that, nor have I searched for a Linux alternative. There is a site named alternative.to that may be helpful here.
If you don’t want to work with git, you can download a zipped copy of the 5.1 branch from GitHub, and use that as a reference.
There are other ways too, but they depend on using the proper git tools. If you clone the repo, check out 5.1, and then overwrite all source code with the patched version. You can then do a git diff to find all the differences, and also use git to reject the changes that you don’t trust.
According to alternative.to, Meld would be a good replacement for WinMerge, and that makes sense to me, when I look at the screens. You can do everything with a good git client too, for which I suggest gitkraken.
And in the end, it all depends on whether you can and want to deal with these kind of workflows.
So @emyoulation what do you see as a change? Is that the code itself, or a change made to the repository, a.k.a. a commit? If it’s the latter, you will need to work with git, because that’s the only way to see changes in the right context of a bug fix or an enhancement.
I applied a lot of patches (such as these) and noted others in a Note attached to a “Gramps” surname person in my main tree, some with XML media objects.
But I failed to note some of the experiments that @SNoiraud has so kindly created. (Sometimes because the expirment touched a broad spectrum of files.)
So… I’m thinking that it may be time to dive deeper into GitHub than I ever wanted.
I suggest diving deeper in the whole git workflow, and building from source. Applying patches on line is a way, for which I didn’t realize that you have experience with, and it’s nice, because GitHub may then run some tests for you, which is not so easy on your own machine, but it still means that you’ll need to download a zipped copy of a particular branch, and after a while that can be quite a boring task. Using a git client, like gitkraken, can make that a bit easier, also because with such a client, switching between branches takes no more than a second or so.
You will need to learn to build and run Gramps from source anyway.
The may be a bit of a risk here, because when I understand things right, the patched version lives on Windows, and the original on Linux. And that means that files may have different line terminators, which may mess up the result of the diff quite a bit.
I was thinking of 1st trying the DIFF on the Windows source directory against a copy of the PortableApps
Since Windows doesn’t have a DIFF tool natively, I was going to try the open source DiffUtils.
But my expectation is that the GrampsPortable is too different and will find massive directory structure differences. So I’ll have to fall back to re-installing 5.1.5 on the machine in another directory. Then fallback to the WinMerge.
(And I will just have to hope that the laptop has enough left in it to survive all the installs.)
WinMerge is open source too, and it will often tell you when it finds differences in line terminators, and ask if you want to ignore them. And if you want, there’s a portable version of it too.
The program also has some nice filters, so that it can automatically ignore irrelevant things like compiled Python code, or git data.
And if you do the comparison on Windows, the line terminator problem may not even show up.
The immediate attraction of the suggested DIFF solution was that it redirected output of the differences to a file. This should make it possible to use that as an indirect reference … even though it require searching the different OS directory structure for the correlating location.
But that command line suggestion was from a linux perspective. I’d need to verify the DiffUtils can do the same as the native DIFF on a linux distro.
The WinMerge feature bullet list has making a patch file too.
Now that (offloading via ZIP) should minimize the stress on the ailing Win box. And eliminate the need to assess DIFF alternatives. Thanks!
Then I will try the Linux DIFF against the directory (unzipped to the existing 5.1.5 GrampsPortable thumbs drive) as the first test.
(If Standard vs. Portable directory structures have too must difference, I can try a re-install of 5.1.5 to a different destination on the Windows box, ZIP it too, and use that as my baseline reference.)