From: John Keeping <john@keeping.me.uk>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Martin von Zweigbergk <martinvonz@gmail.com>,
Jonathan Nieder <jrnieder@gmail.com>
Subject: Re: [PATCH 0/2] finding the fork point from reflog entries
Date: Thu, 24 Oct 2013 22:50:53 +0100 [thread overview]
Message-ID: <20131024215053.GF10779@serenity.lan> (raw)
In-Reply-To: <20131024214007.GE10779@serenity.lan>
On Thu, Oct 24, 2013 at 10:40:07PM +0100, John Keeping wrote:
> On Thu, Oct 24, 2013 at 10:31:35PM +0100, John Keeping wrote:
> > On Thu, Oct 24, 2013 at 02:20:29PM -0700, Junio C Hamano wrote:
> > > John Keeping <john@keeping.me.uk> writes:
> > >
> > > > On Thu, Oct 24, 2013 at 12:11:22PM -0700, Junio C Hamano wrote:
> > > >> The first one is a clean-up of the code to parse command line
> > > >> options to "git merge-base". Options such as "--independent",
> > > >> "--is-ancestor" and "--octopus" are mutually exclusive and it is
> > > >> better expressed in terms of the recently introduced OPT_CMDMODE.
> > > >>
> > > >> The second one implements the entire logic of the for loop we see in
> > > >> "git pull --rebase" directly using get_merge_bases_many() and
> > > >> postprocessing the result.
> > > >
> > > > Nice! I tried this in the case where the target commit happens to be
> > > > the 63rd reflog entry:
> > > >
> > > > $ time sh -c 'for rev in $(git rev-list -g origin/master 2>/dev/null)
> > > > do
> > > > git merge-base --is-ancestor $rev b2edae0 && break
> > > > done
> > > > '
> > > >
> > > > real 0m3.772s
> > > > user 0m3.338s
> > > > sys 0m0.440s
> > > >
> > > > $ time git merge-base --reflog origin/master b2edae0
> > > >
> > > > real 0m0.156s
> > > > user 0m0.138s
> > > > sys 0m0.018s
> > >
> > > The real question is if the C code computes the same as the shell
> > > loop.
> >
> > And in fact it doesn't - if you replace the "break" with "echo $rev" the
> > shell version prints b2edae0... but the C version prints nothing (and
> > exists with status 1).
>
> To clarify: the particular commit in the calls above happens to be the
> oldest entry in the reflog, if I pick a newer entry then it works.
>
> It seems that for_each_reflog_ent isn't returning the oldest entry;
> revs.nr is 62 whereas "git rev-list -g origin/master | wc -l" gives 63.
The following patch on top fixes it, but I'm sure it can be done in a
neater way.
-- >8 --
diff --git a/builtin/merge-base.c b/builtin/merge-base.c
index 7b9bc15..f6f1f14 100644
--- a/builtin/merge-base.c
+++ b/builtin/merge-base.c
@@ -98,7 +98,17 @@ static int collect_one_reflog_ent(unsigned char *osha1, unsigned char *nsha1,
int tz, const char *message, void *cbdata_)
{
struct rev_collect *revs = cbdata_;
- struct commit *commit = lookup_commit(nsha1);
+ struct commit *commit;
+
+ if (!revs->nr) {
+ commit = lookup_commit(osha1);
+ if (commit) {
+ ALLOC_GROW(revs->commit, revs->nr + 1, revs->alloc);
+ revs->commit[revs->nr++] = commit;
+ }
+ }
+
+ commit = lookup_commit(nsha1);
if (commit) {
ALLOC_GROW(revs->commit, revs->nr + 1, revs->alloc);
revs->commit[revs->nr++] = commit;
next prev parent reply other threads:[~2013-10-24 21:51 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-16 18:53 [PATCH] rebase: use reflog to find common base with upstream John Keeping
2013-10-16 19:24 ` Jonathan Nieder
2013-10-16 19:44 ` John Keeping
2013-10-21 5:03 ` Martin von Zweigbergk
2013-10-21 11:24 ` John Keeping
2013-10-22 6:24 ` Martin von Zweigbergk
2013-10-24 19:04 ` Junio C Hamano
2013-10-24 19:11 ` [PATCH 0/2] finding the fork point from reflog entries Junio C Hamano
2013-10-24 19:11 ` [PATCH 1/2] merge-base: use OPT_CMDMODE and clarify the command line parsing Junio C Hamano
2013-10-24 19:11 ` [PATCH 2/2] merge-base: "--reflog" mode finds fork point from reflog entries Junio C Hamano
2013-10-24 21:01 ` Eric Sunshine
2013-10-24 21:26 ` Junio C Hamano
2013-10-24 21:43 ` Eric Sunshine
2013-10-24 22:13 ` Junio C Hamano
2013-10-24 22:21 ` [PATCH v2 " Junio C Hamano
2013-10-25 7:12 ` Johannes Sixt
2013-10-25 8:09 ` John Keeping
2013-10-25 8:17 ` Johannes Sixt
2013-10-25 16:53 ` Junio C Hamano
2013-10-25 21:38 ` [PATCH v3 2/2] merge-base: teach "--fork-point" mode Junio C Hamano
2013-10-25 21:56 ` Eric Sunshine
2013-10-26 5:15 ` Martin von Zweigbergk
2013-10-28 14:47 ` Junio C Hamano
2013-10-26 9:00 ` John Keeping
2013-10-28 19:13 ` Junio C Hamano
2013-10-29 8:51 ` John Keeping
2013-10-29 20:11 ` Junio C Hamano
2013-10-24 20:54 ` [PATCH 0/2] finding the fork point from reflog entries John Keeping
2013-10-24 21:20 ` Junio C Hamano
2013-10-24 21:31 ` John Keeping
2013-10-24 21:40 ` John Keeping
2013-10-24 21:50 ` John Keeping [this message]
2013-10-25 2:46 ` Junio C Hamano
2013-10-22 5:40 ` [PATCH] rebase: use reflog to find common base with upstream Martin von Zweigbergk
2013-10-24 20:26 ` John Keeping
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=20131024215053.GF10779@serenity.lan \
--to=john@keeping.me.uk \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jrnieder@gmail.com \
--cc=martinvonz@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.