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 <j...@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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
