Re: [PATCH v4 02/10] rebase -i: generate the script via rebase--helper

> Hi Liam,
> 
> On Thu, 25 May 2017, Liam Beguin wrote:
> 
>> Johannes Schindelin <johannes.schindelin@gmx.de> writes:
>>
>>> diff --git a/sequencer.c b/sequencer.c
>>> index 130cc868e51..88819a1a2a9 100644
>>> --- a/sequencer.c
>>> +++ b/sequencer.c
>>> @@ -2388,3 +2388,52 @@ void append_signoff(struct strbuf *msgbuf, int ignore_footer, unsigned flag)
>>>  
>>>  	strbuf_release(&sob);
>>>  }
>>> +
>>> +int sequencer_make_script(int keep_empty, FILE *out,
>>> +		int argc, const char **argv)
>>> +{
>>> +	char *format = NULL;
>>> +	struct pretty_print_context pp = {0};
>>> +	struct strbuf buf = STRBUF_INIT;
>>> +	struct rev_info revs;
>>> +	struct commit *commit;
>>> +
>>> +	init_revisions(&revs, NULL);
>>> +	revs.verbose_header = 1;
>>> +	revs.max_parents = 1;
>>> +	revs.cherry_pick = 1;
>>> +	revs.limited = 1;
>>> +	revs.reverse = 1;
>>> +	revs.right_only = 1;
>>> +	revs.sort_order = REV_SORT_IN_GRAPH_ORDER;
>>> +	revs.topo_order = 1;
>>> +
>>> +	revs.pretty_given = 1;
>>> +	git_config_get_string("rebase.instructionFormat", &format);
>>> +	if (!format || !*format) {
>>> +		free(format);
>>> +		format = xstrdup("%s");
>>> +	}
>>> +	get_commit_format(format, &revs);
>>> +	free(format);
>>> +	pp.fmt = revs.commit_format;
>>> +	pp.output_encoding = get_log_output_encoding();
>>> +
>>> +	if (setup_revisions(argc, argv, &revs, NULL) > 1)
>>> +		return error(_("make_script: unhandled options"));
>>> +
>>> +	if (prepare_revision_walk(&revs) < 0)
>>> +		return error(_("make_script: error preparing revisions"));
>>> +
>>> +	while ((commit = get_revision(&revs))) {
>>> +		strbuf_reset(&buf);
>>> +		if (!keep_empty && is_original_commit_empty(commit))
>>> +			strbuf_addf(&buf, "%c ", comment_line_char);
>>
>> I've never had to use empty commits before, but while testing this, I
>> noticed that `git rebase -i --keep-empty` behaves differently if using
>> the --root option instead of a branch or something like 'HEAD~10'.
>> I also tested this on v2.13.0 and the behavior is the same.
> 
> FWIW the terminology "empty commit" is a pretty poor naming choice. This
> is totally not your fault at all. I just wish we had a much more intuitive
> name to describe a commit that does not introduce any changes to the tree.
> 
> And yes, doing this with --root is a bit of a hack. That's because --root
> is a bit of a hack.
> 
> I am curious, though, as to the exact differences you experienced. I mean,
> it could be buggy behavior that needs to be fixed (independently of this
> patch series, of course).
>