[gentoo-dev] [PATCH git-2.eclass 1/2] Clean up non-bare checkout before updating.

[gentoo-dev] [PATCH git-2.eclass 1/2] Clean up non-bare checkout before updating.

[Michał Górny]

Fixes: https://bugs.gentoo.org/show_bug.cgi?id=395247
---
 eclass/git-2.eclass |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/eclass/git-2.eclass b/eclass/git-2.eclass
index f1ed79f..4f0b65b 100644
--- a/eclass/git-2.eclass
+++ b/eclass/git-2.eclass
@@ -344,6 +344,8 @@ git-2_update_repo() {
 	if [[ ${EGIT_LOCAL_NONBARE} ]]; then
 		# checkout master branch and drop all other local branches
 		git checkout ${EGIT_MASTER} || die "${FUNCNAME}: can't checkout master branch ${EGIT_MASTER}"
+		git clean -d -f -x || die "${FUNCNAME}: failed to clean checkout dir"
+
 		for x in $(git branch | grep -v "* ${EGIT_MASTER}" | tr '\n' ' '); do
 			debug-print "${FUNCNAME}: git branch -D ${x}"
 			git branch -D ${x} > /dev/null
-- 
1.7.8.352.g876a6f.dirty

[gentoo-dev] [PATCH git-2.eclass 2/2] When constructing storedir, strip trailing '/.git' directory.

[Michał Górny]

Fixes: https://bugs.gentoo.org/show_bug.cgi?id=386845
---
 eclass/git-2.eclass |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/eclass/git-2.eclass b/eclass/git-2.eclass
index 4f0b65b..44e3476 100644
--- a/eclass/git-2.eclass
+++ b/eclass/git-2.eclass
@@ -278,7 +278,8 @@ git-2_prepare_storedir() {
 		if [[ ${EGIT_PROJECT} ]]; then
 			clone_dir=${EGIT_PROJECT}
 		else
-			clone_dir=${EGIT_REPO_URI##*/}
+			local strippeduri=${EGIT_REPO_URI%/.git}
+			clone_dir=${strippeduri##*/}
 		fi
 		EGIT_DIR=${EGIT_STORE_DIR}/${clone_dir}
 
-- 
1.7.8.352.g876a6f.dirty

Re: [gentoo-dev] [PATCH git-2.eclass 1/2] Clean up non-bare checkout before updating.

[Ulrich Mueller]

>>>>> On Fri, 23 Dec 2011, Michał Górny wrote:

> Fixes: https://bugs.gentoo.org/show_bug.cgi?id=395247

> +		git clean -d -f -x || die "${FUNCNAME}: failed to clean checkout dir"
> +

Why should there be untracked files, in the first place? (In the
"steps to reproduce" of bug 395247 such files are explicitly generated
by the user, which doesn't look like a valid usage case to me.)

Ulrich

Re: [gentoo-dev] [PATCH git-2.eclass 1/2] Clean up non-bare checkout before updating.

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 668 bytes --]

On Fri, 23 Dec 2011 22:09:26 +0100
Ulrich Mueller <ulm@gentoo.org> wrote:

> >>>>> On Fri, 23 Dec 2011, Michał Górny wrote:
> 
> > Fixes: https://bugs.gentoo.org/show_bug.cgi?id=395247
> 
> > +		git clean -d -f -x || die "${FUNCNAME}: failed to
> > clean checkout dir" +
> 
> Why should there be untracked files, in the first place? (In the
> "steps to reproduce" of bug 395247 such files are explicitly generated
> by the user, which doesn't look like a valid usage case to me.)

Yes, it is invalid. Yet I think it's better to clean up just in case
upstream pulling gone wrong (e.g. when upstream does rebase).

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] [PATCH git-2.eclass 1/2] Clean up non-bare checkout before updating.

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1455 bytes --]

On Friday 23 December 2011 16:49:46 Michał Górny wrote:
> On Fri, 23 Dec 2011 22:09:26 +0100 Ulrich Mueller wrote:
> > >>>>> On Fri, 23 Dec 2011, Michał Górny wrote:
> > > Fixes: https://bugs.gentoo.org/show_bug.cgi?id=395247
> > > 
> > > +		git clean -d -f -x || die "${FUNCNAME}: failed to
> > > clean checkout dir" +
> > 
> > Why should there be untracked files, in the first place? (In the
> > "steps to reproduce" of bug 395247 such files are explicitly generated
> > by the user, which doesn't look like a valid usage case to me.)
> 
> Yes, it is invalid. Yet I think it's better to clean up just in case
> upstream pulling gone wrong (e.g. when upstream does rebase).

obviously i disagree.  the point is to not duplicate both the network traffic 
and the on-disk storage between the repos i've already checked out and portage 
(i buy dedicated disks for my source code and it fills up quickly ... often 
times faster than my music collection :P).

imo, the git eclass shouldn't be modifying that repo at all.  instead, it 
should be treating it merely as an object store and then cloning it with 
something like --reference.  if you want to create a new variable for these 
semantics, that's fine (although kind of pointless i think since this clearly 
isn't widely used), but the point of having these per-package repo overrides 
in the first place was to easily share already checked out repos with portage.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]