Hi Liam,
On Thu, 25 May 2017, Liam Beguin wrote:
> Johannes Schindelin <johannes.schinde...@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).
Ciao,
Johannes
