Re: [jgit-dev] GarbageCollectCommand does not prune unreferenced commit

[R�diger Herrmann <ruediger.herrmann@xxxxxx>]

My primary interest was to see when at all JGit considers a commit for garbage collection. However your insights are really welcome.

Thanks again

Rüdiger

---

From: Christian Halstrick <christian.halstrick@xxxxxxxxx>
To: R�diger Herrmann <ruediger.herrmann@xxxxxx>
Cc: Matthias Sohn <matthias.sohn@xxxxxxxxx>; "jgit-dev@xxxxxxxxxxx" <jgit-dev@xxxxxxxxxxx>
Sent: Friday, April 8, 2016 2:36 PM
Subject: Re: [jgit-dev] GarbageCollectCommand does not prune unreferenced commit

One more comment: if you really want to get rid of certain content
which you (maybe accidentally) commited then what you are doing is not
sufficient. The commit object itself will be garbage collected but not
the new content (the blobs) which you committed. That's because these
blobs are still referenced from the index and therefore JGit (and
native git) will not be able to throw away that content. If you would
checkout the new initial commit instead of just updating
refs/heads/master then the checkout would also let the index point to
the content of the initial commit. And then a gc can throw away even
the blobs.
Ciao
  Chris

On Fri, Apr 8, 2016 at 2:19 PM, Christian Halstrick
<christian.halstrick@xxxxxxxxx> wrote:
> To be honest, I was also a little bit of surprised.
>
> But when reading the javadoc it makes sense. The javadoc of says
> "Parse a git revision string and return an object id". Nowhere it is
> mentioned that this objectid does actually exist in the objectdatabase
> of the repo (although you and me somehow expects this). So whenever
> the method can compute an objectid for the input string it will return
> that. If you call
> repo.resolve("a73692b9992fc5d2476f08195a2c0511a1d96d1c") then it is no
> doubt which objectid to return. No need to open pack files, search the
> .git/objects/* file system hierarchy, etc. But If you call
> repo.resolve("HEAD~9") then there is no other way then for the method
> than to go the very expensive way and to resolve HEAD, read the commit
> object HEAD points to, get the objectid of the the first parent, read
> the commitobject this objectid points to, parse that commit, get the
> objectid of the the first parent...... . Even if you say
> repo.resolve("master") and there is a file called
> .git/refs/heads/master containing the string
> "a73692b9992fc5d2476f08195a2c0511a1d96d1c" then a
> ObjectId.fromString("a73692b9992fc5d2476f08195a2c0511a1d96d1c") will
> be returned. It is not checked whether such an object really exists in
> the object database.