Johannes Schindelin [off-list ref] writes:
On Wed, 17 Jun 2009, Junio C Hamano wrote:
...
quoted
The commit not only must begin with "squash to " but also there has to
be a matching commit whose message begins with the remainder of the
title of the "squash to" commit _in the range you are rebasing
INTERACTIVELY_.
In addition, the resulting rebase insn is presented in the editor, and
in a rare case where you do have such a commit, you can rearrange it
back.
Well, that really sounds pretty awkward to me. I regularly call such
commits "amend". If there is a risk I confuse myself as to which commit
needs to be amended, I use "amend.<short-hint>".
I'd really rather stay with "fixup". And as I use single-letter commands
quite often, I'd also rather stay away from that magic "!". And by
"magic" I really mean that: people will not find that magic intuitive at
all.
My vote is for "fixup".
I am too tired to either make the final judgement nor proposal on this
topic now, but before I forget here is one tangent.
I also often use "magic" commit log message in other occasions. The most
important is "[DONTMERGE]" prefix to somebody else's commit I queue to
'pu' (or leave unmerged even to 'pu'---just keeping on a topic branch). I
accept a patch with "am" and then "amend" after review when I find that it
needs more work. One day I am hoping to write a pre-merge hook that
forbids commits marked with such magic to come into 'next' and down.
The point?
Earlier somebody objected to a command that changes behaviour based on
what is in the commit log message, but for the private commits the patch
under discussion deals with and the ones I mark with "[DONTMERGE]", the
commit log message _is_ the right place to leave a mark for commands to
take notice and act differently.
Of course we _could_ use notes for that, but that won't play well with
rebasing I suppose ...
Hi,
On Thu, 18 Jun 2009, Junio C Hamano wrote:
Johannes Schindelin [off-list ref] writes:
quoted
On Wed, 17 Jun 2009, Junio C Hamano wrote:
...
quoted
The commit not only must begin with "squash to " but also there has to
be a matching commit whose message begins with the remainder of the
title of the "squash to" commit _in the range you are rebasing
INTERACTIVELY_.
In addition, the resulting rebase insn is presented in the editor, and
in a rare case where you do have such a commit, you can rearrange it
back.
Well, that really sounds pretty awkward to me. I regularly call such
commits "amend". If there is a risk I confuse myself as to which commit
needs to be amended, I use "amend.<short-hint>".
I'd really rather stay with "fixup". And as I use single-letter commands
quite often, I'd also rather stay away from that magic "!". And by
"magic" I really mean that: people will not find that magic intuitive at
all.
My vote is for "fixup".
I am too tired to either make the final judgement nor proposal on this
topic now,
Okay, I'll add another point that should convince you that the commit
message is not the good place to trigger that behavior:
Interactive rebasing is about having made a quite messy patch series,
maybe having a few fixup commits, and then deciding how to clean it up.
The decision how to clean it up is very much a rebase-time decision, not a
commit-time decision.
For example, it is very easy to decide that you want to squash one fixup
after all instead of leaving it stand-alone.
Of course we _could_ use notes for that, but that won't play well with
rebasing I suppose ...
Reminds me. Nothing has happened on that front, right?
Ciao,
Dscho
Johannes Schindelin venit, vidit, dixit 18.06.2009 10:33:
Hi,
On Thu, 18 Jun 2009, Junio C Hamano wrote:
quoted
Johannes Schindelin [off-list ref] writes:
quoted
On Wed, 17 Jun 2009, Junio C Hamano wrote:
...
quoted
The commit not only must begin with "squash to " but also there has to
be a matching commit whose message begins with the remainder of the
title of the "squash to" commit _in the range you are rebasing
INTERACTIVELY_.
In addition, the resulting rebase insn is presented in the editor, and
in a rare case where you do have such a commit, you can rearrange it
back.
Well, that really sounds pretty awkward to me. I regularly call such
commits "amend". If there is a risk I confuse myself as to which commit
needs to be amended, I use "amend.<short-hint>".
I'd really rather stay with "fixup". And as I use single-letter commands
quite often, I'd also rather stay away from that magic "!". And by
"magic" I really mean that: people will not find that magic intuitive at
all.
My vote is for "fixup".
I am too tired to either make the final judgement nor proposal on this
topic now,
Okay, I'll add another point that should convince you that the commit
message is not the good place to trigger that behavior:
Interactive rebasing is about having made a quite messy patch series,
maybe having a few fixup commits, and then deciding how to clean it up.
The decision how to clean it up is very much a rebase-time decision, not a
commit-time decision.
For example, it is very easy to decide that you want to squash one fixup
after all instead of leaving it stand-alone.
quoted
Of course we _could_ use notes for that, but that won't play well with
rebasing I suppose ...
Reminds me. Nothing has happened on that front, right?
<!--#if expr="$SARCASM_ON" -->
No, but isn't that the true purpose of out-sourcing? You've got someone
else to blame now!
<!--#endif -->
Cheers,
Michael
The 18/06/09, Junio C Hamano wrote:
I also often use "magic" commit log message in other occasions. The most
important is "[DONTMERGE]" prefix to somebody else's commit I queue to
'pu' (or leave unmerged even to 'pu'---just keeping on a topic branch). I
accept a patch with "am" and then "amend" after review when I find that it
needs more work. One day I am hoping to write a pre-merge hook that
forbids commits marked with such magic to come into 'next' and down.
The point?
Earlier somebody objected to a command that changes behaviour based on
what is in the commit log message, but for the private commits the patch
under discussion deals with and the ones I mark with "[DONTMERGE]", the
commit log message _is_ the right place to leave a mark for commands to
take notice and act differently.
Of course we _could_ use notes for that, but that won't play well with
rebasing I suppose ...
Not for now; you're right. But what I see here is all about
commit/branch metadata to make our like with workflows easier.
What about implementing a true metadata feature into Git? There are a
lot of nice possible functionalities around metadata.
Fast, stupid and superficial thoughts on that:
- have metadata to make git to act differently and/or for information
purpose;
- let the user create its own metadata for his own purpose;
- let the user have hooks script where appropriate.
--
Nicolas Sebrecht