threads / discuss / 6954

RFC: Patch editing

Subject: RFC: Patch editing

## tl;dr

15 messages between Feb 25, 2007 and Mar 1, 2007.

replies: 14people: 6as markdown or json

Johannes Schindelin· Feb 25, 2007, 21:59 UTC · lore
Hi list,

while I was hacking on another issue, I realized just how often I would like to stash away a fix which is unrelated (but often triggered) by the theme of the current topic branch. Or I fix an earlier commit, which is not the tip of the branch, so I cannot --amend it.

My common practice is to commit it nevertheless, and sort the topic branches out later, by cherry-picking my way through the commits.

This is a tedious and error-prone procedure, and I often wished I knew how to use StGIT. But then, StGIT is overkill for me: on some machines I work on, there is no Python installed, I do not really need to have a history on the order and version of patches, and I do not need to preserve author and committer information *1*.

Therefore, I wrote this extremely simple script to sort out the order of commits, and possibly merging some. The script lets you edit the commit list upon start (reordering it, or removing commits), and then works on that list. It has three subcommands:

	start <base>
	continue
	reset [-f]

The subcommand "start" takes a base commit (actually, it will take the merge base of HEAD and that base commit) from which to start. It builds a commit list and opens it in an editor. The rows of the list have the form "<action> <sha1> <oneline>". The oneline description is purely for ease of use.

The three possible actions are "pick" (the default), "edit" and "merge". "pick" will just cherry-pick that commit, "edit" will stop after cherry-picking so that you can make a small fixup (in the code or in the commit message), and "merge" will try to apply the corresponding patch, amend the previous commit with the result, and let you edit the combined commit message.

If a patch fails, or "edit" was specified, the loop is interrupted for fixups. Use the subcommand "continue" to restart the loop (the working tree has to be clean, though).

Once there are no more commits to be picked, the original branch is updated to that new tip.

If you decide at some point that you do not want to rewrite the patches after all, you can use the subcommand "reset".

To see which commits were already applied, you can inspect .series/done, and likewise .series/todo for what is to be applied yet. You can even edit .series/todo if you decide on another course of action.

Anyway, it is a relatively short and stupid script.

Ciao, Dscho

*1* My slight aversion against Python and Perl might be involved, too.

-- snipsnap -- #!/bin/sh # # Copyright (c) 2006 Johannes E. Schindelin

# SHORT DESCRIPTION # # This is a really stupid script to arrange a patch series for submission. # It does not care for authorship or dates, all it does is make it easy # to fix up commits in the middle of a series, and rearrange commits. # # MOTIVATION # # It is extremely useful for this type of workflow: # # 1. have a wonderful idea # 2. hack on the code # 3. prepare a series for submission # 4. submit # # where the point (2) consists of several instances of # # A.1. finish something worthy of a commit # A.2. commit # # and/or # # B.1. realize that something does not work # B.2. fix that # B.3. commit it # # Sometimes the thing fixed in B.2. cannot be amended to the not-quite # perfect commit it fixes, because that commit is buried deeply in a # patch series. # # Use this script after plenty of "A"s and "B"s, by rearranging, and # possibly editing and merging commits. # # USAGE: # # The subcommand "start" will make a list of the commits in the patch # series <base>..HEAD, where <base> is the commit identiefied by the # parameter. # # It will automatically start an editor, where you can rearrange the # commits. The list looks more or less like this: # # pick deadbee The oneline of this commit # pick fa1afe1 The oneline of the next commit # ... # # By replacing the command "pick" with "edit" you can tell # this script to stop the loop so you can fix up the commit by editing # files and/or the commit message. # # When replacing the command "pick" with "merge, the script will merge # this commit's changes into the previous commit, munge the commit # messages of both, and open the commit message editor. # # In both cases, or when a "pick" does not succeed (because of merge # errors), the loop will stop to let you fix things, and you can continue # the loop with `git edit-patch-series continue`.

USAGE='(start <basecommit>| continue | reset [--force])'

. git-sh-setup require_work_tree

SERIESDIR="$(pwd)/.series" TODO="$SERIESDIR"/todo DONE="$SERIESDIR"/done

