Re: [PATCH 09/11] Introduce filter_independent() in commit.c

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Thu, 19 Jun 2008, Junio C Hamano wrote:

> Miklos Vajna <vmiklos@xxxxxxxxxxxxxx> writes:
> 
> > This is similar to git-show-branch --independent: It filters out commits
> > which are reachable from any other item from the input list.
> >
> > Signed-off-by: Miklos Vajna <vmiklos@xxxxxxxxxxxxxx>
> > ---
> >  commit.c |   16 ++++++++++++++++
> >  commit.h |    1 +
> >  2 files changed, 17 insertions(+), 0 deletions(-)
> >
> > diff --git a/commit.c b/commit.c
> > index 6052ca3..0dbf4b7 100644
> > --- a/commit.c
> > +++ b/commit.c
> > @@ -705,3 +705,19 @@ int in_merge_bases(struct commit *commit, struct commit **reference, int num)
> >  	free_commit_list(bases);
> >  	return ret;
> >  }
> > +
> > +struct commit_list *filter_independent(unsigned char *head,
> > +	struct commit_list *heads)
> > +{
> > +	struct commit_list *i, *bases, *ret = NULL;
> > +	struct commit_list **pptr = &ret;
> > +
> > +	commit_list_insert(lookup_commit(head), &heads);
> > +
> > +	bases = get_octopus_merge_bases(heads);
> > +
> > +	for (i = heads; i; i = i->next)
> > +		if (!(i->item->object.flags & RESULT))
> > +			pptr = &commit_list_insert(i->item, pptr)->next;
> 
> Hmm.  How well was this function tested?
> 
> Because RESULT is an implementation detail of merge_bases(), I do not
> think we would want to expose it outside of it.

Well, filter_independent() lives in commit.c, too, so it is in the same 
scope as merge_branches().

> More worryingly, the flag is supposed to be cleaned from the objects 
> after get_merge_bases() returns.  I am not sure what you'll learn by 
> looking at the flag here.

That is a valid point, methinks.  Probably the octopus_merge_base and the 
cleanup have to be decoupled here.  The cleanup should be nothing more 
than calling clear_commit_marks() for every head.

A test case would be desirable, but probably pretty complicated.  Hmm.  I 
like tests when they are simple, because they are easy to verify by a 
human.  Miklos, any chance for such a test case?

Ciao,
Dscho

--
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux