From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Liam Beguin <liambeguin@gmail.com>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>,
Philip Oakley <philipoakley@iee.org>, Jeff King <peff@peff.net>,
Phillip Wood <phillip.wood@dunelm.org.uk>
Subject: Re: [PATCH v5 08/10] rebase -i: skip unnecessary picks using the rebase--helper
Date: Mon, 19 Jun 2017 11:45:50 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.21.1.1706191127450.57822@virtualbox> (raw)
In-Reply-To: <529f6cc7-ab2b-72bb-bc51-f4cca4e98652@gmail.com>
Hi Liam,
On Sat, 17 Jun 2017, Liam Beguin wrote:
> On 16/06/17 09:56 AM, Johannes Schindelin wrote:
>
> > On Thu, 15 Jun 2017, Liam Beguin wrote:
> >
> >> On 14/06/17 09:08 AM, Johannes Schindelin wrote:
> >>> diff --git a/sequencer.c b/sequencer.c
> >>> index a697906d463..a0e020dab09 100644
> >>> --- a/sequencer.c
> >>> +++ b/sequencer.c
> >>> @@ -2640,3 +2640,110 @@ int check_todo_list(void)
> >>>
> >>> return res;
> >>> }
> >>> +
> >>> +/* skip picking commits whose parents are unchanged */
> >>> +int skip_unnecessary_picks(void)
> >>> +{
> >>> + const char *todo_file = rebase_path_todo();
> >>> + struct strbuf buf = STRBUF_INIT;
> >>> + struct todo_list todo_list = TODO_LIST_INIT;
> >>> + struct object_id onto_oid, *oid = &onto_oid, *parent_oid;
> >>> + int fd, i;
> >>> +
> >>> + if (!read_oneliner(&buf, rebase_path_onto(), 0))
> >>> + return error(_("could not read 'onto'"));
> >>> + if (get_sha1(buf.buf, onto_oid.hash)) {
> >>
> >> I missed this last time but we could also replace `get_sha1` with
> >> `get_oid`
> >
> > Good point!
> >
> > I replaced this locally and force-pushed, but there is actually little
> > chance of this patch series being integrated in a form with which I
> > would be comfortable.
>
> Is there any chance of this moving forward? I was hoping to resend my
> path to abbreviate command names on top of this.
We are at an impasse right now.
Junio wants me to change this code:
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)
...
which is reasonably compile-time safe, to something like this:
struct strbuf userformat = STRBUF_INIT;
struct argv_array args = ARGV_ARRAY_INIT;
...
for (i = 0; i < argc; i++)
argv_array_push(&args, argv[i]);
git_config_get_string("rebase.instructionFormat", &format);
if (!format || !*format)
argv_array_push(&args, "--format=%s");
else {
strbuf_addf(&userformat, "--format=%s", format);
argv_array_push(&args, userformat.buf);
}
if (setup_revisions(args.argc, args.argv, &revs, NULL) > 1)
...
argv_array_clear(&args);
strbuf_release(&userformat);
which is not compile-time safe, harder to read, sloppy coding in my book.
The reason for this suggestion is that one of the revision machinery's
implementation details is an ugly little semi-secret: the pretty-printing
machinery uses a global state, and that is why we need the "pretty_given"
flag in the first place.
Junio thinks that it would be better to not use the pretty_given flag in
this patch series. I disagree: It would be better to use the pretty_given
flag, also as a good motivator to work on removing the global state in the
pretty-printing machinery.
Junio wants to strong-arm me into accepting authorship for this sloppy
coding, and I simply won't do it.
That's why we are at an impasse right now.
I am really, really sorry that this affects your patch series, as I had
not foreseen Junio's insistence on the sloppy coding when I suggested that
you rebase your work on top of my patch series. I just was really
unprepared for this contention, and I am still surprised/shocked that this
is even an issue up for discussion.
Be that as it may, I see that this is a very bad experience for a
motivated contributor such as yourself. I am very sorry about that!
So it may actually be better for you to go forward with your original
patch series targeting git-rebase--interactive.sh.
My apologies,
Dscho
next prev parent reply other threads:[~2017-06-19 9:46 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-14 13:06 [PATCH v5 00/10] The final building block for a faster rebase -i Johannes Schindelin
2017-06-14 13:07 ` [PATCH v5 01/10] t3415: verify that an empty instructionFormat is handled as before Johannes Schindelin
2017-06-14 13:07 ` [PATCH v5 02/10] rebase -i: generate the script via rebase--helper Johannes Schindelin
2017-06-14 13:07 ` [PATCH v5 03/10] rebase -i: remove useless indentation Johannes Schindelin
2017-06-14 13:07 ` [PATCH v5 04/10] rebase -i: do not invent onelines when expanding/collapsing SHA-1s Johannes Schindelin
2017-06-14 13:07 ` [PATCH v5 05/10] rebase -i: also expand/collapse the SHA-1s via the rebase--helper Johannes Schindelin
2017-06-14 13:07 ` [PATCH v5 06/10] t3404: relax rebase.missingCommitsCheck tests Johannes Schindelin
2017-06-14 13:07 ` [PATCH v5 07/10] rebase -i: check for missing commits in the rebase--helper Johannes Schindelin
2017-06-14 13:08 ` [PATCH v5 08/10] rebase -i: skip unnecessary picks using " Johannes Schindelin
2017-06-16 2:39 ` Liam Beguin
2017-06-16 13:56 ` Johannes Schindelin
2017-06-17 22:48 ` Liam Beguin
2017-06-19 9:45 ` Johannes Schindelin [this message]
2017-06-19 16:10 ` Jeff King
2017-06-19 17:39 ` Junio C Hamano
2017-06-20 2:35 ` Liam Beguin
2017-06-14 13:08 ` [PATCH v5 09/10] t3415: test fixup with wrapped oneline Johannes Schindelin
2017-06-14 13:08 ` [PATCH v5 10/10] rebase -i: rearrange fixup/squash lines using the rebase--helper Johannes Schindelin
2017-06-15 23:13 ` [PATCH v5 00/10] The final building block for a faster rebase -i Junio C Hamano
2017-06-16 13:50 ` Johannes Schindelin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.21.1.1706191127450.57822@virtualbox \
--to=johannes.schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=liambeguin@gmail.com \
--cc=peff@peff.net \
--cc=philipoakley@iee.org \
--cc=phillip.wood@dunelm.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox