Daniel Barkalow <barkalow@iabervon.org> writes:

quoted text
> I like this idea a lot. I'd actually also like it for commit, although (1) 
> and (3a) obviously don't happen there. It would help to combat my tendency 
> to forget to push when I mean to.

Thanks.

quoted text
>> +/*
>> + * We really should allow cb_data... Yuck
>> + */
>> +static const char *branch_name;
>> +static int branch_name_len;
>> +static char *found_remote;
>> +static char *found_merge;
>> +static int read_branch_config(const char *var, const char *value)
>> +{
>
> ...
>
> I think you want branch_get(), which handles all the config file stuff up 
> to approximately here:

Fixups are very much welcomed.  This was more or less a proof of
concept.

quoted text
>> +	if (show_log) {
>> +		const char *args[32];
>> +		int ac;
>> +
>> +		ac = 0;
>> +		args[ac++] = "log";
>> +		args[ac++] = "--pretty=oneline";
>> +		args[ac++] = "--abbrev-commit";
>> +		args[ac++] = "--left-right";
>> +		args[ac++] = "--boundary";
>> +		args[ac++] = symmetric;
>> +		args[ac++] = "--";
>> +		args[ac] = NULL;
>> +
>> +		run_command_v_opt(args, RUN_GIT_CMD);
>
> We really should be able to do this in-process, although I'm not sure if 
> we really can.

The code runs in_merge_bases() twice, between our branch head
and the base, but if we really care about the performance, we
can have a single merge-base traversal and the resulting object
pool will have everything necessary to emit the log output
without a separate traversal.

Because I think that is reasonably easy, I just did not bother
to.  This is not a performance critical piece of code anyway.

One thing I thought about was to limit the output to latest N
entries from both sides.  That would also be easier to implement
if we do a single merge-base traversal and reuse the result.


-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html