| 1 |
On Friday 23 December 2011 16:49:46 Michał Górny wrote: |
| 2 |
> On Fri, 23 Dec 2011 22:09:26 +0100 Ulrich Mueller wrote: |
| 3 |
> > >>>>> On Fri, 23 Dec 2011, Michał Górny wrote: |
| 4 |
> > > Fixes: https://bugs.gentoo.org/show_bug.cgi?id=395247 |
| 5 |
> > > |
| 6 |
> > > + git clean -d -f -x || die "${FUNCNAME}: failed to |
| 7 |
> > > clean checkout dir" + |
| 8 |
> > |
| 9 |
> > Why should there be untracked files, in the first place? (In the |
| 10 |
> > "steps to reproduce" of bug 395247 such files are explicitly generated |
| 11 |
> > by the user, which doesn't look like a valid usage case to me.) |
| 12 |
> |
| 13 |
> Yes, it is invalid. Yet I think it's better to clean up just in case |
| 14 |
> upstream pulling gone wrong (e.g. when upstream does rebase). |
| 15 |
|
| 16 |
obviously i disagree. the point is to not duplicate both the network traffic |
| 17 |
and the on-disk storage between the repos i've already checked out and portage |
| 18 |
(i buy dedicated disks for my source code and it fills up quickly ... often |
| 19 |
times faster than my music collection :P). |
| 20 |
|
| 21 |
imo, the git eclass shouldn't be modifying that repo at all. instead, it |
| 22 |
should be treating it merely as an object store and then cloning it with |
| 23 |
something like --reference. if you want to create a new variable for these |
| 24 |
semantics, that's fine (although kind of pointless i think since this clearly |
| 25 |
isn't widely used), but the point of having these per-package repo overrides |
| 26 |
in the first place was to easily share already checked out repos with portage. |
| 27 |
-mike |
Archives