On 04/10/2016 05:36 PM, Gordon Pettey wrote:
> Or you could just use a branching workflow like Git has great support
> for, and create your overlay as a branch of the main tree you're copying
> ebuilds from. With recent versions, you can even have checkouts of
> different branches from the same tree in different directories, so
> you're not duplicating the the whole repository. Then you could just git
> diff from the master branch, and no need for preserving CVS misbehavior.
>
I suggested this on the bug, but it's not so clear-cut. With a branch,
you have a million other ebuilds sitting around in "your overlay" that
you don't care about. I'm also not sure how the metadata updates would
work; like, if it would be efficient to pull the rsync metadata and then
run `emerge --metadata` or something like that. It wouldn't be fair to
say "just use a branch!" if that's going to mean that somebody's
day-to-day work gets a lot slower.
I would also feel a little guilty saying that the supported way of
extending/modifying the tree (overlays) won't work and you have to
branch off our VCS. I promised to think about it, but haven't had much
inspiration. Here's the best I've got so far.
1. Use git for your ::gentoo tree.
2. Before every sync (git pull), save the current HEAD:
OLD=$(git rev-parse --verify HEAD)
3. git pull
4. Save the new HEAD:
NEW=$(git rev-parse --verify HEAD)
5. Search through the log (between the old HEAD and the new one) for
any files that were modified:
git log $OLD..$NEW --format='' --name-status \
| grep '^M.*ebuild' \
| cut -f2 \
| sort \
| uniq
That gives you a nice list at least, and you can compare it to the files
present in your overlay.
If you add another
| xargs git log --stat $OLD..$NEW
onto the end of that last command, you can see statistics on what
changes were made. (Holy crap do we have a lot of people editing
dependencies without making revision bumps.)
