Re: squashing patches

Stephan Beyer [off-list ref] writes:

So I wonder if file --squash is useful, too, or even --squash as an
general option. The latter means that you could squash merge commits
into other commits, too.

We've also discussed the non-atomic approach of doing something like
	pick ( a b c d )	# or another syntax for that
for picking multiple commits into one.
In my current point of view, this does not seem right, as it:
 - is not atomic ;), and...
 - Well, the approach could be used for "file ( a b c d )", too,
   but it doesn't help for squashing commits AND patches.

Comments? Opinions? Ideas?

I actually expected that the primitive command sequence the backward
compatible "edit" would expand to would be a pair, "pick" followed by
"pause".  Whenever the sequencer sees "pause", it does not do anything but
reports the current HEAD and gives the control back to the user, so that
the user can do amend or whatever before telling you to --continue.

Similarly, I expected the backward-compatible "squash" to expand to a
pair, "pick" followed by "zucchini 2".  Whenever the sequencer sees
"zucchini <n>", it prepares a commit log to describe the top <n> commits,
resets HEAD back by <n> commits, and gives control to your editor.

About the other parts in your original message:

 - The "tag" command looked a little out of place;

 - I would have called your "file" command "patch" (we might want to have
   another file related operation later).

 - The --author option presumably would be to lie about the authorship but
   without taking it from an existing commit.  (1) Don't you need to have
   an option similar to -C option of "git-commit"?  (2) Don't you need to
   also be able to lie about the author timestamp?

quoted

Comments? Opinions? Ideas?

I actually expected that the primitive command sequence the backward
compatible "edit" would expand to would be a pair, "pick" followed by
"pause".

Something "like" this was my veeeery first approach: "edit" with commit
was the backwards-compatible "edit" and without arguments was your
"pause".
Example:
	pick ea7beef
	edit		# or "pause" as you suggested
After a little discussion this became:
	pick --edit ea7beef

And I can't objectively say what's better

Whenever the sequencer sees "pause", it does not do anything but
reports the current HEAD and gives the control back to the user, so that
the user can do amend or whatever before telling you to --continue.

Yes.

Similarly, I expected the backward-compatible "squash" to expand to a
pair, "pick" followed by "zucchini 2".  Whenever the sequencer sees
"zucchini <n>", it prepares a commit log to describe the top <n> commits,
resets HEAD back by <n> commits, and gives control to your editor.

That's right.  See the RFC/PATCH about git-squash mail or its parent
mail[1] ;-)

 1. http://article.gmane.org/gmane.comp.version-control.git/84391 2) ff.
    and
    http://article.gmane.org/gmane.comp.version-control.git/84420

The open question is, if we should do this by a natural number <n> or
by a commit.
The natural number approach seems easier, but imagine someone pauses
and does some commits (not --amend)... Here the behavior of these
approaches differs. ;-)

About the other parts in your original message:

 - The "tag" command looked a little out of place;

Eh, why?

 - I would have called your "file" command "patch" (we might want to have
   another file related operation later).

Ok. "file" and "patch" were both choices to me. Don't know, why I
decided for "file".

 - The --author option presumably would be to lie about the authorship but
   without taking it from an existing commit.  (1) Don't you need to have
   an option similar to -C option of "git-commit"?  (2) Don't you need to
   also be able to lie about the author timestamp?

Right. ;)

Regards and thanks,
  Stephan

-- 
Stephan Beyer [off-list ref], PGP 0x6EDDD207FCC5040F

On Mon, Jun 09, 2008 at 10:43:27PM +0200, Stephan Beyer wrote:

Something "like" this was my veeeery first approach: "edit" with commit
was the backwards-compatible "edit" and without arguments was your
"pause".
Example:
	pick ea7beef
	edit		# or "pause" as you suggested
After a little discussion this became:
	pick --edit ea7beef

And I can't objectively say what's better

I am just watching this from the sidelines, but it seems to me that you
are best off creating the directives as modular and orthogonal as
possible.  It is very simple to create "pick $1; edit" from "pick --edit
$1" later, but it is more difficult to go the other way around.

IOW, worry early about flexibility, and later you can build syntactic
sugar if you need to.

-Peff

Hi,

I am just watching this from the sidelines, but it seems to me that you
are best off creating the directives as modular and orthogonal as
possible.  It is very simple to create "pick $1; edit" from "pick --edit
$1" later, but it is more difficult to go the other way around.

Perhaps it is just me, but isn't "pick X ; edit"
more modular and orthogonal than "pick --edit X"? ;-)

But yes, the "pick --edit X" => "pick X ; edit" conversion seems easier.

And I'm slightly confused which solution seems better to you for now ;)

Regards,
  Stephan

-- 
Stephan Beyer [off-list ref], PGP 0x6EDDD207FCC5040F

On Tue, Jun 10, 2008 at 01:57:33AM +0200, Stephan Beyer wrote:

quoted

I am just watching this from the sidelines, but it seems to me that you
are best off creating the directives as modular and orthogonal as
possible.  It is very simple to create "pick $1; edit" from "pick --edit
$1" later, but it is more difficult to go the other way around.

Perhaps it is just me, but isn't "pick X ; edit"
more modular and orthogonal than "pick --edit X"? ;-)

Sorry, I chose a bad phrase. When I said "create X from Y", I meant
"when the user gives you Y, you can produce the canonical X". Not "once
we have the canonical Y, you can create X out of it."

So I appear to have said the exact opposite of what I meant. :)

But yes, the "pick --edit X" => "pick X ; edit" conversion seems easier.

Exactly.

-Peff