threads / patch / 19869

patch, 2 partsrebase -i: use some kind of config file to save author information

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

## tl;dr

13 messages between Jun 20, 2009 and Jun 24, 2009. Diffs are folded; open one to read it.

replies: 12people: 4as markdown or json

Christian Couder· Jun 20, 2009, 02:34 UTC · lore

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(-)
Show changes to git-rebase--interactive.sh +41 −37
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
Jakub Narebski· Jun 20, 2009, 09:27 UTC · re: Christian Couder · lore

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

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.

Show 24 quoted lines
> 
> 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
Christian Couder· Jun 21, 2009, 05:15 UTC · re: Jakub Narebski · lore

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

On Saturday 20 June 2009, Jakub Narebski wrote:
Show 6 quoted lines
> 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.
Show 6 quoted lines
> > 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.
Show 10 quoted lines
> > +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.

Johannes Schindelin· Jun 21, 2009, 21:55 UTC · re: Christian Couder · lore

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

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

Junio C Hamano· Jun 21, 2009, 23:15 UTC · re: Johannes Schindelin · lore

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

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 10 quoted lines
> 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(-)
Show changes to git-rebase--interactive.sh +1 −2
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."
 			}
Christian Couder· Jun 22, 2009, 04:50 UTC · re: Junio C Hamano · lore

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

On Monday 22 June 2009, Junio C Hamano wrote:
Show 10 quoted lines
> 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.

Show 20 quoted lines
> "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.
Show 6 quoted lines
> 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.

Johannes Schindelin· Jun 22, 2009, 09:19 UTC · re: Junio C Hamano · lore

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

Hi,
On Sun, 21 Jun 2009, Junio C Hamano wrote:
Show 16 quoted lines
> 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

Christian Couder· Jun 23, 2009, 05:30 UTC · re: Johannes Schindelin · lore

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

On Monday 22 June 2009, Johannes Schindelin wrote:
Show 27 quoted lines
> 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.

Johannes Schindelin· Jun 23, 2009, 09:40 UTC · re: Christian Couder · lore

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

Hi,
On Tue, 23 Jun 2009, Christian Couder wrote:
Show 36 quoted lines
> 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

Christian Couder· Jun 24, 2009, 04:36 UTC · re: Johannes Schindelin · lore

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

Hi,
On Tuesday 23 June 2009, Johannes Schindelin wrote:
Show 16 quoted lines
> 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.
Show 5 quoted lines
> 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.

Christian Couder· Jun 23, 2009, 04:57 UTC · re: Junio C Hamano · lore

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

On Monday 22 June 2009, Junio C Hamano wrote:
Show 24 quoted lines
>
> 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.

Junio C Hamano· Jun 23, 2009, 05:25 UTC · re: Christian Couder · lore

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

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.

Christian Couder· Jun 24, 2009, 04:29 UTC · re: Junio C Hamano · lore

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

On Tuesday 23 June 2009, Junio C Hamano wrote:
Show 12 quoted lines
> 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.
Show 10 quoted lines
> 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.

← back to recent threads