Re: [RFC/PATCH] rebase--interactive: Add "sign" command

Johannes Schindelin [off-list ref] writes:

... my Git garden shears [*1*] (essentially, what
git rebase --interactive --preserve-merges *should* have been).

Any plan to fold it into "git rebase -i" as a new (improved) mode of
operation, by the way?

However, I could imagine that we actually want this to be more extensible.
After all, all you are doing is to introduce a new rebase -i command that
does nothing else than shelling out to a command.

Yup, I tend to agree.

Adding "sign" feature (i.e. make it pass -S to "commit [--amend]")
may be a good thing, but adding "sign" command to do so is not a
great design.

There is no inherent reason why "sign" feature implies "--no-edit",
and adding a "sign" command like this patch means that the next
command somebody else proposes will be "sign-and-reword".

We should be able to treat Signing and Rewording as two orthogonal
features, one that passes -S, and the other that refrains from
passing --no-edit.  Otherwise as the number of features grow, the
number of commands will see combinatorial growth.

Thanks.

Hi Junio,

On Wed, 3 Aug 2016, Junio C Hamano wrote:

Johannes Schindelin [off-list ref] writes:

quoted

... my Git garden shears [*1*] (essentially, what
git rebase --interactive --preserve-merges *should* have been).

Any plan to fold it into "git rebase -i" as a new (improved) mode of
operation, by the way?

It was my plan to integrate it into the sequencer, once the rebase--helper
landed in `master`. Little did I know how long it would take to get this
done...

My loose idea was to deprecate --preserve-merges after introducing a
--recreate-branches, or some such. But enough of that. The rebase--helper
needs to get here first.

quoted

However, I could imagine that we actually want this to be more extensible.
After all, all you are doing is to introduce a new rebase -i command that
does nothing else than shelling out to a command.

Yup, I tend to agree.

Awesome!

Ciao,
Dscho

On Wed, Aug 03, 2016 at 09:08:48AM -0700, Junio C Hamano wrote:

quoted

However, I could imagine that we actually want this to be more extensible.
After all, all you are doing is to introduce a new rebase -i command that
does nothing else than shelling out to a command.

Yup, I tend to agree.

Adding "sign" feature (i.e. make it pass -S to "commit [--amend]")
may be a good thing, but adding "sign" command to do so is not a
great design.

I'm not sure what you mean by "feature" here, but it reminded me of
Michael's proposal to allow options to todo lines:

  http://public-inbox.org/git/530DA00E.4090402@alum.mit.edu/

which would allow:

  pick -S 1234abcd

If that's what you meant, I think it is a good idea. :)

-Peff

On Thu, Aug 4, 2016 at 6:08 AM, Jeff King [off-list ref] wrote:

On Wed, Aug 03, 2016 at 09:08:48AM -0700, Junio C Hamano wrote:

quoted

quoted

However, I could imagine that we actually want this to be more extensible.
After all, all you are doing is to introduce a new rebase -i command that
does nothing else than shelling out to a command.

Yup, I tend to agree.

Adding "sign" feature (i.e. make it pass -S to "commit [--amend]")
may be a good thing, but adding "sign" command to do so is not a
great design.

I'm not sure what you mean by "feature" here, but it reminded me of
Michael's proposal to allow options to todo lines:

  http://public-inbox.org/git/530DA00E.4090402@alum.mit.edu/

which would allow:

  pick -S 1234abcd

If that's what you meant, I think it is a good idea. :)

That would definitely suit me. I see there was some discussion of
which options were sensible to support. --signoff and --reset-author
would be a good start from my point of view. Maybe that's something
that could be build on top of Johannes work.

-Peff

Hi Peff,

On Wed, 3 Aug 2016, Jeff King wrote:

On Wed, Aug 03, 2016 at 09:08:48AM -0700, Junio C Hamano wrote:

quoted

quoted

However, I could imagine that we actually want this to be more
extensible.  After all, all you are doing is to introduce a new
rebase -i command that does nothing else than shelling out to a
command.

Yup, I tend to agree.

Adding "sign" feature (i.e. make it pass -S to "commit [--amend]") may
be a good thing, but adding "sign" command to do so is not a great
design.

I'm not sure what you mean by "feature" here, but it reminded me of
Michael's proposal to allow options to todo lines:

  http://public-inbox.org/git/530DA00E.4090402@alum.mit.edu/

which would allow:

  pick -S 1234abcd

If that's what you meant, I think it is a good idea. :)

I looked at the code in git-rebase--interactive.sh again and stumbled over
something important: if you "pick" a commit, it *already* uses the
information provided to the rebase command via the -S option, *unless* the
pick fast-forwards.

That is, I came to believe that the "sign" command is unnecessary, and
that the --force-rebase option in conjunction with the -S option is what
should be used.

Ciao,
Dscho