Re: [PATCH 1/4] rebase -i: add ack action
"Michael S. Tsirkin" writes: >> As to the "use commit-tree", well, personally I am not interested in >> a solution that can work well in my workflow ONLY if I further script >> it. That's half-solution and unless that half is done very well, >> I'd rather do a full solution better. > > Absolutely. But that's not what I meant. I will add a flag to git-ack to > select a branch and use commit-tree to put the ack commit there > *internally*. Would this do everything you need? How do you select > a branch? Automatically or do you remember the mapping from topic > to branch name? > ... > For first part, that is less common but also happens > (for example I get "for patches 1,7 and 23 in series: ACK") - > I would do git ack -s > to store David's signoff, then tag just messages by David > (probably just using limit ~b From:\ David in mutt) > and pipe them to git ack -r. > > Does this sound user-friendly enough? What would you do > differently? Because my workflow is I usually comment on and review many topics without applying them to anywhere, by the time I start applying patches, I often know which one got Acked and Reviewed already. So for them the workflow would be 0. Think which maintenance track the topic should be based on. 1. Fork $ git checkout -b maint- 2. In my MUA, pipe the message into this pipeline Meta/add-by -r peff@ -a Tsirkin | git am -s3c where the "add-by" script (found in 'todo') expands the given names using .mailmap and appends appropriate trailers (the latter should eventually be updated to use interpret-trailers when the tool matures, but I did not think it was there yet when I last updated the "add-by" script). So for a use case where I work off of my MUA, I have no use for your "git ack". -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] rebase -i: add ack action
On Tue, Apr 12, 2016 at 09:07:30AM -0700, Junio C Hamano wrote: > Matthieu Moy writes: > > > "Michael S. Tsirkin" writes: > > > >> Interesting. An empty commit would be rather easy to create on any > >> branch, not just the current one, using git-commit-tree. > > > > This "modify a branch without checking-it out" makes me think of "git > > notes". It may make sense to teach "git rebase -i" to look for notes in > > rebased commits and append them to the commit message when applying. > > Just an idea, not necessarily a good one ;-). > > Yeah that may actually fly well, as a note is designed to attach to > an exact commit, not to a branch, so that feels more natural. We'd have to invent a way to show that in the rebase -i output though. > As to the "use commit-tree", well, personally I am not interested in > a solution that can work well in my workflow ONLY if I further script > it. That's half-solution and unless that half is done very well, > I'd rather do a full solution better. Absolutely. But that's not what I meant. I will add a flag to git-ack to select a branch and use commit-tree to put the ack commit there *internally*. Would this do everything you need? How do you select a branch? Automatically or do you remember the mapping from topic to branch name? > Note: this is a continuation of "I personally would not use > it, even though other people might" discussion. > > I was also wondering if I should just script around filter-branch, > if all I am futzing with is the data in the trailer block, doing the > munging of the trailer block with interpret-trailers, naturally. > > In any case, a recent occasion that I had to do something related to > this topic may illustrate the boundary of requirements: > > Two developers, Michael and David, are involved. David sends a > 24-patch series, some of which were written by Michael and > others by David. The in-body "From:" lines are set right and > the resulting patches record authorship correctly. > > Michael reminds David that patches authored by Michael still > need to be signed-off by David. David sends a single message > "those by Michael in this series are signed off by me". > > Michael also says that he reviewed all patches authored by > David, i.e. "Add Acked-by Michael to all patches in this series > authored by David". > > Now this is an extreme case where a simple "OK I received an > e-mailed Ack, so I can rely on the subject line matching to mark it > to be squashed" approach will never work (i.e. if we were automating > it I'd expect that the script in DSL to the automation machinery to > take at last as many (conceptual) bits as the above problem > description). So here's how I solve the second part for now - that is very common: I expect Michael to write something like For series: Acked-by: Michael S. Tsirkin then I run git ack -s to put the signature in a file .git/ACKS. (git ack -s is just writing acks into .git/ACKS so if the email format is wrong I just edit it manually). And then I tag the series in email and run git ack -r to add the ack tag. For first part, that is less common but also happens (for example I get "for patches 1,7 and 23 in series: ACK") - I would do git ack -s to store David's signoff, then tag just messages by David (probably just using limit ~b From:\ David in mutt) and pipe them to git ack -r. Does this sound user-friendly enough? What would you do differently? -- MST -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] rebase -i: add ack action
Matthieu Moy writes: > "Michael S. Tsirkin" writes: > >> Interesting. An empty commit would be rather easy to create on any >> branch, not just the current one, using git-commit-tree. > > This "modify a branch without checking-it out" makes me think of "git > notes". It may make sense to teach "git rebase -i" to look for notes in > rebased commits and append them to the commit message when applying. > Just an idea, not necessarily a good one ;-). Yeah that may actually fly well, as a note is designed to attach to an exact commit, not to a branch, so that feels more natural. As to the "use commit-tree", well, personally I am not interested in a solution that can work well in my workflow ONLY if I further script it. That's half-solution and unless that half is done very well, I'd rather do a full solution better. Note: this is a continuation of "I personally would not use it, even though other people might" discussion. I was also wondering if I should just script around filter-branch, if all I am futzing with is the data in the trailer block, doing the munging of the trailer block with interpret-trailers, naturally. In any case, a recent occasion that I had to do something related to this topic may illustrate the boundary of requirements: Two developers, Michael and David, are involved. David sends a 24-patch series, some of which were written by Michael and others by David. The in-body "From:" lines are set right and the resulting patches record authorship correctly. Michael reminds David that patches authored by Michael still need to be signed-off by David. David sends a single message "those by Michael in this series are signed off by me". Michael also says that he reviewed all patches authored by David, i.e. "Add Acked-by Michael to all patches in this series authored by David". Now this is an extreme case where a simple "OK I received an e-mailed Ack, so I can rely on the subject line matching to mark it to be squashed" approach will never work (i.e. if we were automating it I'd expect that the script in DSL to the automation machinery to take at last as many (conceptual) bits as the above problem description). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] rebase -i: add ack action
On Mon, Apr 11, 2016 at 10:03:39PM +0200, Matthieu Moy wrote: > "Michael S. Tsirkin" writes: > > > On Mon, Apr 11, 2016 at 12:48:22PM -0700, Junio C Hamano wrote: > >> "Michael S. Tsirkin" writes: > >> > >> > Repost, sorry about the noise. > >> > > >> > On Mon, Apr 11, 2016 at 05:36:45PM +0200, Johannes Schindelin wrote: > >> >> Hi Michael, > >> >> > >> >> On Mon, 11 Apr 2016, Michael S. Tsirkin wrote: > >> >> > >> >> > So far I only see examples of adding footers. If that's all we can > >> >> > think > >> >> > up, why code in all this genericity? > >> >> > >> >> Because as far as I can see, the only benefitor of your patches would be > >> >> you. > >> >> > >> >> Ciao, > >> >> Johannes > >> > > >> > This seems unlikely. Just merging the patches won't benefit me directly > >> > - I have maintained them in my tree for a couple of years now with very > >> > little effort. For sure, I could benefit if they get merged and then > >> > someone improves them further - that was the point of posting them - but > >> > then I'm not the only benefitor. > >> > > >> > The workflow including getting acks for patches by email is not handled > >> > well by upstream git right now. It would surprise me if no one uses it > >> > if it's upstream, as you seem to suggest. But maybe most people moved > >> > on and just do pull requests instead. > >> > >> I doubt I would use this in its current form myself. > >> > >> Patch series I receive are all queued on their own separate topic > >> branches, and having to switch branches only to create a fake empty > >> commit to record received Acked-by and Reviewed-by is a chore that > >> serves only half of what needs to be done. > > > > Interesting. An empty commit would be rather easy to create on any > > branch, not just the current one, using git-commit-tree. > > This "modify a branch without checking-it out" makes me think of "git > notes". It may make sense to teach "git rebase -i" to look for notes in > rebased commits and append them to the commit message when applying. > Just an idea, not necessarily a good one ;-). Two things making it harder - machinery to look for commits is part of git rebase anyway - notes are expected to come after --- at the moment > > Does it sounds interesting if I teach > > git ack to get an active branch as a parameter? > > I think "ack" is not a good name for this feature: you use it to append > "Acked-by", but it can be used to append any trailer (for example, > Reviewed-by: would make complete sense too). Yes - I use it to append all trailers. > I think using a better name > would help the discussion (to remove the "it's my use-case" biais). > Perhaps "append"? Or "trailer". > -- > Matthieu Moy > http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] rebase -i: add ack action
"Michael S. Tsirkin" writes: > On Mon, Apr 11, 2016 at 12:48:22PM -0700, Junio C Hamano wrote: >> "Michael S. Tsirkin" writes: >> >> > Repost, sorry about the noise. >> > >> > On Mon, Apr 11, 2016 at 05:36:45PM +0200, Johannes Schindelin wrote: >> >> Hi Michael, >> >> >> >> On Mon, 11 Apr 2016, Michael S. Tsirkin wrote: >> >> >> >> > So far I only see examples of adding footers. If that's all we can think >> >> > up, why code in all this genericity? >> >> >> >> Because as far as I can see, the only benefitor of your patches would be >> >> you. >> >> >> >> Ciao, >> >> Johannes >> > >> > This seems unlikely. Just merging the patches won't benefit me directly >> > - I have maintained them in my tree for a couple of years now with very >> > little effort. For sure, I could benefit if they get merged and then >> > someone improves them further - that was the point of posting them - but >> > then I'm not the only benefitor. >> > >> > The workflow including getting acks for patches by email is not handled >> > well by upstream git right now. It would surprise me if no one uses it >> > if it's upstream, as you seem to suggest. But maybe most people moved >> > on and just do pull requests instead. >> >> I doubt I would use this in its current form myself. >> >> Patch series I receive are all queued on their own separate topic >> branches, and having to switch branches only to create a fake empty >> commit to record received Acked-by and Reviewed-by is a chore that >> serves only half of what needs to be done. > > Interesting. An empty commit would be rather easy to create on any > branch, not just the current one, using git-commit-tree. This "modify a branch without checking-it out" makes me think of "git notes". It may make sense to teach "git rebase -i" to look for notes in rebased commits and append them to the commit message when applying. Just an idea, not necessarily a good one ;-). > Does it sounds interesting if I teach > git ack to get an active branch as a parameter? I think "ack" is not a good name for this feature: you use it to append "Acked-by", but it can be used to append any trailer (for example, Reviewed-by: would make complete sense too). I think using a better name would help the discussion (to remove the "it's my use-case" biais). Perhaps "append"? -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] rebase -i: add ack action
On Mon, Apr 11, 2016 at 12:48:22PM -0700, Junio C Hamano wrote: > "Michael S. Tsirkin" writes: > > > Repost, sorry about the noise. > > > > On Mon, Apr 11, 2016 at 05:36:45PM +0200, Johannes Schindelin wrote: > >> Hi Michael, > >> > >> On Mon, 11 Apr 2016, Michael S. Tsirkin wrote: > >> > >> > So far I only see examples of adding footers. If that's all we can think > >> > up, why code in all this genericity? > >> > >> Because as far as I can see, the only benefitor of your patches would be > >> you. > >> > >> Ciao, > >> Johannes > > > > This seems unlikely. Just merging the patches won't benefit me directly > > - I have maintained them in my tree for a couple of years now with very > > little effort. For sure, I could benefit if they get merged and then > > someone improves them further - that was the point of posting them - but > > then I'm not the only benefitor. > > > > The workflow including getting acks for patches by email is not handled > > well by upstream git right now. It would surprise me if no one uses it > > if it's upstream, as you seem to suggest. But maybe most people moved > > on and just do pull requests instead. > > I doubt I would use this in its current form myself. > > Patch series I receive are all queued on their own separate topic > branches, and having to switch branches only to create a fake empty > commit to record received Acked-by and Reviewed-by is a chore that > serves only half of what needs to be done. Interesting. An empty commit would be rather easy to create on any branch, not just the current one, using git-commit-tree. Does it sounds interesting if I teach git ack to get an active branch as a parameter? > Once I decide to switch > back to the topic branch after receiving Acked-by and Reviewed-by, > I'd rather "rebase -i" to directly record them at that point, with > "reword". > > If the "trailers" stuff is packaged into an easier-to-use format to > use with "git commit --amend", I may use that together with "exec" > to automatically add these while doing so, but again, I do not see > any need for fake empty commits out of received e-mails in the > resulting workflow. > > That does not at all mean nobody other than Michael would use it, > though. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] rebase -i: add ack action
"Michael S. Tsirkin" writes: > Repost, sorry about the noise. > > On Mon, Apr 11, 2016 at 05:36:45PM +0200, Johannes Schindelin wrote: >> Hi Michael, >> >> On Mon, 11 Apr 2016, Michael S. Tsirkin wrote: >> >> > So far I only see examples of adding footers. If that's all we can think >> > up, why code in all this genericity? >> >> Because as far as I can see, the only benefitor of your patches would be >> you. >> >> Ciao, >> Johannes > > This seems unlikely. Just merging the patches won't benefit me directly > - I have maintained them in my tree for a couple of years now with very > little effort. For sure, I could benefit if they get merged and then > someone improves them further - that was the point of posting them - but > then I'm not the only benefitor. > > The workflow including getting acks for patches by email is not handled > well by upstream git right now. It would surprise me if no one uses it > if it's upstream, as you seem to suggest. But maybe most people moved > on and just do pull requests instead. I doubt I would use this in its current form myself. Patch series I receive are all queued on their own separate topic branches, and having to switch branches only to create a fake empty commit to record received Acked-by and Reviewed-by is a chore that serves only half of what needs to be done. Once I decide to switch back to the topic branch after receiving Acked-by and Reviewed-by, I'd rather "rebase -i" to directly record them at that point, with "reword". If the "trailers" stuff is packaged into an easier-to-use format to use with "git commit --amend", I may use that together with "exec" to automatically add these while doing so, but again, I do not see any need for fake empty commits out of received e-mails in the resulting workflow. That does not at all mean nobody other than Michael would use it, though. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] rebase -i: add ack action
Repost, sorry about the noise. On Mon, Apr 11, 2016 at 05:36:45PM +0200, Johannes Schindelin wrote: > Hi Michael, > > On Mon, 11 Apr 2016, Michael S. Tsirkin wrote: > > > So far I only see examples of adding footers. If that's all we can think > > up, why code in all this genericity? > > Because as far as I can see, the only benefitor of your patches would be > you. > > Ciao, > Johannes This seems unlikely. Just merging the patches won't benefit me directly - I have maintained them in my tree for a couple of years now with very little effort. For sure, I could benefit if they get merged and then someone improves them further - that was the point of posting them - but then I'm not the only benefitor. The workflow including getting acks for patches by email is not handled well by upstream git right now. It would surprise me if no one uses it if it's upstream, as you seem to suggest. But maybe most people moved on and just do pull requests instead. -- MST -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] rebase -i: add ack action
Hi Michael, On Mon, 11 Apr 2016, Michael S. Tsirkin wrote: > So far I only see examples of adding footers. If that's all we can think > up, why code in all this genericity? Because as far as I can see, the only benefitor of your patches would be you. Ciao, Johannes -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] rebase -i: add ack action
Johannes Schindelin writes: > How about making it easier to use, and much, much more generic, like this? > > 1. introducing an `--add-footer` flag to `git commit` that you could use > like this: > > git commit --amend --add-footer "Acked-by: Bugs Bunny" I have a script where I currently do this ala: GIT_EDITOR="git -c trailer.closes.ifExists=replace interpret-trailers \ --trailer 'Closes: #$PR [via git-merge-pr]' --in-place" \ git commit --quiet --amend But I think it could be a good addition to porcelain. (interpret-trailers still feels hard to drive by a script...) -- Christian Neukirchenhttp://chneukirchen.org -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] rebase -i: add ack action
On Mon, Apr 11, 2016 at 01:02:07PM +0200, Johannes Schindelin wrote: > Hi Michael, > > On Sun, 10 Apr 2016, Michael S. Tsirkin wrote: > > > This implements a new ack! action for git rebase -i > > It is essentially a middle ground between fixup! and squash!: > > - commits are squashed silently without editor being started > > - commit logs are concatenated (with action line being discarded) > > - because of the above, empty commits aren't discarded, > > their log is also included. > > > > I am using it as follows: > > git am -s < mailbox #creates first commit > > hack ... > > get mail with Ack > > git commit --allow-empty -m `cat <<-EOF > > ack! first > > > > Acked-by: maintainer > > EOF` > > repeat cycle > > git rebase --autosquash -i origin/master > > before public branch push > > > > The "cat" command above is actually a script that > > parses the Ack mail to create the empty commit - > > to be submitted separately. > > This looks awfully complicated, still, and not very generic. > > How about making it easier to use, and much, much more generic, like this? I can look at using a different syntax but the below does not support the workflow I described, which is a standard email based one: get email, handle it. > 1. introducing an `--add-footer` flag to `git commit` that you could use > like this: > > git commit --amend --add-footer "Acked-by: Bugs Bunny" > 2. introducing an `--exec-after` flag to `git commit` that would be a new > sibling of `--fixup` and `--squash` and would work like this: > > git commit --exec-after HEAD~5 \ > 'git commit --amend --add-footer "Acked-by: Bugs Bunny"' But it wouldn't address my use-case where I get an ack by email. If I have to dig up the relevant commit(s) by hand anyway, then what was the point? > > (it should imply `--allow-empty`, of course, and probably even fail if > anything was staged for commit at that point.) The commit message would > then look something like > > exec-after! Fix broken breakage > > git commit --amend --add-footer "Acked-by: Bugs Bunny" So if I happen to fetch a branch from someone and rebase it, stuff gets auto-executed on my local system? That looks scary. > This way would obviously benefit a lot more users. It might benefit others who have the commit handy but it does not look like it helps email based workflow. > For example, you could > easily say (and alias) > > git commit --amend --add-footer 'Reviewed-by: Arrested Developer" > > i.e. support all kind of use cases where developers need to slap on > footers in a quick & easy way. > > And the --exec-after option would obviously have *a lot* more use cases > than just squashing in ACKs. > > Ciao, > Johannes So far I only see examples of adding footers. If that's all we can think up, why code in all this genericity? All these small scripts scattered around just make things hard to use, and add security issues. -- MSR -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] rebase -i: add ack action
Hi Michael, On Sun, 10 Apr 2016, Michael S. Tsirkin wrote: > This implements a new ack! action for git rebase -i > It is essentially a middle ground between fixup! and squash!: > - commits are squashed silently without editor being started > - commit logs are concatenated (with action line being discarded) > - because of the above, empty commits aren't discarded, > their log is also included. > > I am using it as follows: > git am -s < mailbox #creates first commit > hack ... > get mail with Ack > git commit --allow-empty -m `cat <<-EOF > ack! first > > Acked-by: maintainer > EOF` > repeat cycle > git rebase --autosquash -i origin/master > before public branch push > > The "cat" command above is actually a script that > parses the Ack mail to create the empty commit - > to be submitted separately. This looks awfully complicated, still, and not very generic. How about making it easier to use, and much, much more generic, like this? 1. introducing an `--add-footer` flag to `git commit` that you could use like this: git commit --amend --add-footer "Acked-by: Bugs Bunny" 2. introducing an `--exec-after` flag to `git commit` that would be a new sibling of `--fixup` and `--squash` and would work like this: git commit --exec-after HEAD~5 \ 'git commit --amend --add-footer "Acked-by: Bugs Bunny"' (it should imply `--allow-empty`, of course, and probably even fail if anything was staged for commit at that point.) The commit message would then look something like exec-after! Fix broken breakage git commit --amend --add-footer "Acked-by: Bugs Bunny" This way would obviously benefit a lot more users. For example, you could easily say (and alias) git commit --amend --add-footer 'Reviewed-by: Arrested Developer" i.e. support all kind of use cases where developers need to slap on footers in a quick & easy way. And the --exec-after option would obviously have *a lot* more use cases than just squashing in ACKs. Ciao, Johannes -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] rebase -i: add ack action
This implements a new ack! action for git rebase -i
It is essentially a middle ground between fixup! and squash!:
- commits are squashed silently without editor being started
- commit logs are concatenated (with action line being discarded)
- because of the above, empty commits aren't discarded,
their log is also included.
I am using it as follows:
git am -s < mailbox #creates first commit
hack ...
get mail with Ack
git commit --allow-empty -m `cat <<-EOF
ack! first
Acked-by: maintainer
EOF`
repeat cycle
git rebase --autosquash -i origin/master
before public branch push
The "cat" command above is actually a script that
parses the Ack mail to create the empty commit -
to be submitted separately.
Signed-off-by: Michael S. Tsirkin
---
git-rebase--interactive.sh | 36
1 file changed, 28 insertions(+), 8 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 4cde685..6a766ca 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -150,6 +150,7 @@ Commands:
r, reword = use commit, but edit the commit message
e, edit = use commit, but stop for amending
s, squash = use commit, but meld into previous commit
+ a, ack = like "squash", but append commit body only to previous commit
f, fixup = like "squash", but discard this commit's log message
x, exec = run command (the rest of the line) using shell
d, drop = remove commit
@@ -438,6 +439,15 @@ update_squash_messages () {
echo
commit_message $2
;;
+ ack)
+ if test -f "$fixup_msg"
+ then
+ commit_message $2 | git stripspace --strip-comments |
sed -e '1,2d' >> "$fixup_msg"
+ fi
+ printf '%s\n' "$comment_char This is the $(nth_string $count)
commit message:"
+ echo
+ commit_message $2
+ ;;
fixup)
echo
printf '%s\n' "$comment_char The $(nth_string $count) commit
message will be skipped:"
@@ -479,7 +489,7 @@ record_in_rewritten() {
echo "$oldsha1" >> "$rewritten_pending"
case "$(peek_next_command)" in
- squash|s|fixup|f)
+ squash|s|fixup|f|ack|a)
;;
*)
flush_rewritten_pending
@@ -551,8 +561,11 @@ do_next () {
warn "Stopped at $sha1... $rest"
exit_with_patch $sha1 0
;;
- squash|s|fixup|f)
+ squash|s|fixup|f|ack|a)
case "$command" in
+ ack|a)
+ squash_style=ack
+ ;;
squash|s)
squash_style=squash
;;
@@ -576,7 +589,7 @@ do_next () {
die_failed_squash $sha1 "$rest"
fi
case "$(peek_next_command)" in
- squash|s|fixup|f)
+ squash|s|fixup|f|ack|a)
# This is an intermediate commit; its message will only
be
# used in case of trouble. So use the long version:
do_with_author output git commit --amend --no-verify -F
"$squash_msg" \
@@ -587,7 +600,7 @@ do_next () {
# This is the final command of this squash/fixup group
if test -f "$fixup_msg"
then
- do_with_author git commit --amend --no-verify
-F "$fixup_msg" \
+ do_with_author git commit --quiet --amend
--no-verify -F "$fixup_msg" \
${gpg_sign_opt:+"$gpg_sign_opt"} ||
die_failed_squash $sha1 "$rest"
else
@@ -717,7 +730,7 @@ skip_unnecessary_picks () {
done <"$todo" >"$todo.new" 3>>"$done" &&
mv -f "$todo".new "$todo" &&
case "$(peek_next_command)" in
- squash|s|fixup|f)
+ squash|s|fixup|f|ack|a)
record_in_rewritten "$onto"
;;
esac ||
@@ -764,7 +777,7 @@ rearrange_squash () {
do
test -z "${format}" || message=$(git log -n 1 --format="%s"
${sha1})
case "$message" in
- "squash! "*|"fixup! "*)
+ "squash! "*|"fixup! "*|"ack! "*)
action="${message%%!*}"
rest=$message
prefix=
@@ -772,7 +785,7 @@ rearrange_squash () {
while :
do
case "$rest" in
- "squash! "*|"fixup! "*)
+ "squash! "*|"fixup! "* |"ack! "*)
prefix="$prefix${rest%%!*},"
rest="${rest#*! }"
[PATCH 1/4] rebase -i: add ack action
This implements a new ack! action for git rebase -i
It is essentially a middle ground between fixup! and squash!:
- commits are squashed silently without editor being started
- commit logs are concatenated (with action line being discarded)
- because of the above, empty commits aren't discarded,
their log is also included.
I am using it as follows:
git am -s < mailbox #creates first commit
hack ...
get mail with Ack
git commit --allow-empty -m `cat <<-EOF
ack! first
Acked-by: maintainer
EOF`
repeat cycle
git rebase --autosquash -i origin/master
before public branch push
The "cat" command above is actually a script that
parses the Ack mail to create the empty commit -
to be submitted separately.
Signed-off-by: Michael S. Tsirkin
---
git-rebase--interactive.sh | 34 +++---
1 file changed, 27 insertions(+), 7 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 6ec9d3c..821872c 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -140,6 +140,7 @@ Commands:
r, reword = use commit, but edit the commit message
e, edit = use commit, but stop for amending
s, squash = use commit, but meld into previous commit
+ a, ack = like "squash", but append commit body only to previous commit
f, fixup = like "squash", but discard this commit's log message
x, exec = run command (the rest of the line) using shell
@@ -412,6 +413,15 @@ update_squash_messages () {
echo
commit_message $2
;;
+ ack)
+ if test -f "$fixup_msg"
+ then
+ commit_message $2 | git stripspace --strip-comments |
sed -e '1,2d' >> "$fixup_msg"
+ fi
+ printf '%s\n' "$comment_char This is the $(nth_string $count)
commit message:"
+ echo
+ commit_message $2
+ ;;
fixup)
echo
printf '%s\n' "$comment_char The $(nth_string $count) commit
message will be skipped:"
@@ -453,7 +463,7 @@ record_in_rewritten() {
echo "$oldsha1" >> "$rewritten_pending"
case "$(peek_next_command)" in
- squash|s|fixup|f)
+ squash|s|fixup|f|ack|a)
;;
*)
flush_rewritten_pending
@@ -521,8 +531,11 @@ do_next () {
warn "Stopped at $sha1... $rest"
exit_with_patch $sha1 0
;;
- squash|s|fixup|f)
+ squash|s|fixup|f|ack|a)
case "$command" in
+ ack|a)
+ squash_style=ack
+ ;;
squash|s)
squash_style=squash
;;
@@ -546,7 +559,7 @@ do_next () {
die_failed_squash $sha1 "$rest"
fi
case "$(peek_next_command)" in
- squash|s|fixup|f)
+ squash|s|fixup|f|ack|a)
# This is an intermediate commit; its message will only
be
# used in case of trouble. So use the long version:
do_with_author output git commit --amend --no-verify -F
"$squash_msg" \
@@ -557,7 +570,7 @@ do_next () {
# This is the final command of this squash/fixup group
if test -f "$fixup_msg"
then
- do_with_author git commit --amend --no-verify
-F "$fixup_msg" \
+ do_with_author git commit --quiet --amend
--no-verify -F "$fixup_msg" \
${gpg_sign_opt:+"$gpg_sign_opt"} ||
die_failed_squash $sha1 "$rest"
else
@@ -690,7 +703,7 @@ skip_unnecessary_picks () {
done <"$todo" >"$todo.new" 3>>"$done" &&
mv -f "$todo".new "$todo" &&
case "$(peek_next_command)" in
- squash|s|fixup|f)
+ squash|s|fixup|f|ack|a)
record_in_rewritten "$onto"
;;
esac ||
@@ -732,7 +745,7 @@ rearrange_squash () {
while read -r pick sha1 message
do
case "$message" in
- "squash! "*|"fixup! "*)
+ "squash! "*|"fixup! "*|"ack! "*)
action="${message%%!*}"
rest=$message
prefix=
@@ -740,7 +753,7 @@ rearrange_squash () {
while :
do
case "$rest" in
- "squash! "*|"fixup! "*)
+ "squash! "*|"fixup! "* |"ack! "*)
prefix="$prefix${rest%%!*},"
rest="${rest#*! }"
;;
@@ -975,6 +988,13 @@ do
