All of lore.kernel.org
 help / color / mirror / Atom feed
* RFC: Patch editing
@ 2007-02-25 21:59 Johannes Schindelin
  2007-02-26 13:18 ` Peter Baumann
                   ` (3 more replies)
  0 siblings, 4 replies; 15+ messages in thread
From: Johannes Schindelin @ 2007-02-25 21:59 UTC (permalink / raw)
  To: git

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: RFC: Patch editing
  2007-02-25 21:59 RFC: Patch editing Johannes Schindelin
@ 2007-02-26 13:18 ` Peter Baumann
  2007-02-26 18:03 ` Shawn O. Pearce
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 15+ messages in thread
From: Peter Baumann @ 2007-02-26 13:18 UTC (permalink / raw)
  To: git

Johannes Schindelin <Johannes.Schindelin@gmx.de> schrieb:
> 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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: RFC: Patch editing
  2007-02-25 21:59 RFC: Patch editing Johannes Schindelin
  2007-02-26 13:18 ` Peter Baumann
@ 2007-02-26 18:03 ` Shawn O. Pearce
  2007-02-26 18:52   ` Johannes Schindelin
  2007-02-27  7:14 ` Daniel Barkalow
  2007-03-01 23:30 ` Updated version, was " Johannes Schindelin
  3 siblings, 1 reply; 15+ messages in thread
From: Shawn O. Pearce @ 2007-02-26 18:03 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: git

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.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: RFC: Patch editing
  2007-02-26 18:03 ` Shawn O. Pearce
@ 2007-02-26 18:52   ` Johannes Schindelin
  2007-02-26 18:56     ` Shawn O. Pearce
  0 siblings, 1 reply; 15+ messages in thread
From: Johannes Schindelin @ 2007-02-26 18:52 UTC (permalink / raw)
  To: Shawn O. Pearce; +Cc: git

Hi,

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...

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

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: RFC: Patch editing
  2007-02-26 18:52   ` Johannes Schindelin
@ 2007-02-26 18:56     ` Shawn O. Pearce
  2007-02-26 19:51       ` Junio C Hamano
  0 siblings, 1 reply; 15+ messages in thread
From: Shawn O. Pearce @ 2007-02-26 18:56 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: git

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> 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.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: RFC: Patch editing
  2007-02-26 18:56     ` Shawn O. Pearce
@ 2007-02-26 19:51       ` Junio C Hamano
  0 siblings, 0 replies; 15+ messages in thread
From: Junio C Hamano @ 2007-02-26 19:51 UTC (permalink / raw)
  To: Shawn O. Pearce; +Cc: Johannes Schindelin, git

"Shawn O. Pearce" <spearce@spearce.org> writes:

> 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.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: RFC: Patch editing
  2007-02-25 21:59 RFC: Patch editing Johannes Schindelin
  2007-02-26 13:18 ` Peter Baumann
  2007-02-26 18:03 ` Shawn O. Pearce
@ 2007-02-27  7:14 ` Daniel Barkalow
  2007-02-27 11:54   ` Johannes Schindelin
  2007-03-01 23:30 ` Updated version, was " Johannes Schindelin
  3 siblings, 1 reply; 15+ messages in thread
From: Daniel Barkalow @ 2007-02-27  7:14 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: git

On Sun, 25 Feb 2007, Johannes Schindelin wrote:

> 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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: RFC: Patch editing
  2007-02-27  7:14 ` Daniel Barkalow
@ 2007-02-27 11:54   ` Johannes Schindelin
  2007-02-27 17:35     ` Daniel Barkalow
  0 siblings, 1 reply; 15+ messages in thread
From: Johannes Schindelin @ 2007-02-27 11:54 UTC (permalink / raw)
  To: Daniel Barkalow; +Cc: git

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.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: RFC: Patch editing
  2007-02-27 11:54   ` Johannes Schindelin
@ 2007-02-27 17:35     ` Daniel Barkalow
  2007-02-27 20:07       ` Johannes Schindelin
  0 siblings, 1 reply; 15+ messages in thread
