[PATCH 2/2] rebase -i: use some kind of config file to save author information

[PATCH 2/2] rebase -i: use some kind of config file to save author information

[Christian Couder]

This is better than saving in a shell script, because it will make
it much easier to port "rebase -i" to C. This also removes some sed
regexps and some "eval"s.

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
 git-rebase--interactive.sh |   78 +++++++++++++++++++++++---------------------
 1 files changed, 41 insertions(+), 37 deletions(-)

diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 92e2523..73f888a 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -40,6 +40,7 @@ MSG="$DOTEST"/message
 SQUASH_MSG="$DOTEST"/message-squash
 REWRITTEN="$DOTEST"/rewritten
 DROPPED="$DOTEST"/dropped
+SAVE_AUTHOR_INFO="$DOTEST"/save-author-info
 PRESERVE_MERGES=
 STRATEGY=
 ONTO=
@@ -117,30 +118,31 @@ mark_action_done () {
 }
 
 get_author_ident_from_commit () {
-	pick_author_script='
-	/^author /{
-		s/'\''/'\''\\'\'\''/g
-		h
-		s/^author \([^<]*\) <[^>]*> .*$/\1/
-		s/'\''/'\''\'\'\''/g
-		s/.*/GIT_AUTHOR_NAME='\''&'\''/p
-
-		g
-		s/^author [^<]* <\([^>]*\)> .*$/\1/
-		s/'\''/'\''\'\'\''/g
-		s/.*/GIT_AUTHOR_EMAIL='\''&'\''/p
-
-		g
-		s/^author [^<]* <[^>]*> \(.*\)$/\1/
-		s/'\''/'\''\'\'\''/g
-		s/.*/GIT_AUTHOR_DATE='\''&'\''/p
-
-		q
-	}
-	'
-	encoding=$(git config i18n.commitencoding || echo UTF-8)
-	git show -s --pretty=raw --encoding="$encoding" "$1" -- |
-	LANG=C LC_ALL=C sed -ne "$pick_author_script"
+	encoding=$(git config i18n.commitencoding || echo UTF-8) &&
+	author_ident_name=$(git show -s --pretty="format:%an" \
+		--encoding="$encoding" "$1" --) &&
+	author_ident_mail=$(git show -s --pretty="format:%ae" \
+		--encoding="$encoding" "$1" --) &&
+	author_ident_date=$(git show -s --pretty="format:%ai" \
+		--encoding="$encoding" "$1" --)
+}
+
+save_author_ident () {
+	GIT_CONFIG="$SAVE_AUTHOR_INFO" git config rebase.author.name \
+		"$author_ident_name" &&
+	GIT_CONFIG="$SAVE_AUTHOR_INFO" git config rebase.author.mail \
+		"$author_ident_mail" &&
+	GIT_CONFIG="$SAVE_AUTHOR_INFO" git config rebase.author.date \
+		"$author_ident_date"
+}
+
+load_author_ident () {
+	GIT_AUTHOR_NAME=$(GIT_CONFIG="$SAVE_AUTHOR_INFO" \
+		git config rebase.author.name) &&
+	GIT_AUTHOR_EMAIL=$(GIT_CONFIG="$SAVE_AUTHOR_INFO" \
+		git config rebase.author.mail) &&
+	GIT_AUTHOR_DATE=$(GIT_CONFIG="$SAVE_AUTHOR_INFO" \
+		git config rebase.author.date)
 }
 
 make_patch () {
@@ -158,8 +160,10 @@ make_patch () {
 	esac > "$DOTEST"/patch
 	test -f "$DOTEST"/message ||
 		git cat-file commit "$1" | sed "1,/^$/d" > "$DOTEST"/message
-	test -f "$DOTEST"/author-script ||
-		get_author_ident_from_commit "$1" > "$DOTEST"/author-script
+	test -f "$SAVE_AUTHOR_INFO" || {
+		get_author_ident_from_commit "$1"
+		save_author_ident
+	}
 }
 
 die_with_patch () {
@@ -294,8 +298,10 @@ pick_one_preserving_merges () {
 			test "a$1" = a-n && die "Refusing to squash a merge: $sha1"
 
 			# redo merge
-			author_script=$(get_author_ident_from_commit $sha1)
-			eval "$author_script"
+			get_author_ident_from_commit $sha1
+			GIT_AUTHOR_NAME="$author_ident_name"
+			GIT_AUTHOR_EMAIL="$author_ident_mail"
+			GIT_AUTHOR_DATE="$author_ident_date"
 			msg="$(git cat-file commit $sha1 | sed -e '1,/^$/d')"
 			# No point in merging the first parent, that's HEAD
 			new_parents=${new_parents# $first_parent}
@@ -353,8 +359,7 @@ peek_next_command () {
 }
 
 do_next () {
-	rm -f "$DOTEST"/message "$DOTEST"/author-script \
-		"$DOTEST"/amend || exit
+	rm -f "$DOTEST"/message "$DOTEST"/amend "$SAVE_AUTHOR_INFO" || exit
 	read command sha1 rest < "$TODO"
 	case "$command" in
 	'#'*|''|noop)
@@ -395,7 +400,7 @@ do_next () {
 		mark_action_done
 		make_squash_message $sha1 > "$MSG"
 		failed=f
-		author_script=$(get_author_ident_from_commit HEAD)
+		get_author_ident_from_commit HEAD
 		output git reset --soft HEAD^
 		pick_one -n $sha1 || failed=t
 		case "$(peek_next_command)" in
@@ -414,14 +419,13 @@ do_next () {
 			rm -f "$GIT_DIR"/MERGE_MSG || exit
 			;;
 		esac
-		echo "$author_script" > "$DOTEST"/author-script
+		save_author_ident
 		if test $failed = f
 		then
 			# This is like --amend, but with a different message
-			eval "$author_script"
-			GIT_AUTHOR_NAME="$GIT_AUTHOR_NAME" \
-			GIT_AUTHOR_EMAIL="$GIT_AUTHOR_EMAIL" \
-			GIT_AUTHOR_DATE="$GIT_AUTHOR_DATE" \
+			GIT_AUTHOR_NAME="$author_ident_name" \
+			GIT_AUTHOR_EMAIL="$author_ident_mail" \
+			GIT_AUTHOR_DATE="$author_ident_date" \
 			$USE_OUTPUT git commit --no-verify \
 				$MSG_OPT "$EDIT_OR_FILE" || failed=t
 		fi
@@ -536,7 +540,7 @@ do
 		then
 			: Nothing to commit -- skip this
 		else
-			. "$DOTEST"/author-script ||
+			load_author_ident ||
 				die "Cannot find the author identity"
 			amend=
 			if test -f "$DOTEST"/amend
-- 
1.6.3.GIT

Re: [PATCH 2/2] rebase -i: use some kind of config file to save author information

[Jakub Narebski]

Christian Couder <chriscool@tuxfamily.org> writes:

> Subject: [PATCH 2/2] rebase -i: use some kind of config file to save author information

Errr... "kind of" config file?  I'd say use config file format for
saving author information.

>
> This is better than saving in a shell script, because it will make
> it much easier to port "rebase -i" to C. This also removes some sed
> regexps and some "eval"s.

Would it?  Well, I guess that at least we will avoid problems with
shell quoting and shell variable expansion rules.

> 
> Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
> ---
>  git-rebase--interactive.sh |   78 +++++++++++++++++++++++---------------------
>  1 files changed, 41 insertions(+), 37 deletions(-)
> 
> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> +save_author_ident () {
> +	GIT_CONFIG="$SAVE_AUTHOR_INFO" git config rebase.author.name \
> +		"$author_ident_name" &&
> +	GIT_CONFIG="$SAVE_AUTHOR_INFO" git config rebase.author.mail \
> +		"$author_ident_mail" &&
> +	GIT_CONFIG="$SAVE_AUTHOR_INFO" git config rebase.author.date \
> +		"$author_ident_date"
> +}
> +
> +load_author_ident () {
> +	GIT_AUTHOR_NAME=$(GIT_CONFIG="$SAVE_AUTHOR_INFO" \
> +		git config rebase.author.name) &&
> +	GIT_AUTHOR_EMAIL=$(GIT_CONFIG="$SAVE_AUTHOR_INFO" \
> +		git config rebase.author.mail) &&
> +	GIT_AUTHOR_DATE=$(GIT_CONFIG="$SAVE_AUTHOR_INFO" \
> +		git config rebase.author.date)
>  }

Why not use --file=<filename> option of git-config instead?
-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: [PATCH 2/2] rebase -i: use some kind of config file to save author information

[Christian Couder]

On Saturday 20 June 2009, Jakub Narebski wrote:
> Christian Couder <chriscool@tuxfamily.org> writes:
> > Subject: [PATCH 2/2] rebase -i: use some kind of config file to save
> > author information
>
> Errr... "kind of" config file?  I'd say use config file format for
> saving author information.

Ok, I changed this in the patch series I just sent.

> > This is better than saving in a shell script, because it will make
> > it much easier to port "rebase -i" to C. This also removes some sed
> > regexps and some "eval"s.
>
> Would it?  Well, I guess that at least we will avoid problems with
> shell quoting and shell variable expansion rules.

Yeah.

> > +load_author_ident () {
> > +	GIT_AUTHOR_NAME=$(GIT_CONFIG="$SAVE_AUTHOR_INFO" \
> > +		git config rebase.author.name) &&
> > +	GIT_AUTHOR_EMAIL=$(GIT_CONFIG="$SAVE_AUTHOR_INFO" \
> > +		git config rebase.author.mail) &&
> > +	GIT_AUTHOR_DATE=$(GIT_CONFIG="$SAVE_AUTHOR_INFO" \
> > +		git config rebase.author.date)
> >  }
>
> Why not use --file=<filename> option of git-config instead?

That's a good idea. I changed that too.

Thanks,
Christian.

Re: [PATCH 2/2] rebase -i: use some kind of config file to save author information

[Johannes Schindelin]

Hi,

On Sat, 20 Jun 2009, Christian Couder wrote:

> This is better than saving in a shell script, because it will make
> it much easier to port "rebase -i" to C. This also removes some sed
> regexps and some "eval"s.

It will not make it easier to port "rebase -i" to C, as this is an 
internal file.  The user is not supposed to touch it at all.  Only "rebase 
-i".  So it would be very easy to just use a different on-disk format when 
turning "rebase -i" into a builtin.

Ciao,
Dscho

Re: [PATCH 2/2] rebase -i: use some kind of config file to save author information

[Junio C Hamano]

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

> On Sat, 20 Jun 2009, Christian Couder wrote:
>
>> This is better than saving in a shell script, because it will make
>> it much easier to port "rebase -i" to C. This also removes some sed
>> regexps and some "eval"s.
>
> It will not make it easier to port "rebase -i" to C, as this is an 
> internal file.  The user is not supposed to touch it at all.  Only "rebase 
> -i".  So it would be very easy to just use a different on-disk format when 
> turning "rebase -i" into a builtin.

"This is an internal file" is just a declaration you are making, and the
file is observable by anybody after "rebase -i" relinquishes the control
to let the user sort out the mess.  The users do not have any obligation
to honor your declaration, and strictly speaking it is a regression to
change the file format.

For example, when I realize I misspelt somebody's name (perhaps the
mailpath between the sender and me mishandled the encoding headers), I
could edit .git/rebase-merge/author-script and say "git rebase --continue"
to let auto-amend to kick in, which would use the fixed author name from
the file.

	Side note.  The current "rebase --continue" behaviour is somewhat
	inconsistent; if "edit" does not do anything to the tree, nor the
	user runs "git commit --amend', the commit is untouched, but if
	the user updates the index and says --continue without amending,
	the authorship is not taken from the auto-amended commit but is
	taken from the author-script file.  Perhaps something along the
	line of untested patch attached at the end would remedy this a
	bit? 

Having said that, if we were to change the way rebase-i leaves its state
behind so that it can pick up from where it left off, I prefer Christian's
later suggestion to leave the object name of the commit that is being
rebased in the file.  Sure, it makes it harder to lie about the authorship,
but my previous example was purely "I _could_ do this" and not "I rely on
being able to do this".

But I have this nagging feeling that we may be able to get rid of even the
"current commit".

-- >8 --

rebase -i: AUTHOR_{NAME,EMAIL,DATE} are already available in HEAD; use it.

This only changes the codepath of "rebase -i --continue" that auto-amends
the HEAD commit with the change user made but forgot to "commit --amend".

 git-rebase--interactive.sh |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index f96d887..b8608be 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -522,8 +522,7 @@ first and then run 'git rebase --continue' again."
 				git reset --soft HEAD^ ||
 				die "Cannot rewind the HEAD"
 			fi
-			export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE &&
-			git commit --no-verify -F "$DOTEST"/message -e || {
+			git commit --no-verify -c HEAD || {
 				test -n "$amend" && git reset --soft $amend
 				die "Could not commit staged changes."
 			}

Re: [PATCH 2/2] rebase -i: use some kind of config file to save author information

[Christian Couder]

On Monday 22 June 2009, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > On Sat, 20 Jun 2009, Christian Couder wrote:
> >> This is better than saving in a shell script, because it will make
> >> it much easier to port "rebase -i" to C. This also removes some sed
> >> regexps and some "eval"s.
> >
> > It will not make it easier to port "rebase -i" to C, as this is an
> > internal file.  The user is not supposed to touch it at all.  Only
> > "rebase -i".  So it would be very easy to just use a different on-disk
> > format when turning "rebase -i" into a builtin.

I'd rather port "rebase -i" to C step by step like I started 
porting "bisect". So changing the format to something easier to deal with 
in C makes it easier to port.

> "This is an internal file" is just a declaration you are making, and the
> file is observable by anybody after "rebase -i" relinquishes the control
> to let the user sort out the mess.  The users do not have any obligation
> to honor your declaration, and strictly speaking it is a regression to
> change the file format.
>
> For example, when I realize I misspelt somebody's name (perhaps the
> mailpath between the sender and me mishandled the encoding headers), I
> could edit .git/rebase-merge/author-script and say "git rebase
> --continue" to let auto-amend to kick in, which would use the fixed
> author name from the file.
>
> 	Side note.  The current "rebase --continue" behaviour is somewhat
> 	inconsistent; if "edit" does not do anything to the tree, nor the
> 	user runs "git commit --amend', the commit is untouched, but if
> 	the user updates the index and says --continue without amending,
> 	the authorship is not taken from the auto-amended commit but is
> 	taken from the author-script file.  Perhaps something along the
> 	line of untested patch attached at the end would remedy this a
> 	bit?

Interesting. I will try it.

> Having said that, if we were to change the way rebase-i leaves its state
> behind so that it can pick up from where it left off, I prefer
> Christian's later suggestion to leave the object name of the commit that
> is being rebased in the file.  Sure, it makes it harder to lie about the
> authorship, but my previous example was purely "I _could_ do this" and
> not "I rely on being able to do this".

I just sent a v3 where the commit sha1 is saved in the file, so you can 
choose between v2 and v3 what behavior you prefer.

> But I have this nagging feeling that we may be able to get rid of even
> the "current commit".

I will have a look at that.

Thanks,
Christian.

Re: [PATCH 2/2] rebase -i: use some kind of config file to save author information

[Johannes Schindelin]

Hi,

On Sun, 21 Jun 2009, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > On Sat, 20 Jun 2009, Christian Couder wrote:
> >
> >> This is better than saving in a shell script, because it will make
> >> it much easier to port "rebase -i" to C. This also removes some sed
> >> regexps and some "eval"s.
> >
> > It will not make it easier to port "rebase -i" to C, as this is an 
> > internal file.  The user is not supposed to touch it at all.  Only "rebase 
> > -i".  So it would be very easy to just use a different on-disk format when 
> > turning "rebase -i" into a builtin.
> 
> "This is an internal file" is just a declaration you are making, and the
> file is observable by anybody after "rebase -i" relinquishes the control
> to let the user sort out the mess.

It is an observation I am making.  Sure, the file is observable by the 
user.  But it is hidden deep inside .git/ and users who change things 
inside .git/ (with the exception of config) are asking for trouble.

I really do not see the point of changing the file format _before_ turning 
rebase -i into C.

Oh, and I do not see the point of turning rebase -i into C before finally 
polishing sequencer so it can go into git.git's master.

Ciao,
Dscho

Re: [PATCH 2/2] rebase -i: use some kind of config file to save author information

[Christian Couder]

On Monday 22 June 2009, Junio C Hamano wrote:
>
> rebase -i: AUTHOR_{NAME,EMAIL,DATE} are already available in HEAD; use
> it.
>
> This only changes the codepath of "rebase -i --continue" that auto-amends
> the HEAD commit with the change user made but forgot to "commit --amend".
>
>  git-rebase--interactive.sh |    3 +--
>  1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> index f96d887..b8608be 100755
> --- a/git-rebase--interactive.sh
> +++ b/git-rebase--interactive.sh
> @@ -522,8 +522,7 @@ first and then run 'git rebase --continue' again."
>  				git reset --soft HEAD^ ||
>  				die "Cannot rewind the HEAD"
>  			fi
> -			export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE &&
> -			git commit --no-verify -F "$DOTEST"/message -e || {
> +			git commit --no-verify -c HEAD || {
>  				test -n "$amend" && git reset --soft $amend
>  				die "Could not commit staged changes."
>  			}

This patch would use the message from HEAD instead of "$DOTEST"/message, but 
it looks like we are changing "$DOTEST"/message sometimes with 
the "make_squash_message" function.

Best regards,
Christian.

Re: [PATCH 2/2] rebase -i: use some kind of config file to save author information

[Junio C Hamano]

Christian Couder <chriscool@tuxfamily.org> writes:

> This patch would use the message from HEAD instead of "$DOTEST"/message, but 
> it looks like we are changing "$DOTEST"/message sometimes with 
> the "make_squash_message" function.

Heh, that is why it was "something along this line" patch ;-)

Regarding the C rewrite vs rebase--i.sh update, I tend to agree with Dscho
that changing the scripted Porcelain is not worth it if we are rewriting
the whole thing in C soon.  But perhaps we can allow combinations of the
two options ("-[cC] commit" and "-F file") given to "git commit"?  The
intent of the caller in such a case is quite clear---use the authorship
but do use the message from the other source (if we do this, it would
probably make sense to do that also for "-m message").  The version
entirely written in C obviously does not even need such an option (it can
read authorship from HEAD and use its own message), but the point is if
going that route would eliminate the need to store "which commit were we
dealing with when we gave the control back" information on disk.  I
suspect that the sequencing information is already on disk (i.e. $TODO
file) and author-script may be redundant information.

Re: [PATCH 2/2] rebase -i: use some kind of config file to save author information

[Christian Couder]

On Monday 22 June 2009, Johannes Schindelin wrote:
> Hi,
>
> On Sun, 21 Jun 2009, Junio C Hamano wrote:
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > > On Sat, 20 Jun 2009, Christian Couder wrote:
> > >> This is better than saving in a shell script, because it will make
> > >> it much easier to port "rebase -i" to C. This also removes some sed
> > >> regexps and some "eval"s.
> > >
> > > It will not make it easier to port "rebase -i" to C, as this is an
> > > internal file.  The user is not supposed to touch it at all.  Only
> > > "rebase -i".  So it would be very easy to just use a different
> > > on-disk format when turning "rebase -i" into a builtin.
> >
> > "This is an internal file" is just a declaration you are making, and
> > the file is observable by anybody after "rebase -i" relinquishes the
> > control to let the user sort out the mess.
>
> It is an observation I am making.  Sure, the file is observable by the
> user.  But it is hidden deep inside .git/ and users who change things
> inside .git/ (with the exception of config) are asking for trouble.
>
> I really do not see the point of changing the file format _before_
> turning rebase -i into C.
>
> Oh, and I do not see the point of turning rebase -i into C before finally
> polishing sequencer so it can go into git.git's master.

The problem with this is that it will take a lot of time to implement the 
features that have been added to rebase -i since the sequencer stalled, 
then to polish it, and to get it reviewed and so on, and during that time 
other features or changes may be implemented by other people.

So I prefer to use code from the current sequencer (at 
http://repo.or.cz/w/git/sbeyer.git) to start porting step by step rebase -i 
to C.

Regards,
Christian.

Re: [PATCH 2/2] rebase -i: use some kind of config file to save author information

[Johannes Schindelin]

Hi,

On Tue, 23 Jun 2009, Christian Couder wrote:

> On Monday 22 June 2009, Johannes Schindelin wrote:
>
> > On Sun, 21 Jun 2009, Junio C Hamano wrote:
> > > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > > > On Sat, 20 Jun 2009, Christian Couder wrote:
> > > >> This is better than saving in a shell script, because it will 
> > > >> make it much easier to port "rebase -i" to C. This also removes 
> > > >> some sed regexps and some "eval"s.
> > > >
> > > > It will not make it easier to port "rebase -i" to C, as this is an 
> > > > internal file.  The user is not supposed to touch it at all.  
> > > > Only "rebase -i".  So it would be very easy to just use a 
> > > > different on-disk format when turning "rebase -i" into a builtin.
> > >
> > > "This is an internal file" is just a declaration you are making, and 
> > > the file is observable by anybody after "rebase -i" relinquishes the 
> > > control to let the user sort out the mess.
> >
> > It is an observation I am making.  Sure, the file is observable by the 
> > user.  But it is hidden deep inside .git/ and users who change things 
> > inside .git/ (with the exception of config) are asking for trouble.
> >
> > I really do not see the point of changing the file format _before_ 
> > turning rebase -i into C.
> >
> > Oh, and I do not see the point of turning rebase -i into C before 
> > finally polishing sequencer so it can go into git.git's master.
> 
> The problem with this is that it will take a lot of time to implement 
> the features that have been added to rebase -i since the sequencer 
> stalled, then to polish it, and to get it reviewed and so on, and during 
> that time other features or changes may be implemented by other people.
> 
> So I prefer to use code from the current sequencer (at 
> http://repo.or.cz/w/git/sbeyer.git) to start porting step by step rebase 
> -i to C.

I think that the best way to go forward would be to have something like 
fetch--tool, i.e. a builtin helper that successively takes more and more 
functionality into C.

IMHO a first sensible step would be to implement the commands ("pick", 
"squash", "edit") in such a helper, and call them from do_next().

That should take care of the most difficult part, getting the transition 
started.

But I had the impression that the sequencer started out almost like this, 
but then it also wanted to implement the do_next() and everything.

Ciao,
Dscho

Re: [PATCH 2/2] rebase -i: use some kind of config file to save author information

[Christian Couder]

On Tuesday 23 June 2009, Junio C Hamano wrote:
> Christian Couder <chriscool@tuxfamily.org> writes:
> > This patch would use the message from HEAD instead of
> > "$DOTEST"/message, but it looks like we are changing "$DOTEST"/message
> > sometimes with the "make_squash_message" function.
>
> Heh, that is why it was "something along this line" patch ;-)
>
> Regarding the C rewrite vs rebase--i.sh update, I tend to agree with
> Dscho that changing the scripted Porcelain is not worth it if we are
> rewriting the whole thing in C soon.  But perhaps we can allow
> combinations of the two options ("-[cC] commit" and "-F file") given to
> "git commit"?

I agree that it would be nice.

> The intent of the caller in such a case is quite 
> clear---use the authorship but do use the message from the other source
> (if we do this, it would probably make sense to do that also for "-m
> message").  The version entirely written in C obviously does not even
> need such an option (it can read authorship from HEAD and use its own
> message), but the point is if going that route would eliminate the need
> to store "which commit were we dealing with when we gave the control
> back" information on disk.  I suspect that the sequencing information is
> already on disk (i.e. $TODO file) and author-script may be redundant
> information.

Yeah, perhaps we could ge this route, but I'd rather just port what I can 
step by step first and then polish and/or rewrite some parts than the other 
way around.

Thanks,
Christian.

Re: [PATCH 2/2] rebase -i: use some kind of config file to save author information

[Christian Couder]

Hi,

On Tuesday 23 June 2009, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 23 Jun 2009, Christian Couder wrote:
> > The problem with this is that it will take a lot of time to implement
> > the features that have been added to rebase -i since the sequencer
> > stalled, then to polish it, and to get it reviewed and so on, and
> > during that time other features or changes may be implemented by other
> > people.
> >
> > So I prefer to use code from the current sequencer (at
> > http://repo.or.cz/w/git/sbeyer.git) to start porting step by step
> > rebase -i to C.
>
> I think that the best way to go forward would be to have something like
> fetch--tool, i.e. a builtin helper that successively takes more and more
> functionality into C.

Yeah, I started working on something like that.

> IMHO a first sensible step would be to implement the commands ("pick",
> "squash", "edit") in such a helper, and call them from do_next().
>
> That should take care of the most difficult part, getting the transition
> started.

I agree that it looks like a good way forward.

> But I had the impression that the sequencer started out almost like this,
> but then it also wanted to implement the do_next() and everything.

Yeah, I think at some steps we got something close to that.

Thanks,
Christian.