warn () {
	echo "$@" >&2
}
require_clean_work_tree () {
	# test if working tree is dirty
	git rev-parse --verify HEAD > /dev/null &&
	git update-index --refresh &&
	test -z "`git diff-files --name-only`" &&
	test -z "`git diff-index --cached --name-only HEAD`" ||
	die "Working tree is dirty"
}
ORIG_REFLOG_ACTION="$GIT_REFLOG_ACTION"
comment_for_reflog () {
	if test -z "$ORIG_REFLOG_ACTION"; then
		GIT_REFLOG_ACTION="edit-patch-series($1)"
		export GIT_REFLOG_ACTION
	fi
}
mark_action_done () {
	sed -n 1p < "$TODO" >> "$DONE"
	sed -n '2,$p' < "$TODO" >> "$TODO".new
	mv -f "$TODO".new "$TODO"
}
do_next () {
	read command sha1 rest < "$TODO"
	case "$command" in
	\#)
		mark_action_done
		continue
	;;
	pick)
		comment_for_reflog pick
		mark_action_done
		git cherry-pick "$sha1" || \
			die "Could not apply $sha1... $rest"
	;;
	edit)
		comment_for_reflog edit
		mark_action_done
		git cherry-pick "$sha1" || \
			die "Could not apply $sha1... $rest"
		exit 0
	;;
	merge)
		comment_for_reflog merge
		test -s "$DONE" &&
			die "Cannot 'merge' without a previous commit"
		mark_action_done
		failed=f
		git cherry-pick -n "$sha1" || failed=t
		MSG="$SERIESDIR"/message
		echo "# This is a combination of two commits." > "$MSG"
		echo "# The first commit's message is:" >> "$MSG"
		git cat-file commit HEAD | sed -n '/^$/,$p' >> "$MSG"
		echo >> "$MSG"
		echo "# And this is the 2nd commit message:" >> "$MSG"
		echo >> "$MSG"
		cat .msg >> "$MSG"
		case $failed in
		f)
			# Usually, I would use --amend here, but -F forbids it
			git reset --soft HEAD^
			git commit -F "$MSG" -e
		;;
		t)
			cp "$MSG" .msg
			warn "Could not apply $sha1... $rest"
			warn "After you fixed that, commit the result with"
			warn
			warn "	git commit --reedit-message .msg"
			exit 1
		esac
	;;
	*)
		warn "Unknown command: $command $sha1 $rest"
		warn "Please fix this in the file $TODO."
		exit 1
	esac
	test -s "$TODO" && continue
	HEAD=$(git rev-parse HEAD)
	HEADNAME=$(cat "$SERIESDIR"/head-name)
	git update-ref $HEADNAME $HEAD &&
	git symbolic-ref HEAD $HEADNAME &&
	rm -rf "$SERIESDIR" &&
	warn "Successfully edited patch series and updated $HEADNAME."
	exit $?
}
case "$1" in
start)
	comment_for_reflog start
	HEAD=$(git rev-parse --verify HEAD) || die "No HEAD?"
	BASE=$(git rev-parse --verify "$2") || die "Invalid base"
	# DWIM: use the merge base
	MERGEBASE=$(git merge-base $HEAD $BASE)
	if test "$BASE" != "$MERGEBASE"
	then
		CANDIDATES="$(git merge-base --all $HEAD $BASE)"
		if test "$MERGEBASE" != "$CANDIDATES"
		then
			warn "Error: Multiple merge bases found:"
			warn "$CANDIDATES"
			rm -rf "$SERIESDIR"
			exit 1
		fi
		BASE=$MERGEBASE
	fi
	require_clean_work_tree
	git var GIT_COMMITTER_IDENT >/dev/null || exit
	test -d "$SERIESDIR" &&
		die "Edit-patch-series already started"
	test "z$(git rev-list --parents $BASE..$HEAD | grep " .* ")" != z &&
		die "Cannot edit a series including merges"
	mkdir "$SERIESDIR" || die "Could not create temporary $SERIESDIR"
	git symbolic-ref HEAD > "$SERIESDIR"/head-name || die "Could not get HEAD"
	echo $HEAD > "$SERIESDIR"/head
	echo $BASE > "$SERIESDIR"/base
	cat > "$TODO" << EOF
# Edit the patch series by exchanging lines.  The commits will be
# arranged in the given order.  If you want to edit a commit, replace
# the "pick" command with "edit".  If you want to merge the changes of
# a commit A into a commit B, place A directly after B, and replace the
# "pick" command with "merge".
EOF
	git rev-list --reverse --pretty=oneline --abbrev-commit --abbrev=7 \
		$BASE..$HEAD | sed "s/^/pick /" >> "$TODO"
	cp "$TODO" "$TODO".backup
	${VISUAL:-${EDITOR:-vi}} "$TODO" || warn "Could not execute editor"
	if git diff --no-index "$TODO" "$TODO".backup > /dev/null
	then
		rm -rf "$SERIESDIR"
		warn "No changes"
		exit 0
	fi
	git checkout $BASE || die "Could not checkout $BASE"
	while :
	do
		do_next
	done
;;
continue)
	comment_for_reflog continue
	test -d "$SERIESDIR" || die "No edit-patch-series running"
	require_clean_work_tree
	while :
	do
		do_next
	done
;;
reset)
	comment_for_reflog reset
	test -d "$SERIESDIR" || die "No edit-patch-series running"
	HEADNAME=$(cat "$SERIESDIR"/head-name)
	force=
	case "$2" in
	-f|--force)
		git symbolic-ref HEAD $HEADNAME &&
		git reset --hard
	;;
	*)
		git checkout $HEADNAME
	esac &&
	rm -rf "$SERIESDIR"
;;
*)
	usage
esac
Peter Baumann· Feb 26, 2007, 13:18 UTC · re: Johannes Schindelin · lore

Re: RFC: Patch editing

Johannes Schindelin <Johannes.Schindelin@gmx.de> schrieb:
Show 54 quoted lines
> Hi list,
>
> while I was hacking on another issue, I realized just how often I would 
> like to stash away a fix which is unrelated (but often triggered) by the 
> theme of the current topic branch. Or I fix an earlier commit, which is 
> not the tip of the branch, so I cannot --amend it.
>
> My common practice is to commit it nevertheless, and sort the topic 
> branches out later, by cherry-picking my way through the commits.
>
> This is a tedious and error-prone procedure, and I often wished I knew how 
> to use StGIT. But then, StGIT is overkill for me: on some machines I work 
> on, there is no Python installed, I do not really need to have a history 
> on the order and version of patches, and I do not need to preserve author 
> and committer information *1*.
>
> Therefore, I wrote this extremely simple script to sort out the order of 
> commits, and possibly merging some. The script lets you edit the commit 
> list upon start (reordering it, or removing commits), and then works on 
> that list. It has three subcommands:
>
> 	start <base>
> 	continue
> 	reset [-f]
>
> The subcommand "start" takes a base commit (actually, it will take the 
> merge base of HEAD and that base commit) from which to start. It builds a 
> commit list and opens it in an editor. The rows of the list have the form 
> "<action> <sha1> <oneline>". The oneline description is purely for ease of 
> use.
>
> The three possible actions are "pick" (the default), "edit" and "merge". 
> "pick" will just cherry-pick that commit, "edit" will stop after 
> cherry-picking so that you can make a small fixup (in the code or in the 
> commit message), and "merge" will try to apply the corresponding patch, 
> amend the previous commit with the result, and let you edit the combined 
> commit message.
>
> If a patch fails, or "edit" was specified, the loop is interrupted for 
> fixups. Use the subcommand "continue" to restart the loop (the working 
> tree has to be clean, though).
>
> Once there are no more commits to be picked, the original branch is 
> updated to that new tip.
>
> If you decide at some point that you do not want to rewrite the patches 
> after all, you can use the subcommand "reset".
>
> To see which commits were already applied, you can inspect .series/done, 
> and likewise .series/todo for what is to be applied yet. You can even edit 
> .series/todo if you decide on another course of action.
>
> Anyway, it is a relatively short and stupid script.
>

Nice. I tried it on a simple testcase to just rearrange some commits and it worked as expected. That was exactly what I was looking for!

I tried for a while stgit, but it seemed like overkill to me and I messed up my test repo several times, propably because I have done something wrong so I gave up.

-Peter
Shawn O. Pearce· Feb 26, 2007, 18:03 UTC · re: Johannes Schindelin · lore

Re: RFC: Patch editing

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Therefore, I wrote this extremely simple script to sort out the order of 
> commits, and possibly merging some. The script lets you edit the commit 
> list upon start (reordering it, or removing commits), and then works on 
> that list. It has three subcommands:
This simple tool rocks.  Thank you!  ;-)
-- 
Shawn.
Johannes Schindelin· Feb 26, 2007, 18:52 UTC · re: Shawn O. Pearce · lore

Re: RFC: Patch editing

Hi,
On Mon, 26 Feb 2007, Shawn O. Pearce wrote:
Show 7 quoted lines
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > Therefore, I wrote this extremely simple script to sort out the order of 
> > commits, and possibly merging some. The script lets you edit the commit 
> > list upon start (reordering it, or removing commits), and then works on 
> > that list. It has three subcommands:
> 
> This simple tool rocks.  Thank you!  ;-)

I am undecided how to continue. Originally, I wanted to add an "--onto <commit>" option, and maybe an "edit" subcommand, but since Junio made me realize that it is more similar to git-rebase than I previously thought, and that they should merge, possibly in the form of a builtin...

But in order to merge the two, I have to learn about rebase's syntax first ;-)

Ciao, Dscho

Shawn O. Pearce· Feb 26, 2007, 18:56 UTC · re: Johannes Schindelin · lore

