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.
On Sun, Apr 10, 2016 at 12:28 PM, Robin H. Johnson <robb...@gentoo.org> wrote: > On Sun, Apr 10, 2016 at 06:16:05PM +0200, Ulrich Mueller wrote: > > Why would you need $Id$ feature for this? "git ls-files -s" gives you > > the hash of the blob as well, is more efficient than grep, and even > > works recursively on a directory tree. > > > > $ git ls-files -s -- www-client/seamonkey/seamonkey-2.40.ebuild > > 100644 5ecd7709c6c8a316d9f005b4e4a0a54da81eb048 0 > www-client/seamonkey/seamonkey-2.40.ebuild > Your ls-files doesn't let you track what blob the modified ebuild came > from, when it's copied out of the git repo where expansion was > happening. > > If the $Id$ is expanded in rsync, or your local environment, then you > copy the file with the expanded $Id$ to an overlay (or another Git > environment without expansion enabled), you have preserved the $Id$. > > Now the user edits it in their overlay, and since the original $Id$ is > preserved, when you ask on bugzilla, please submit it as a diff; they > can simply do: > # diff <(git show $IdHash) $OVERLAY/pn/pv.ebuild > > > -- > Robin Hugh Johnson > Gentoo Linux: Developer, Infrastructure Lead, Foundation Trustee > E-Mail : robb...@gentoo.org > GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 > >
