Re: [PATCH] Fix fetch completeness assumptions
- From
Daniel Barkalow <barkalow@iabervon.org>
- Date
- Sep 15, 2005, 16:54 UTC
- Message-ID
- <Pine.LNX.4.63.0509151243020.23242@iabervon.org>
- In-Reply-To
- <20050915150205.65378a65.vsu@altlinux.ru>
On Thu, 15 Sep 2005, Sergey Vlasov wrote:
Show 40 quoted lines
> On Wed, 14 Sep 2005 21:31:42 -0400 (EDT) Daniel Barkalow wrote: > > > Don't assume that any commit we have is complete; assume that any ref > > we have is complete. > > > > Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> > > > > --- > > Only lightly tested, but it seems to work. Marks all of the commits in > > refs, and their ancestors back as far as the date of the commit it's > > processing. If the commit it's processing is marked, it doesn't recurse > > into it. > > Seems to work here too (however, previous playing with git-fetch and > old git-http-fetch left .git/refs/heads/origin.remote pointing to an > incomplete commit, and this greatly confused the new git-http-fetch). > > Junio, probably you can throw away my patches adding --recover (also I > forgot to add Signed-off-by for them...) - the automatic recovery > provided by this patch is better. Still there is some room for > improvement... > > > This should make it very difficult to get it to produce a situation where > > it completes without giving you complete information, and it shouldn't > > process commits that are accessible from refs. > > > > fetch.c | 28 ++++++++++++++++++++++++++-- > > 1 files changed, 26 insertions(+), 2 deletions(-) > > > > 39216139abc4f2759f7b55d11fa2f7e7c155898c > > diff --git a/fetch.c b/fetch.c > > --- a/fetch.c > > +++ b/fetch.c > > @@ -62,11 +62,21 @@ static int process_tree(struct tree *tre > > return 0; > > } > > > > +struct commit_list *complete = NULL; > > static
Yup.
Show 10 quoted lines
> > + if (commit->object.flags & 1) > > + return 0; > > Hmm, I would define some constant for this flag at the top of file: > > /* Object flags */ > #define COMPLETE (1U << 0) > > Otherwise it is hard to see what object flags are used in the code > (only one flag is used currently, but we may need more in the future).
Yup.
Show 19 quoted lines
> > +static int mark_complete(const char *path, const unsigned char *sha1)
> > +{
> > + struct object *obj = parse_object(sha1);
> > + while (obj->type == tag_type) {
> > + obj = ((struct tag *) obj)->tagged;
> > + parse_object(obj->sha1);
> > + }
> > + if (obj->type == commit_type) {
> > + obj->flags |= 1;
> > + insert_by_date((struct commit *) obj, &complete);
> > + }
>
> Dereferencing of tags is already implemented:
>
> struct commit *commit = lookup_commit_reference_gently(sha1, 1);
> if (commit) {
> commit->object.flags |= 1;
> insert_by_date(commit, &complete);
> }Yup. I think I want to untangle some of the functions in commit.c, though, because it wasn't sufficiently clear to me how those functions worked for me to actually use the right one.
-Daniel *This .sig left intentionally blank*