Re: RFC: Patch editing

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
Show 14 quoted lines
> On Mon, 26 Feb 2007, Shawn O. Pearce wrote:
> 
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > Therefore, I wrote this extremely simple script to sort out the order of 
> > > commits, and possibly merging some. The script lets you edit the commit 
> > > list upon start (reordering it, or removing commits), and then works on 
> > > that list. It has three subcommands:
> > 
> > This simple tool rocks.  Thank you!  ;-)
> 
> I am undecided how to continue. Originally, I wanted to add an "--onto 
> <commit>" option, and maybe an "edit" subcommand, but since Junio made me 
> realize that it is more similar to git-rebase than I previously thought, 
> and that they should merge, possibly in the form of a builtin...

Yea - this is a lot like rebase. I was also thinking that the -m (merge mode) in rebase probably should be the only option offered. I don't see why rebase should format-patch|am when we have the whole commit available and merge-recursive does an excellent job on tree level merges.

> But in order to merge the two, I have to learn about rebase's syntax first 
> ;-)
Its easier than it looks.  ;-)
-- 
Shawn.
Junio C Hamano· Feb 26, 2007, 19:51 UTC · re: Shawn O. Pearce · lore

Re: RFC: Patch editing

"Shawn O. Pearce" <spearce@spearce.org> writes:
Show 5 quoted lines
> Yea - this is a lot like rebase.  I was also thinking that the -m
> (merge mode) in rebase probably should be the only option offered.
> I don't see why rebase should format-patch|am when we have the
> whole commit available and merge-recursive does an excellent job
> on tree level merges.

One reason is that it just matches the practice to the mental model. Rebasing is like sending yourself a patch series and applying with 'am' on top of a known commit afresh, which is exactly what the command without -m does.

The other historical reason is that reconstructing (with -3) the only part of the tree that matters in the 3-way merge and running the merge was a lot faster with the merge tool we had, than a full 3-way merge.

Daniel Barkalow· Feb 27, 2007, 07:14 UTC · re: Johannes Schindelin · lore

Re: RFC: Patch editing

On Sun, 25 Feb 2007, Johannes Schindelin wrote:
Show 20 quoted lines
> Hi list,
> 
> while I was hacking on another issue, I realized just how often I would 
> like to stash away a fix which is unrelated (but often triggered) by the 
> theme of the current topic branch. Or I fix an earlier commit, which is 
> not the tip of the branch, so I cannot --amend it.
> 
> My common practice is to commit it nevertheless, and sort the topic 
> branches out later, by cherry-picking my way through the commits.
> 
> This is a tedious and error-prone procedure, and I often wished I knew how 
> to use StGIT. But then, StGIT is overkill for me: on some machines I work 
> on, there is no Python installed, I do not really need to have a history 
> on the order and version of patches, and I do not need to preserve author 
> and committer information *1*.
> 
> Therefore, I wrote this extremely simple script to sort out the order of 
> commits, and possibly merging some. The script lets you edit the commit 
> list upon start (reordering it, or removing commits), and then works on 
> that list.

For much the same reason, I wrote a script that entirely ignores the intermediate commits in a throw-away head, and lets you trim down the diff between the mainline and your head, and arrange it into a new patch series. Never got around to making it particularly nice, but it might be a good starting point for someone who wants to make something useable. (In its current state, you need some external tool that you're comfortable editing diffs with, and it doesn't do anything with any commit messages you may have written)

	-Daniel
*This .sig left intentionally blank*
#!/bin/sh
if [ "$1" != "" ]
then
  git-symbolic-ref REFINE_HEAD refs/heads/$1
fi
if [ -f .git/refine-patch ]
then
  if ! git-apply --index .git/refine-patch
  then
    exit 1
  fi
  rm .git/refine-patch
  echo "Applied selected changes; verify and commit"
  exit 0
fi
if git-status > /dev/null
then
  echo "Uncommitted changes; verify and commit"
  exit 0
fi
git-diff -M HEAD REFINE_HEAD > .git/refine-patch
if [ -s .git/refine-patch ]
then
  $EDITOR .git/refine-patch
else
  echo "All done"
  rm .git/refine-patch
fi
Johannes Schindelin· Feb 27, 2007, 11:54 UTC · re: Daniel Barkalow · lore

Re: RFC: Patch editing

Hi,
On Tue, 27 Feb 2007, Daniel Barkalow wrote:
> For much the same reason, I wrote a script that entirely ignores the 
> intermediate commits in a throw-away head, and lets you trim down the 
> diff between the mainline and your head, and arrange it into a new patch 
> series.

It looks to me like you just start a new branch, get the state of an existing commit *1*, and then "git add -i" your way through that diff.

This is slightly different from my work flow:
- I can have overlapping changes (i.e. one commit fixes something which 
  gets refactored in the next), and
- I try not to touch the code when editing the patch series. Only in the 
  conflicting case, I _have_ to edit it.

