John Keeping [off-list ref] writes:
On Thu, Oct 24, 2013 at 12:11:22PM -0700, Junio C Hamano wrote:
quoted
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.
On Thu, Oct 24, 2013 at 02:20:29PM -0700, Junio C Hamano wrote:
John Keeping [off-list ref] writes:
quoted
On Thu, Oct 24, 2013 at 12:11:22PM -0700, Junio C Hamano wrote:
quoted
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).
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:
quoted
John Keeping [off-list ref] writes:
quoted
On Thu, Oct 24, 2013 at 12:11:22PM -0700, Junio C Hamano wrote:
quoted
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.
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:
quoted
On Thu, Oct 24, 2013 at 02:20:29PM -0700, Junio C Hamano wrote:
quoted
John Keeping [off-list ref] writes:
quoted
On Thu, Oct 24, 2013 at 12:11:22PM -0700, Junio C Hamano wrote:
quoted
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;