Re: [PATCH v2 7/9] checkout: avoid using the rev_info flag leak_pending

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

 



René Scharfe <l.s.r@xxxxxx> writes:

> diff --git a/builtin/checkout.c b/builtin/checkout.c
> index f9f3797e11..afb225ca79 100644
> --- a/builtin/checkout.c
> +++ b/builtin/checkout.c
> @@ -790,37 +790,26 @@ static void suggest_reattach(struct commit *commit, struct rev_info *revs)
>  static void orphaned_commit_warning(struct commit *old, struct commit *new)
>  {
>  	struct rev_info revs;
>  	struct object *object = &old->object;
> -	struct object_array refs;
>  
>  	init_revisions(&revs, NULL);
>  	setup_revisions(0, NULL, &revs, NULL);
>  
>  	object->flags &= ~UNINTERESTING;
>  	add_pending_object(&revs, object, oid_to_hex(&object->oid));
>  
>  	for_each_ref(add_pending_uninteresting_ref, &revs);
>  	add_pending_oid(&revs, "HEAD", &new->object.oid, UNINTERESTING);

Somewhat unrelated tangent, but I mention it only because that it
appears that the use of leak-pending is closely associated with the
"are these objects all reachable from some ref?" query.  This one of
course is asking that exact question (and the way to ask that in a
script is "rev-list $objects --not --all" to see if anything comes
out). The one in "bundle" we saw earlier is another one.  Even
though the implementation is quite different, everything_local()
shares the same purpose.  

I wonder if we want a single unified implementation of this query so
that reinventions do not have to get the details wrong.

The conversion looks obviously correct.  Thanks.




[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