The latter means, of course, that the commits in the throwaway branch _must_ be a superset of the commits I want to have in the cleaned up branch. (Meaning that I never commit two unrelated things with the same commit.)

To achieve that, I use my own version of "git add -i" quite often while composing the throwaway branch. For example, when I found a bug with an easy fix, in the middle of something different, and the fix touches a file that is already changed, I only commit the appropriate hunks of that file.

Ciao, Dscho

*1* It is not really as easy as "git diff ..other-branch | git apply", since you would lose valuable information about added files, so you have to be very careful there.

Daniel Barkalow· Feb 27, 2007, 17:35 UTC · re: Johannes Schindelin · lore

Re: RFC: Patch editing

On Tue, 27 Feb 2007, Johannes Schindelin wrote:
Show 11 quoted lines
> Hi,
> 
> On Tue, 27 Feb 2007, Daniel Barkalow wrote:
> 
> > For much the same reason, I wrote a script that entirely ignores the 
> > intermediate commits in a throw-away head, and lets you trim down the 
> > diff between the mainline and your head, and arrange it into a new patch 
> > series.
> 
> It looks to me like you just start a new branch, get the state of an 
> existing commit *1*, and then "git add -i" your way through that diff.
Essentially, yes.
> This is slightly different from my work flow:
> 
> - I can have overlapping changes (i.e. one commit fixes something which 
>   gets refactored in the next), and

That's true; I occasionally add some change that will go away in the next patch (or a later patch). This goes in between applying the cut-down patch and committing it (I also often build and test at this point, to make sure that my intermediate states work; so I can leave thing not working in the patch, and fix the build errors to generate the temporary intermediate state).

Show 12 quoted lines
> - I try not to touch the code when editing the patch series. Only in the 
>   conflicting case, I _have_ to edit it.
> 
> The latter means, of course, that the commits in the throwaway branch 
> _must_ be a superset of the commits I want to have in the cleaned up 
> branch. (Meaning that I never commit two unrelated things with the same 
> commit.)
> 
> To achieve that, I use my own version of "git add -i" quite often while 
> composing the throwaway branch. For example, when I found a bug with an 
> easy fix, in the middle of something different, and the fix touches a file 
> that is already changed, I only commit the appropriate hunks of that file.

One nice thing about my method is that, if you've had to make a dozen unrelated changes to get something to compile and run far enough to test whether any of the changes are actually correct, you can be sure to get that work preserved. I'd be a lot less comfortable preparing intermediate states if I didn't have the final state securely tucked away.

I don't really trust myself to not lose some partially-working state before I reach a state that's worthy of a commit, so I generate a lot of unworthy commits as part of the process of generating a state worth committing. I also sometimes want to use multiple computers in the course of reaching a state worthy of a commit; using git's state-distribution mechanism for that is really nice.

> *1* It is not really as easy as "git diff ..other-branch | git apply", 
> since you would lose valuable information about added files, so you have 
> to be very careful there.
"git apply --index" actually recovers the information about added files.
	-Daniel
*This .sig left intentionally blank*
Johannes Schindelin· Feb 27, 2007, 20:07 UTC · re: Daniel Barkalow · lore

Re: RFC: Patch editing

Hi,
On Tue, 27 Feb 2007, Daniel Barkalow wrote:
Show 6 quoted lines
> One nice thing about my method is that, if you've had to make a dozen 
> unrelated changes to get something to compile and run far enough to test 
> whether any of the changes are actually correct, you can be sure to get 
> that work preserved. I'd be a lot less comfortable preparing 
> intermediate states if I didn't have the final state securely tucked 
> away.

You _could_ still ensure that by looking in the reflog which was your old tip-of-branch, and git-diff with that.

But I agree. That is why I commit _everything_ before rearranging.

Ciao, Dscho

Daniel Barkalow· Feb 27, 2007, 22:07 UTC · re: Johannes Schindelin · lore

Re: RFC: Patch editing

On Tue, 27 Feb 2007, Johannes Schindelin wrote:
Show 15 quoted lines
> Hi,
> 
> On Tue, 27 Feb 2007, Daniel Barkalow wrote:
> 
> > One nice thing about my method is that, if you've had to make a dozen 
> > unrelated changes to get something to compile and run far enough to test 
> > whether any of the changes are actually correct, you can be sure to get 
> > that work preserved. I'd be a lot less comfortable preparing 
> > intermediate states if I didn't have the final state securely tucked 
> > away.
> 
> You _could_ still ensure that by looking in the reflog which was your old 
> tip-of-branch, and git-diff with that.
> 
> But I agree. That is why I commit _everything_ before rearranging.

I think you're misunderstanding me; I want to use git's archival/distribution functionality before I have a commit that I can put a useful message on. This means that, at some point, I'm making real commits, and I know what final state I want, but that final state involves unrelated changes.