From: Daniel Barkalow @ 2007-02-27 17:35 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: git

On Tue, 27 Feb 2007, Johannes Schindelin wrote:

> 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).

> - 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*

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: RFC: Patch editing
  2007-02-27 17:35     ` Daniel Barkalow
@ 2007-02-27 20:07       ` Johannes Schindelin
  2007-02-27 22:07         ` Daniel Barkalow
  0 siblings, 1 reply; 15+ messages in thread
From: Johannes Schindelin @ 2007-02-27 20:07 UTC (permalink / raw)
  To: Daniel Barkalow; +Cc: git

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.

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: RFC: Patch editing
  2007-02-27 20:07       ` Johannes Schindelin
@ 2007-02-27 22:07         ` Daniel Barkalow
  2007-02-27 22:37           ` Johannes Schindelin
  2007-02-28 10:13           ` Karl Hasselström
  0 siblings, 2 replies; 15+ messages in thread
From: Daniel Barkalow @ 2007-02-27 22:07 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: git

On Tue, 27 Feb 2007, Johannes Schindelin wrote:

> 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*

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: RFC: Patch editing
  2007-02-27 22:07         ` Daniel Barkalow
@ 2007-02-27 22:37           ` Johannes Schindelin
  2007-02-28 10:13           ` Karl Hasselström
  1 sibling, 0 replies; 15+ messages in thread
From: Johannes Schindelin @ 2007-02-27 22:37 UTC (permalink / raw)
  To: Daniel Barkalow; +Cc: git

Hi,

On Tue, 27 Feb 2007, Daniel Barkalow wrote:

> 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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: RFC: Patch editing
  2007-02-27 22:07         ` Daniel Barkalow
  2007-02-27 22:37           ` Johannes Schindelin
@ 2007-02-28 10:13           ` Karl Hasselström
  1 sibling, 0 replies; 15+ messages in thread
From: Karl Hasselström @ 2007-02-28 10:13 UTC (permalink / raw)
  To: Daniel Barkalow; +Cc: Johannes Schindelin, git

On 2007-02-27 17:07:11 -0500, Daniel Barkalow wrote:

> 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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Updated version, was Re: RFC: Patch editing
  2007-02-25 21:59 RFC: Patch editing Johannes Schindelin
                   ` (2 preceding siblings ...)
  2007-02-27  7:14 ` Daniel Barkalow
@ 2007-03-01 23:30 ` Johannes Schindelin
  2007-03-01 23:59   ` Junio C Hamano
  3 siblings, 1 reply; 15+ messages in thread
From: Johannes Schindelin @ 2007-03-01 23:30 UTC (permalink / raw)
  To: git

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Updated version, was Re: RFC: Patch editing
  2007-03-01 23:30 ` Updated version, was " Johannes Schindelin
@ 2007-03-01 23:59   ` Junio C Hamano
  0 siblings, 0 replies; 15+ messages in thread
From: Junio C Hamano @ 2007-03-01 23:59 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: git

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> 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.

^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2007-03-02  0:00 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-02-25 21:59 RFC: Patch editing Johannes Schindelin
2007-02-26 13:18 ` Peter Baumann
2007-02-26 18:03 ` Shawn O. Pearce
2007-02-26 18:52   ` Johannes Schindelin
2007-02-26 18:56     ` Shawn O. Pearce
2007-02-26 19:51       ` Junio C Hamano
2007-02-27  7:14 ` Daniel Barkalow
2007-02-27 11:54   ` Johannes Schindelin
2007-02-27 17:35     ` Daniel Barkalow
2007-02-27 20:07       ` Johannes Schindelin
2007-02-27 22:07         ` Daniel Barkalow
2007-02-27 22:37           ` Johannes Schindelin
2007-02-28 10:13           ` Karl Hasselström
2007-03-01 23:30 ` Updated version, was " Johannes Schindelin
2007-03-01 23:59   ` Junio C Hamano

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.