Hi Stefan,
On Fri, 20 Apr 2018, Stefan Beller wrote:
> > static GIT_PATH_FUNC(rebase_path_amend, "rebase-merge/amend")
> > +/*
> > + * If there was a merge conflict in a fixup/squash series, we need to
> > + * record the type so that a `git rebase --skip` can clean up the commit
> > + * message as appropriate. This file will contain that type (`fixup` or
> > + * `squash`), and not exist otherwise.
> > + */
>
> Thanks for the documentation here, is there some other high level doc that
> describes all things to know about the internals of the rebase-merge dir
> or is this the definitive guide?
>
> > +static GIT_PATH_FUNC(rebase_path_amend_type, "rebase-merge/amend-type")
> > /*
> > * When we stop at a given patch via the "edit" command, this file contains
> > * the abbreviated commit name of the corresponding patch.
> > @@ -2400,10 +2407,20 @@ static int error_with_patch(struct commit *commit,
> > static int error_failed_squash(struct commit *commit,
> > struct replay_opts *opts, int subject_len, const char *subject)
> > {
> > + const char *amend_type = "squash";
> > +
> > + if (file_exists(rebase_path_fixup_msg())) {
> > + unlink(rebase_path_fixup_msg());
> > + amend_type = "fixup";
> > + }
> > + if (write_message(amend_type, strlen(amend_type),
> > + rebase_path_amend_type(), 0))
> > + return error(_("could not write '%s'"),
> > + rebase_path_amend_type());
>
> Do we want to wait with unlinking rebase_path_fixup_msg()
> until after we are sure there is no error returned?
Actually until after the rename() of `rebase_path_squash_msg()` succeeded,
you are right. I had changed the behavior unintentionally.
> I first thought so as to preserve the state as before, but
> then it only signals the amend type. But we're downgrading the
> amend type from "squash" to "fixup", which means that if
> this error happens and the user just retries the git command
> we'll end up with a "fixup", i.e. not opening their editor?
I am actually more worried about the rename() call failing... ;-) I
changed the order back to where it was before.
Thanks,
Dscho