I think I usually come up with something like: 7 patches related to the functionality I'm working on, 1 patch that fixes an old bug that became important due to the change, and 2 patches which improve the debugging infrastructure. And the actual sequence of intermediate states that my code was in is something like: API written, stub implementations, some code that suggests what should happen; program calling the API and crashing; version that is written but buggy; version that's buggy but verbose; version that's working but verbose. In refining the work, I drop or "if (DEFINED_TO_0_DEBUG)" the messages, split out the patches that support the new kinds of messages, and include only working versions of functions. And then I write commit messages that talk about the code and sign them.

Am I unusual in being afraid of losing work in a state that contains 3 different half-features?

	-Daniel
*This .sig left intentionally blank*
Johannes Schindelin· Feb 27, 2007, 22:37 UTC · re: Daniel Barkalow · lore

Re: RFC: Patch editing

Hi,
On Tue, 27 Feb 2007, Daniel Barkalow wrote:
Show 26 quoted lines
> On Tue, 27 Feb 2007, Johannes Schindelin wrote:
> 
> > On Tue, 27 Feb 2007, Daniel Barkalow wrote:
> > 
> > > One nice thing about my method is that, if you've had to make a dozen 
> > > unrelated changes to get something to compile and run far enough to test 
> > > whether any of the changes are actually correct, you can be sure to get 
> > > that work preserved. I'd be a lot less comfortable preparing 
> > > intermediate states if I didn't have the final state securely tucked 
> > > away.
> > 
> > You _could_ still ensure that by looking in the reflog which was your old 
> > tip-of-branch, and git-diff with that.
> > 
> > But I agree. That is why I commit _everything_ before rearranging.
> 
> I think you're misunderstanding me; I want to use git's 
> archival/distribution functionality before I have a commit that I can put 
> a useful message on. This means that, at some point, I'm making real 
> commits, and I know what final state I want, but that final state involves 
> unrelated changes.
> 
> I think I usually come up with something like: 7 patches related to the 
> functionality I'm working on, 1 patch that fixes an old bug that became 
> important due to the change, and 2 patches which improve the debugging 
> infrastructure.
Same for me.
> And the actual sequence of intermediate states that my 
> code was in is something like: API written, stub implementations, some 
> code that suggests what should happen; program calling the API and 
> crashing; version that is written but buggy;
Still same for me.
> version that's buggy but verbose;
I don't commit that.

However, if I _do_, it _only_ contains the messages. And in that case rebase--interactive (this is the new working title for edit-patch-series) allows you to just kill these commits...

> version that's working but verbose.
Would be handled by (3way) cherry-pick.
> Am I unusual in being afraid of losing work in a state that contains 3 
> different half-features?

Not at all. I often do "git checkout -b temp && git commit -a -m temp && git checkout <oldname>".

Ciao, Dscho

Karl Hasselström· Feb 28, 2007, 10:13 UTC · re: Daniel Barkalow · lore

Re: RFC: Patch editing

On 2007-02-27 17:07:11 -0500, Daniel Barkalow wrote:
Show 15 quoted lines
> I think I usually come up with something like: 7 patches related to
> the functionality I'm working on, 1 patch that fixes an old bug that
> became important due to the change, and 2 patches which improve the
> debugging infrastructure. And the actual sequence of intermediate
> states that my code was in is something like: API written, stub
> implementations, some code that suggests what should happen; program
> calling the API and crashing; version that is written but buggy;
> version that's buggy but verbose; version that's working but
> verbose. In refining the work, I drop or "if (DEFINED_TO_0_DEBUG)"
> the messages, split out the patches that support the new kinds of
> messages, and include only working versions of functions. And then I
> write commit messages that talk about the code and sign them.
>
> Am I unusual in being afraid of losing work in a state that contains
> 3 different half-features?

My usual workflow looks like this too. I start out with a rough plan of how to accomplish my goal with a number of smaller changes, but it always turns out that I need more debug code, need to fix old bugs in the middle of the process, need to fix silly bugs in earlier commits in the series I'm building, and so on. I record this work with lots of small commits. When I'm done, and usually at some intermediate stages as well, I coalesce and reorder these commits to get a history resembling my initial plan.

StGit is really helpful here. It doesn't actually do anything I couldn't do manually with just git, but it makes it _simple_, and tracks all the metadata for me so that I don't get a chance to make a mess of things.

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle
Johannes Schindelin· Mar 1, 2007, 23:30 UTC · re: Johannes Schindelin · lore

Updated version, was Re: RFC: Patch editing

Hi,

