Re: GC of alternate object store
Dan Johnson writes: > I believe that is bad interaction with "--all" (probably a bug). If I > am remembering correctly, --no-tags is internally a per-remote > setting, so I'm guessing it's not getting set on all remotes here. > > I'll look into this more a bit later tonight. Does fetch --no-tags > work when you specify a remote? Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GC of alternate object store
On Fri, Aug 31, 2012 at 12:26 PM, Oswald Buddenhagen wrote: > On Thu, Aug 30, 2012 at 09:03:34AM -0700, Junio C Hamano wrote: >> Oswald Buddenhagen writes: >> >> >> Doesn't >> >> >> >>git push $over_there 'refs/*:refs/remotes/mine/*' >> >> >> >> push your tag v1.0 to refs/remotes/mine/v1.0 over there? The >> >> version of git I ship seems to do this just fine. >> >> >> > as i wrote before, i'm pulling, not pushing,... >> >> You would need to decline the automatic tag following with --no-tags >> (which in hindsight is misnamed; it really means "do not auto-follow >> tags"), like so: >> >> cd $over_there && >> git fetch --no-tags $my_repository 'refs/*:refs/remotes/mine/*' >> >> Otherwise, you will also get tags in refs/tags/. >> > git seems to be happily ignoring that flag. > git fetch --prune --all --no-tags > still re-populates the tags after i delete them manually. I believe that is bad interaction with "--all" (probably a bug). If I am remembering correctly, --no-tags is internally a per-remote setting, so I'm guessing it's not getting set on all remotes here. I'll look into this more a bit later tonight. Does fetch --no-tags work when you specify a remote? -- -Dan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GC of alternate object store
On Thu, Aug 30, 2012 at 09:03:34AM -0700, Junio C Hamano wrote: > Oswald Buddenhagen writes: > > >> Doesn't > >> > >>git push $over_there 'refs/*:refs/remotes/mine/*' > >> > >> push your tag v1.0 to refs/remotes/mine/v1.0 over there? The > >> version of git I ship seems to do this just fine. > >> > > as i wrote before, i'm pulling, not pushing,... > > You would need to decline the automatic tag following with --no-tags > (which in hindsight is misnamed; it really means "do not auto-follow > tags"), like so: > > cd $over_there && > git fetch --no-tags $my_repository 'refs/*:refs/remotes/mine/*' > > Otherwise, you will also get tags in refs/tags/. > git seems to be happily ignoring that flag. git fetch --prune --all --no-tags still re-populates the tags after i delete them manually. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GC of alternate object store
Oswald Buddenhagen writes: >> Doesn't >> >> git push $over_there 'refs/*:refs/remotes/mine/*' >> >> push your tag v1.0 to refs/remotes/mine/v1.0 over there? The >> version of git I ship seems to do this just fine. >> > as i wrote before, i'm pulling, not pushing,... You would need to decline the automatic tag following with --no-tags (which in hindsight is misnamed; it really means "do not auto-follow tags"), like so: cd $over_there && git fetch --no-tags $my_repository 'refs/*:refs/remotes/mine/*' Otherwise, you will also get tags in refs/tags/. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GC of alternate object store
On Wed, Aug 29, 2012 at 08:52:27AM -0700, Junio C Hamano wrote: > (I won't comment on the other parts in this discussion). > which is kinda unfortunate. ;) > Oswald Buddenhagen writes: > > i did exacty that. the tags are *still* not populated - git just tries > > very hard to treat them specially. > > Doesn't > > git push $over_there 'refs/*:refs/remotes/mine/*' > > push your tag v1.0 to refs/remotes/mine/v1.0 over there? The > version of git I ship seems to do this just fine. > as i wrote before, i'm pulling, not pushing, so any differences could be blamed on that (or git version 1.7.12.23.g948900e). anyway, it seems this new version does fetch the tags under the remotes' namespaces, after all - but it still imports them into the global tag namespace as well, which of course makes a mess with the duplicated tags. and for many repos i'm getting something like this (this is kinda new): Fetching qtbase remote: Counting objects: 62375, done. remote: Compressing objects: 100% (28049/28049), done. remote: Total 55704 (delta 45280), reused 36646 (delta 27368) Receiving objects: 100% (55704/55704), 16.76 MiB | 4.94 MiB/s, done. Resolving deltas: 100% (45280/45280), completed with 3017 local objects. fatal: bad object 90f0f499ec5953d60d616a2ff541ecaf8b0c31a2 error: ../qt5/qtbase did not send all necessary objects both the aggregator and the fetched repos run cleanly through fsck. regards -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GC of alternate object store
Oswald Buddenhagen writes: > On Tue, Aug 28, 2012 at 09:19:53PM +0200, Hallvard Breien Furuseth wrote: > ... >> Junio's proposal partially fixes that: It pushes refs/* instead of >> refs/heads/*, to refs/remotes//. However... >> > i did exacty that. the tags are *still* not populated - git just tries > very hard to treat them specially. Just this part (I won't comment on the other parts in this discussion). Doesn't git push $over_there 'refs/*:refs/remotes/mine/*' push your tag v1.0 to refs/remotes/mine/v1.0 over there? The version of git I ship seems to do this just fine. > and the "stash" file is also ignored, unfortunately. There is a work in progress to do this on 'pu'. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GC of alternate object store (was: Bringing a bit more sanity to $GIT_DIR/objects/info/alternates?)
On Tue, Aug 28, 2012 at 09:19:53PM +0200, Hallvard Breien Furuseth wrote: > Oswald Buddenhagen wrote: > > (...)so the second approach is the "bare aggregator repo" which adds > > all other repos as remotes, and the other repos link back via > > alternates. problems: > > > > - to actually share objects, one always needs to push to the aggregator > > Run a cron job which frequently does that? > nope. i also have separate repos which share the same code, so when i develop it i need to pick between them "live". of course it's unlikely to get conflicts in this case, so the missing object sharing is not that bad (the objects are transferred via format-patch, as i'm rewriting paths anyway), but when it happens it's messy to get out again. > > - tags having a shared namespace doesn't actually work, because the > > repos have the same tags on different commits (they are independent > > repos, after all) > > Junio's proposal partially fixes that: It pushes refs/* instead of > refs/heads/*, to refs/remotes//. However... > i did exacty that. the tags are *still* not populated - git just tries very hard to treat them specially. and the "stash" file is also ignored, unfortunately. > > - one still cannot safely garbage-collect the aggregator, as the refs > > don't include the stashes and the index, so rebasing may invalidate > > these more transient objects. > > Also if you copy a repo (e.g. making a backup) instead of cloning it, > and then start using both, they'll push into the same namespace - > overwriting each other's refs. > right. it's a clear user error, though - i wouldn't *expect* it to work. anyway, i don't have *that* problem, as my aggregator actually pulls, not the other way round. anyway, the bottom line is that using alternates as-is for anything but sharing refs/remotes/origin/* (which i'm assuming to be ff-only) is a recipe for disaster. anything which is supposed to be in any way safe must make the "donor" object store aware of the sharing, which at the very least means setting the proposed append-only flag _by the borrowing_ object store. which means that the info/alternates file should be obfuscated, so people can't edit it manually. > > i would re-propose hallvard's "volatile" alternates (at least i think that's > > what he was talking about two weeks ago): they can be used to obtain > > objects, but every object which is in any way referenced from the current > > clone must be available locally (or from a "regular" alternate). that means > > that diffing, etc. would get objects only temporarily, while cherry-picking > > would actually copy (some of) the objects. this would make it possible to > > "cross-link" repositories, safely and without any "3rd parties". > > I'm afraid that idea by itself won't work:-( > Either you borrow from a store or not. > correct. from "regular" alternates you "borrow", in "volatile" ones you only "peek". so apparently our definitions are different after all. > If Git uses an object from the volatile store, it can't always know if > the caller needs the object to be copied. > it doesn't have to. the distinction comes when creating objects: if an object is only in a volatile alternate, it does not already exist for the purpose of object creation and is thus created locally. regards -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
