I have no intention of committing those files.
That's exactly the scenario
I'd rather call those additions than changes, as these are all additional files that live in the corresponding port's files directory. So no file under version control is actually changed. Most of these are additional patches that get applied during the patch phase when building the port. The only exception is an .asterisk.makeopts file which is pretty much expendable, as it can easily be recreated.
The benefit is to have your own history with meaningful commits, the ability to track your own changes and easily correct mistakes, and a much easier way to resolve any conflicts should they ever happen. It's nothing you
have to do, just a nice tool. To take full advantage, you'd have to learn how to work with "rebase", e.g. from here:
https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History
A simpler alternative, if you just continue to keep all your changes in the working copy only, is
git stash
. This will be obligatory
if you ever run into a conflict, then you'll have to
git stash
before you can successfully
git pull
. To get your changes back afterwards, write
git stash pop
. In that case, the "stash" is kind of a single commit that will be rebased onto your working copy with "pop". It's your decision whether this is good enough for you. I just recommend the local branch for easy management of several unrelated changes
And from your explanation it seems that I would have to perform additional steps each and every time I update the ports tree, so I don't think it's worth it for the time being.
Uhm, I don't think having to issue two commands (a merge and a rebase) for updating instead of just one pull command is really a drawback