this is an updated version, which got even less testing than the first version :-( However, the changes were small:

- added an attribution to Eric Biederman for the idea,
- if you mark a commit as "edit", it will _not_ be committed, so that
  you do not need --amend _both_ in case of conflicts and no conflicts 
  (noticed by Shawn Pearce),
- a "merge" is refused when it is the _first_ in the list (the first 
  version erroneously checked the opposite...)
- for a failed "merge", like for an "edit", you do not need --amend both 
  in case of conflicts and no conflicts, and
- the wrong usage of the "--reedit-message" flag was replaced by the 
  appropriate "-F .msg -e".

My plans are _not_ to turn this into git-rebase--interactive.sh, as I originally planned. Instead, I will try to make git-rebase a builtin, and add a "-i" flag which does the equivalent of this script.

BTW would people be mad at me if I did _not_ imitate git-rebase.sh (call format-patch and feed that into apply), but rather used cherry-pick throughout?

Ciao, Dscho

-- snipsnap -- #!/bin/sh # # Copyright (c) 2006 Johannes E. Schindelin

# SHORT DESCRIPTION # # This is a really stupid script to arrange a patch series for submission. # It does not care for authorship or dates, all it does is make it easy # to fix up commits in the middle of a series, and rearrange commits. # # The original idea comes from Eric W. Biederman, in # http://article.gmane.org/gmane.comp.version-control.git/22407 # # MOTIVATION # # It is extremely useful for this type of workflow: # # 1. have a wonderful idea # 2. hack on the code # 3. prepare a series for submission # 4. submit # # where the point (2) consists of several instances of # # A.1. finish something worthy of a commit # A.2. commit # # and/or # # B.1. realize that something does not work # B.2. fix that # B.3. commit it # # Sometimes the thing fixed in B.2. cannot be amended to the not-quite # perfect commit it fixes, because that commit is buried deeply in a # patch series. # # Use this script after plenty of "A"s and "B"s, by rearranging, and # possibly editing and merging commits. # # USAGE: # # The subcommand "start" will make a list of the commits in the patch # series <base>..HEAD, where <base> is the commit identiefied by the # parameter. # # It will automatically start an editor, where you can rearrange the # commits. The list looks more or less like this: # # pick deadbee The oneline of this commit # pick fa1afe1 The oneline of the next commit # ... # # By replacing the command "pick" with "edit" you can tell # this script to stop the loop so you can fix up the commit by editing # files and/or the commit message. # # When replacing the command "pick" with "merge, the script will merge # this commit's changes into the previous commit, munge the commit # messages of both, and open the commit message editor. # # In both cases, or when a "pick" does not succeed (because of merge # errors), the loop will stop to let you fix things, and you can continue # the loop with `git edit-patch-series continue`.

USAGE='(start <basecommit>| continue | reset [--force])'

. git-sh-setup require_work_tree

SERIESDIR="$(pwd)/.series" TODO="$SERIESDIR"/todo DONE="$SERIESDIR"/done

warn () {
	echo "$@" >&2
}
require_clean_work_tree () {
	# test if working tree is dirty
	git rev-parse --verify HEAD > /dev/null &&
	git update-index --refresh &&
	test -z "`git diff-files --name-only`" &&
	test -z "`git diff-index --cached --name-only HEAD`" ||
	die "Working tree is dirty"
}
ORIG_REFLOG_ACTION="$GIT_REFLOG_ACTION"
comment_for_reflog () {
	if test -z "$ORIG_REFLOG_ACTION"; then
		GIT_REFLOG_ACTION="edit-patch-series($1)"
		export GIT_REFLOG_ACTION
	fi
}
mark_action_done () {
	sed -n 1p < "$TODO" >> "$DONE"
	sed -n '2,$p' < "$TODO" >> "$TODO".new
	mv -f "$TODO".new "$TODO"
}
do_next () {
	read command sha1 rest < "$TODO"
	case "$command" in
	\#)
		mark_action_done
		continue
	;;
	pick)
		comment_for_reflog pick
		mark_action_done
		git cherry-pick "$sha1" || \
			die "Could not apply $sha1... $rest"
	;;
	edit)
		comment_for_reflog edit
		mark_action_done
		git cherry-pick -n "$sha1" || \
			die "Could not apply $sha1... $rest"
		warn
		warn "After you edited the files, commit the result with"
		warn
		warn "	git commit -F .msg -e"
		warn
		exit 0
	;;
	merge)
		comment_for_reflog merge
		test -s "$DONE" ||
			die "Cannot 'merge' without a previous commit"
		mark_action_done
		failed=f
		git cherry-pick -n "$sha1" || failed=t
		MSG="$SERIESDIR"/message
		echo "# This is a combination of two commits." > "$MSG"
		echo "# The first commit's message is:" >> "$MSG"
		git cat-file commit HEAD | sed -n '/^$/,$p' >> "$MSG"
		echo >> "$MSG"
		echo "# And this is the 2nd commit message:" >> "$MSG"
		echo >> "$MSG"
		cat .msg >> "$MSG"
		git reset --soft HEAD^
		case $failed in
		f)
			# Usually, I would use --amend here, but -F forbids it
			git commit -F "$MSG" -e
		;;
		t)
			cp "$MSG" .msg
			warn
			warn "Could not apply $sha1... $rest"
			warn "After you fixed that, commit the result with"
			warn
			warn "	git commit -F .msg -e"
			warn
			exit 1
		esac
	;;
	*)
		warn "Unknown command: $command $sha1 $rest"
		warn "Please fix this in the file $TODO."
		exit 1
	esac
	test -s "$TODO" && continue
	HEAD=$(git rev-parse HEAD)
	HEADNAME=$(cat "$SERIESDIR"/head-name)
	git update-ref $HEADNAME $HEAD &&
	git symbolic-ref HEAD $HEADNAME &&
	rm -rf "$SERIESDIR" &&
	warn "Successfully edited patch series and updated $HEADNAME."
	exit $?
}
case "$1" in
start)
	comment_for_reflog start
	HEAD=$(git rev-parse --verify HEAD) || die "No HEAD?"
	BASE=$(git rev-parse --verify "$2") || die "Invalid base"
	# DWIM: use the merge base
	MERGEBASE=$(git merge-base $HEAD $BASE)
	if test "$BASE" != "$MERGEBASE"
	then
		CANDIDATES="$(git merge-base --all $HEAD $BASE)"
		if test "$MERGEBASE" != "$CANDIDATES"
		then
			warn "Error: Multiple merge bases found:"
			warn "$CANDIDATES"
			rm -rf "$SERIESDIR"
			exit 1
		fi
		BASE=$MERGEBASE
	fi
	require_clean_work_tree
	git var GIT_COMMITTER_IDENT >/dev/null || exit
	test -d "$SERIESDIR" &&
		die "Edit-patch-series already started"
	test "z$(git rev-list --parents $BASE..$HEAD | grep " .* ")" != z &&
		die "Cannot edit a series including merges"
	mkdir "$SERIESDIR" || die "Could not create temporary $SERIESDIR"
	git symbolic-ref HEAD > "$SERIESDIR"/head-name || die "Could not get HEAD"
	echo $HEAD > "$SERIESDIR"/head
	echo $BASE > "$SERIESDIR"/base
	cat > "$TODO" << EOF
