Junio C Hamano, Sun, Sep 09, 2007 04:10:44 +0200: > Alex Riesen <raa.lkml@xxxxxxxxx> writes: > > > If that will be the case git-p4-import.bat (yes, just a script of > > mine) will break because it has its namespace directly in $GIT_DIR > > (i.e. .git/p4/*) and stores there backup references. It is just a > > someones (ok, it is mine) script, but maybe there are others, who > > expect that plumbing level git-update-ref just do what its told. > > That makes me realize that rejecting anything other than what I > suggested is a good idea, as it avoids mistakes like the one you > just made. The fact is, that things that are reachable only > from .git/p4/* are subject to be pruned. I'd suggest you move > them to somewhere under .git/refs, say, .git/refs/p4/*. Oh, I do have everything which have to be persistent in refs/p4import/*. But there are also things similar to MERGE_HEAD (backup references and the shortcut reference to the commit of the most recent imported state, which can be accessed by p4/IMPORT). It is no problem pruning them. > Neither ORIG_HEAD and FETCH_HEAD protects objects for the same > reason (although HEAD does). And that is actually what we want, > as "git fetch" followed immediately by "git prune" should be > able to get rid of what was fetched. the point of p4/IMPORT exactly - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
