git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Lars Hjemli" <lh@elementstorage.no>
To: "Junio C Hamano" <gitster@pobox.com>
Cc: "Ingo Molnar" <mingo@elte.hu>, "SZEDER Gábor" <szeder@ira.uka.de>,
	git@vger.kernel.org
Subject: Re: [PATCH] builtin-branch.c: optimize --merged and --no-merged
Date: Thu, 24 Jul 2008 09:16:22 +0200	[thread overview]
Message-ID: <8c5c35580807240016y75b69f69h4af47844f57f4539@mail.gmail.com> (raw)
In-Reply-To: <7vtzeg9rhh.fsf_-_@gitster.siamese.dyndns.org>

On Thu, Jul 24, 2008 at 12:15 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Instead, we can let the revision machinery traverse the history as if we
> are running:
>
>    $ git rev-list --branches --not $commit
>
> by queueing the tips of branches we encounter as positive refs (this
> mimicks the "--branches" option in the above command line) and then
> appending the merge_filter_ref commit as a negative one, and finally
> calling prepare_revision_walk() to limit the list..

Nice.


> @@ -213,6 +211,7 @@ static int append_ref(const char *refname, const unsigned char *sha1, int flags,
>  {
>        struct ref_list *ref_list = (struct ref_list*)(cb_data);
>        struct ref_item *newitem;
> +       struct commit *commit;
>        int kind;
>        int len;
>        static struct commit_list branch;

I think you can drop the 'branch' here.


> @@ -239,12 +242,8 @@ static int append_ref(const char *refname, const unsigned char *sha1, int flags,
>                branch.item = lookup_commit_reference_gently(sha1, 1);
>                if (!branch.item)
>                        die("Unable to lookup tip of branch %s", refname);

..and here.


-               if (merge_filter == SHOW_NOT_MERGED &&
-                   has_commit(merge_filter_ref, &branch))
-                       return 0;
-               if (merge_filter == SHOW_MERGED &&
-                   !has_commit(merge_filter_ref, &branch))
-                       return 0;
+               add_pending_object(&ref_list->revs,
+                                  (struct object *)branch.item, refname);


..and use 'commit' instead of 'branch.item' here.


> @@ -305,7 +304,13 @@ static void print_ref_item(struct ref_item *item, int maxwidth, int verbose,
>  {
>        char c;
>        int color;
> -       struct commit *commit;
> +       struct commit *commit = item->commit;
> +
> +       if (merge_filter != NO_FILTER) {
> +               int is_merged = !!(item->commit->object.flags & UNINTERESTING);
> +               if (is_merged != (merge_filter == SHOW_MERGED))
> +                       return;
> +       }


A possible issue here is that `git branch -v --[no]-merged` might use
a wrong maxwidth, but I'm not sure if it's even worth fixing.

Thanks for cleaning up my mess.
--
larsh

  reply	other threads:[~2008-07-24  7:17 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-23 13:05 q: faster way to integrate/merge lots of topic branches? Ingo Molnar
2008-07-23 13:17 ` Ingo Molnar
2008-07-23 13:49   ` Ingo Molnar
2008-07-23 14:47     ` Jay Soffian
2008-07-23 14:56       ` Ingo Molnar
2008-07-23 15:06         ` Ingo Molnar
2008-07-23 13:40 ` Andreas Ericsson
2008-07-23 14:02   ` Ingo Molnar
2008-07-23 14:57   ` Miklos Vajna
2008-07-23 13:41 ` Sergey Vlasov
2008-07-23 14:09   ` Ingo Molnar
2008-07-23 14:14     ` Ingo Molnar
2008-07-23 13:56 ` SZEDER Gábor
2008-07-23 14:04   ` Ingo Molnar
2008-07-23 17:59     ` Junio C Hamano
2008-07-23 22:09       ` [PATCH 1/2] builtin-branch.c: remove unused code in append_ref() callback function Junio C Hamano
2008-07-23 22:15       ` [PATCH] builtin-branch.c: optimize --merged and --no-merged Junio C Hamano
2008-07-24  7:16         ` Lars Hjemli [this message]
2008-07-24  8:29         ` Nanako Shiraishi
2008-07-24 10:03           ` Lars Hjemli
2008-07-24 15:29       ` q: faster way to integrate/merge lots of topic branches? Ingo Molnar
2008-07-23 18:04     ` Linus Torvalds
2008-07-23 18:12       ` Linus Torvalds
2008-07-23 20:01     ` Junio C Hamano
2008-07-24 15:27       ` Ingo Molnar
2008-07-25  8:46         ` Junio C Hamano
2008-07-23 14:06 ` Björn Steinbrink
2008-07-23 14:06 ` Santi Béjar
2008-07-23 17:59 ` Linus Torvalds
2008-07-23 19:09   ` Pierre Habouzit
2008-07-23 20:27     ` Pierre Habouzit
2008-07-23 20:40       ` Pierre Habouzit

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8c5c35580807240016y75b69f69h4af47844f57f4539@mail.gmail.com \
    --to=lh@elementstorage.no \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=mingo@elte.hu \
    --cc=szeder@ira.uka.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).