| 1 |
Or you could just use a branching workflow like Git has great support for, |
| 2 |
and create your overlay as a branch of the main tree you're copying ebuilds |
| 3 |
from. With recent versions, you can even have checkouts of different |
| 4 |
branches from the same tree in different directories, so you're not |
| 5 |
duplicating the the whole repository. Then you could just git diff from the |
| 6 |
master branch, and no need for preserving CVS misbehavior. |
| 7 |
|
| 8 |
On Sun, Apr 10, 2016 at 12:28 PM, Robin H. Johnson <robbat2@g.o> |
| 9 |
wrote: |
| 10 |
|
| 11 |
> On Sun, Apr 10, 2016 at 06:16:05PM +0200, Ulrich Mueller wrote: |
| 12 |
> > Why would you need $Id$ feature for this? "git ls-files -s" gives you |
| 13 |
> > the hash of the blob as well, is more efficient than grep, and even |
| 14 |
> > works recursively on a directory tree. |
| 15 |
> > |
| 16 |
> > $ git ls-files -s -- www-client/seamonkey/seamonkey-2.40.ebuild |
| 17 |
> > 100644 5ecd7709c6c8a316d9f005b4e4a0a54da81eb048 0 |
| 18 |
> www-client/seamonkey/seamonkey-2.40.ebuild |
| 19 |
> Your ls-files doesn't let you track what blob the modified ebuild came |
| 20 |
> from, when it's copied out of the git repo where expansion was |
| 21 |
> happening. |
| 22 |
> |
| 23 |
> If the $Id$ is expanded in rsync, or your local environment, then you |
| 24 |
> copy the file with the expanded $Id$ to an overlay (or another Git |
| 25 |
> environment without expansion enabled), you have preserved the $Id$. |
| 26 |
> |
| 27 |
> Now the user edits it in their overlay, and since the original $Id$ is |
| 28 |
> preserved, when you ask on bugzilla, please submit it as a diff; they |
| 29 |
> can simply do: |
| 30 |
> # diff <(git show $IdHash) $OVERLAY/pn/pv.ebuild |
| 31 |
> |
| 32 |
> |
| 33 |
> -- |
| 34 |
> Robin Hugh Johnson |
| 35 |
> Gentoo Linux: Developer, Infrastructure Lead, Foundation Trustee |
| 36 |
> E-Mail : robbat2@g.o |
| 37 |
> GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 |
| 38 |
> |
| 39 |
> |
Archives