# Edit the patch series by exchanging lines.  The commits will be
# arranged in the given order.  If you want to edit a commit, replace
# the "pick" command with "edit".  If you want to merge the changes of
# a commit A into a commit B, place A directly after B, and replace the
# "pick" command with "merge".
EOF
	git rev-list --reverse --pretty=oneline --abbrev-commit --abbrev=7 \
		$BASE..$HEAD | sed "s/^/pick /" >> "$TODO"
	cp "$TODO" "$TODO".backup
	${VISUAL:-${EDITOR:-vi}} "$TODO" || warn "Could not execute editor"
	if git diff --no-index "$TODO" "$TODO".backup > /dev/null
	then
		rm -rf "$SERIESDIR"
		warn "No changes"
		exit 0
	fi
	git checkout $BASE || die "Could not checkout $BASE"
	while :
	do
		do_next
	done
;;
continue)
	comment_for_reflog continue
	test -d "$SERIESDIR" || die "No edit-patch-series running"
	require_clean_work_tree
	while :
	do
		do_next
	done
;;
reset)
	comment_for_reflog reset
	test -d "$SERIESDIR" || die "No edit-patch-series running"
	HEADNAME=$(cat "$SERIESDIR"/head-name)
	force=
	case "$2" in
	-f|--force)
		git symbolic-ref HEAD $HEADNAME &&
		git reset --hard
	;;
	*)
		git checkout $HEADNAME
	esac &&
	rm -rf "$SERIESDIR"
;;
*)
	usage
esac
Junio C Hamano· Mar 1, 2007, 23:59 UTC · re: Johannes Schindelin · lore

Re: Updated version, was Re: RFC: Patch editing

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 7 quoted lines
> My plans are _not_ to turn this into git-rebase--interactive.sh, as I 
> originally planned. Instead, I will try to make git-rebase a builtin, and 
> add a "-i" flag which does the equivalent of this script.
>
> BTW would people be mad at me if I did _not_ imitate git-rebase.sh (call 
> format-patch and feed that into apply), but rather used cherry-pick 
> throughout?

Then that C built-in would not replace git-rebase but only "git-rebase -m".

I very often find it easier to deal with a conflicting rebase by editing the patch text, so yes I would imagine I would be rather upset, but I do not know about others.

← back to recent threads