* Re: [PATCH] rebase -i: commit when continuing after "edit"
From: Johannes Sixt @ 2007-09-25 15:54 UTC (permalink / raw)
To: David Kastrup; +Cc: git, Johannes Schindelin
In-Reply-To: <86ve9y6bvm.fsf@lola.quinscape.zz>
David Kastrup schrieb:
> Johannes Sixt <j.sixt@viscovery.net> writes:
>> I poked around a bit, but one major obstacle is that the assignments
>> in $author_script are on separate lines, which you would have to
>> splice into a single line before you can insert them in the eval.
>
> Hm? Why? Newlines separate assignments just as reliable as spaces
> do. They are primarily special to the tty as line separators, not the
> shell as such.
The task here is to have the assignments on the same line as the command at
the end so that they are locally exported. Here we are inside an 'eval', and
the new-lines *do* what their name suggest: make new lines.
-- Hannes
^ permalink raw reply
* [PATCH 5/5] rebase -i: avoid exporting GIT_AUTHOR_* variables
From: Johannes Schindelin @ 2007-09-25 15:43 UTC (permalink / raw)
To: git, gitster
In-Reply-To: <Pine.LNX.4.64.0709251640360.28395@racer.site>
It is somewhat unsafe to export the GIT_AUTHOR_* variables, since a later
call to git-commit or git-merge could pick them up inadvertently.
So avoid the export, using a recipe provided by Johannes Sixt.
Incidentally, this fixes authorship of merges with "rebase --preserve -i".
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
git-rebase--interactive.sh | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 445a299..e3e89dd 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -174,7 +174,11 @@ pick_one_preserving_merges () {
eval "$author_script"
msg="$(git cat-file commit $sha1 | sed -e '1,/^$/d')"
# NEEDSWORK: give rerere a chance
- if ! output git merge $STRATEGY -m "$msg" $new_parents
+ if ! GIT_AUTHOR_NAME="$GIT_AUTHOR_NAME" \
+ GIT_AUTHOR_EMAIL="$GIT_AUTHOR_EMAIL" \
+ GIT_AUTHOR_DATE="$GIT_AUTHOR_DATE" \
+ output git merge $STRATEGY -m "$msg" \
+ $new_parents
then
printf "%s\n" "$msg" > "$GIT_DIR"/MERGE_MSG
die Error redoing merge $sha1
@@ -281,7 +285,9 @@ do_next () {
f)
# This is like --amend, but with a different message
eval "$author_script"
- export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE
+ GIT_AUTHOR_NAME="$GIT_AUTHOR_NAME" \
+ GIT_AUTHOR_EMAIL="$GIT_AUTHOR_EMAIL" \
+ GIT_AUTHOR_DATE="$GIT_AUTHOR_DATE" \
$USE_OUTPUT git commit -F "$MSG" $EDIT_COMMIT
;;
t)
--
1.5.3.2.1057.gf4dc1
^ permalink raw reply related
* [PATCH 4/5] rebase -i: work on a detached HEAD
From: Johannes Schindelin @ 2007-09-25 15:43 UTC (permalink / raw)
To: git, gitster
In-Reply-To: <Pine.LNX.4.64.0709251640360.28395@racer.site>
Earlier, rebase -i refused to rebase a detached HEAD. Now it no longer
does.
Incidentally, this fixes "git gc --auto" shadowing the true exit status.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
git-rebase--interactive.sh | 23 +++++++++++++++--------
t/t3404-rebase-interactive.sh | 8 ++++++++
2 files changed, 23 insertions(+), 8 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 4f46a15..445a299 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -312,17 +312,20 @@ do_next () {
else
NEWHEAD=$(git rev-parse HEAD)
fi &&
- message="$GIT_REFLOG_ACTION: $HEADNAME onto $SHORTONTO)" &&
- git update-ref -m "$message" $HEADNAME $NEWHEAD $OLDHEAD &&
- git symbolic-ref HEAD $HEADNAME && {
+ case $HEADNAME in
+ refs/*)
+ message="$GIT_REFLOG_ACTION: $HEADNAME onto $SHORTONTO)" &&
+ git update-ref -m "$message" $HEADNAME $NEWHEAD $OLDHEAD &&
+ git symbolic-ref HEAD $HEADNAME
+ ;;
+ esac && {
test ! -f "$DOTEST"/verbose ||
git diff --stat $(cat "$DOTEST"/head)..HEAD
} &&
rm -rf "$DOTEST" &&
+ git gc --auto &&
warn "Successfully rebased and updated $HEADNAME."
- git gc --auto
-
exit
}
@@ -362,7 +365,11 @@ do
HEADNAME=$(cat "$DOTEST"/head-name)
HEAD=$(cat "$DOTEST"/head)
- git symbolic-ref HEAD $HEADNAME &&
+ case $HEADNAME in
+ refs/*)
+ git symbolic-ref HEAD $HEADNAME
+ ;;
+ esac &&
output git reset --hard $HEAD &&
rm -rf "$DOTEST"
exit
@@ -439,8 +446,8 @@ do
test -z "$ONTO" && ONTO=$UPSTREAM
: > "$DOTEST"/interactive || die "Could not mark as interactive"
- git symbolic-ref HEAD > "$DOTEST"/head-name ||
- die "Could not get HEAD"
+ git symbolic-ref HEAD > "$DOTEST"/head-name 2> /dev/null ||
+ echo "detached HEAD" > "$DOTEST"/head-name
echo $HEAD > "$DOTEST"/head
echo $UPSTREAM > "$DOTEST"/upstream
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index 1af73a4..f2214dd 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -309,4 +309,12 @@ test_expect_success '--continue tries to commit, even for "edit"' '
test $parent = $(git rev-parse HEAD^)
'
+test_expect_success 'rebase a detached HEAD' '
+ grandparent=$(git rev-parse HEAD~2) &&
+ git checkout $(git rev-parse HEAD) &&
+ test_tick &&
+ FAKE_LINES="2 1" git rebase -i HEAD~2 &&
+ test $grandparent = $(git rev-parse HEAD~2)
+'
+
test_done
--
1.5.3.2.1057.gf4dc1
^ permalink raw reply related
* [PATCH 3/5] rebase -i: Fix numbers in progress report
From: Johannes Schindelin @ 2007-09-25 15:43 UTC (permalink / raw)
To: git, gitster
In-Reply-To: <Pine.LNX.4.64.0709251640360.28395@racer.site>
Instead of counting all lines in done and todo, we now count the actions
before outputting "$Rebasing ($count/$total)".
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
git-rebase--interactive.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index c850411..4f46a15 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -72,8 +72,8 @@ mark_action_done () {
sed -e 1q < "$TODO" >> "$DONE"
sed -e 1d < "$TODO" >> "$TODO".new
mv -f "$TODO".new "$TODO"
- count=$(($(wc -l < "$DONE")))
- total=$(($count+$(wc -l < "$TODO")))
+ count=$(($(grep -ve '^$' -e '^#' < "$DONE" | wc -l)))
+ total=$(($count+$(grep -ve '^$' -e '^#' < "$TODO" | wc -l)))
printf "Rebasing (%d/%d)\r" $count $total
test -z "$VERBOSE" || echo
}
--
1.5.3.2.1057.gf4dc1
^ permalink raw reply related
* [PATCH 2/5] rebase -i: style fixes and minor cleanups
From: Johannes Schindelin @ 2007-09-25 15:42 UTC (permalink / raw)
To: git, gitster
In-Reply-To: <Pine.LNX.4.64.0709251640360.28395@racer.site>
This patch indents ";;" consistently with the rest of git's shell scripts,
and makes sure that ";;" are before each "esac".
It introduces a helper function "has_action", to make it easier to read
the intentions of the code.
Errors from "git rev-parse --verify" are no longer ignored.
Spaces are quoted using single quotes instead of a backslash, for
readability.
A "test $preserve=f" (missing spaces) was fixed; hashes are no longer
written to "$DOTEST"/rewritten/ unnecessarily.
We used to quote the message for a squash, only to have "echo" unquote it.
Now we use "printf" and do not need to quote to start with.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
git-rebase--interactive.sh | 48 +++++++++++++++++++++++++++----------------
1 files changed, 30 insertions(+), 18 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 58f6f28..c850411 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -41,9 +41,10 @@ output () {
test $status != 0 &&
cat "$DOTEST"/output
return $status
- ;;
+ ;;
*)
"$@"
+ ;;
esac
}
@@ -63,6 +64,7 @@ comment_for_reflog () {
''|rebase*)
GIT_REFLOG_ACTION="rebase -i ($1)"
export GIT_REFLOG_ACTION
+ ;;
esac
}
@@ -96,13 +98,18 @@ die_abort () {
die "$1"
}
+has_action () {
+ grep -vqe '^$' -e '^#' "$1"
+}
+
pick_one () {
no_ff=
case "$1" in -n) sha1=$2; no_ff=t ;; *) sha1=$1 ;; esac
output git rev-parse --verify $sha1 || die "Invalid commit name: $sha1"
test -d "$REWRITTEN" &&
pick_one_preserving_merges "$@" && return
- parent_sha1=$(git rev-parse --verify $sha1^ 2>/dev/null)
+ parent_sha1=$(git rev-parse --verify $sha1^) ||
+ die "Could not get the parent of $sha1"
current_sha1=$(git rev-parse --verify HEAD)
if test $no_ff$current_sha1 = $parent_sha1; then
output git reset --hard $sha1
@@ -130,7 +137,7 @@ pick_one_preserving_merges () {
fast_forward=t
preserve=t
new_parents=
- for p in $(git rev-list --parents -1 $sha1 | cut -d\ -f2-)
+ for p in $(git rev-list --parents -1 $sha1 | cut -d' ' -f2-)
do
if test -f "$REWRITTEN"/$p
then
@@ -142,41 +149,43 @@ pick_one_preserving_merges () {
;; # do nothing; that parent is already there
*)
new_parents="$new_parents $new_p"
+ ;;
esac
fi
done
case $fast_forward in
t)
output warn "Fast forward to $sha1"
- test $preserve=f && echo $sha1 > "$REWRITTEN"/$sha1
+ test $preserve = f || echo $sha1 > "$REWRITTEN"/$sha1
;;
f)
test "a$1" = a-n && die "Refusing to squash a merge: $sha1"
- first_parent=$(expr "$new_parents" : " \([^ ]*\)")
+ first_parent=$(expr "$new_parents" : ' \([^ ]*\)')
# detach HEAD to current parent
output git checkout $first_parent 2> /dev/null ||
die "Cannot move HEAD to $first_parent"
echo $sha1 > "$DOTEST"/current-commit
case "$new_parents" in
- \ *\ *)
+ ' '*' '*)
# redo merge
author_script=$(get_author_ident_from_commit $sha1)
eval "$author_script"
- msg="$(git cat-file commit $sha1 | \
- sed -e '1,/^$/d' -e "s/[\"\\]/\\\\&/g")"
+ msg="$(git cat-file commit $sha1 | sed -e '1,/^$/d')"
# NEEDSWORK: give rerere a chance
if ! output git merge $STRATEGY -m "$msg" $new_parents
then
- echo "$msg" > "$GIT_DIR"/MERGE_MSG
+ printf "%s\n" "$msg" > "$GIT_DIR"/MERGE_MSG
die Error redoing merge $sha1
fi
;;
*)
output git cherry-pick $STRATEGY "$@" ||
die_with_patch $sha1 "Could not pick $sha1"
+ ;;
esac
+ ;;
esac
}
@@ -213,12 +222,11 @@ peek_next_command () {
}
do_next () {
- test -f "$DOTEST"/message && rm "$DOTEST"/message
- test -f "$DOTEST"/author-script && rm "$DOTEST"/author-script
- test -f "$DOTEST"/amend && rm "$DOTEST"/amend
+ rm -f "$DOTEST"/message "$DOTEST"/author-script \
+ "$DOTEST"/amend || exit
read command sha1 rest < "$TODO"
case "$command" in
- \#|'')
+ '#'*|'')
mark_action_done
;;
pick)
@@ -246,7 +254,7 @@ do_next () {
squash)
comment_for_reflog squash
- test -z "$(grep -ve '^$' -e '^#' < $DONE)" &&
+ has_action "$DONE" ||
die "Cannot 'squash' without a previous commit"
mark_action_done
@@ -256,11 +264,12 @@ do_next () {
EDIT_COMMIT=
USE_OUTPUT=output
cp "$MSG" "$SQUASH_MSG"
- ;;
+ ;;
*)
EDIT_COMMIT=-e
USE_OUTPUT=
- test -f "$SQUASH_MSG" && rm "$SQUASH_MSG"
+ rm -f "$SQUASH_MSG" || exit
+ ;;
esac
failed=f
@@ -280,11 +289,13 @@ do_next () {
warn
warn "Could not apply $sha1... $rest"
die_with_patch $sha1 ""
+ ;;
esac
;;
*)
warn "Unknown command: $command $sha1 $rest"
die_with_patch $sha1 "Please fix this in the file $TODO."
+ ;;
esac
test -s "$TODO" && return
@@ -475,17 +486,18 @@ EOF
$UPSTREAM...$HEAD | \
sed -n "s/^>/pick /p" >> "$TODO"
- test -z "$(grep -ve '^$' -e '^#' < $TODO)" &&
+ has_action "$TODO" ||
die_abort "Nothing to do"
cp "$TODO" "$TODO".backup
git_editor "$TODO" ||
die "Could not execute editor"
- test -z "$(grep -ve '^$' -e '^#' < $TODO)" &&
+ has_action "$TODO" ||
die_abort "Nothing to do"
output git checkout $ONTO && do_rest
+ ;;
esac
shift
done
--
1.5.3.2.1057.gf4dc1
^ permalink raw reply related
* [PATCH 1/5] rebase -i: commit when continuing after "edit"
From: Johannes Schindelin @ 2007-09-25 15:42 UTC (permalink / raw)
To: git, gitster
In-Reply-To: <Pine.LNX.4.64.0709251640360.28395@racer.site>
When doing an "edit" on a commit, editing and git-adding some files,
"git rebase -i" complained about a missing "author-script". The idea was
that the user would call "git commit --amend" herself.
But we can be nice and do that for the user.
Noticed by Dmitry Potapov.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
git-rebase--interactive.sh | 17 +++++++++++------
t/t3404-rebase-interactive.sh | 14 +++++++++++++-
2 files changed, 24 insertions(+), 7 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index d2983d1..58f6f28 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -77,15 +77,16 @@ mark_action_done () {
}
make_patch () {
- parent_sha1=$(git rev-parse --verify "$1"^ 2> /dev/null)
+ parent_sha1=$(git rev-parse --verify "$1"^) ||
+ die "Cannot get patch for $1^"
git diff "$parent_sha1".."$1" > "$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
}
die_with_patch () {
- test -f "$DOTEST"/message ||
- git cat-file commit $sha1 | sed "1,/^$/d" > "$DOTEST"/message
- test -f "$DOTEST"/author-script ||
- get_author_ident_from_commit $sha1 > "$DOTEST"/author-script
make_patch "$1"
die "$2"
}
@@ -214,6 +215,7 @@ peek_next_command () {
do_next () {
test -f "$DOTEST"/message && rm "$DOTEST"/message
test -f "$DOTEST"/author-script && rm "$DOTEST"/author-script
+ test -f "$DOTEST"/amend && rm "$DOTEST"/amend
read command sha1 rest < "$TODO"
case "$command" in
\#|'')
@@ -233,6 +235,7 @@ do_next () {
pick_one $sha1 ||
die_with_patch $sha1 "Could not apply $sha1... $rest"
make_patch $sha1
+ : > "$DOTEST"/amend
warn
warn "You can amend the commit now, with"
warn
@@ -332,7 +335,9 @@ do
git update-index --refresh &&
git diff-files --quiet &&
! git diff-index --cached --quiet HEAD &&
- . "$DOTEST"/author-script &&
+ . "$DOTEST"/author-script && {
+ test ! -f "$DOTEST"/amend || git reset --soft HEAD^
+ } &&
export GIT_AUTHOR_NAME GIT_AUTHOR_NAME GIT_AUTHOR_DATE &&
git commit -F "$DOTEST"/message -e
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index 718c9c1..1af73a4 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -80,7 +80,7 @@ cat "$1".tmp
action=pick
for line in $FAKE_LINES; do
case $line in
- squash)
+ squash|edit)
action="$line";;
*)
echo sed -n "${line}s/^pick/$action/p"
@@ -297,4 +297,16 @@ test_expect_success 'ignore patch if in upstream' '
test $HEAD = $(git rev-parse HEAD^)
'
+test_expect_success '--continue tries to commit, even for "edit"' '
+ parent=$(git rev-parse HEAD^) &&
+ test_tick &&
+ FAKE_LINES="edit 1" git rebase -i HEAD^ &&
+ echo edited > file7 &&
+ git add file7 &&
+ FAKE_COMMIT_MESSAGE="chouette!" git rebase --continue &&
+ test edited = $(git show HEAD:file7) &&
+ git show HEAD | grep chouette &&
+ test $parent = $(git rev-parse HEAD^)
+'
+
test_done
--
1.5.3.2.1057.gf4dc1
^ permalink raw reply related
* [PATCH 0/5] Two real fixes, two minor fixes, and a style fix
From: Johannes Schindelin @ 2007-09-25 15:42 UTC (permalink / raw)
To: git, gitster
Hi,
this patch series arose out of the comments to the simple fix I sent out
earlier, which has now become the first patch of the series.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] rebase -i: commit when continuing after "edit"
From: Johannes Schindelin @ 2007-09-25 15:16 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Dmitry Potapov, git
In-Reply-To: <46F922E0.80504@viscovery.net>
Hi,
On Tue, 25 Sep 2007, Johannes Sixt wrote:
> Johannes Schindelin schrieb:
>
> > On Tue, 25 Sep 2007, Johannes Sixt wrote:
> >
> > > Johannes Schindelin schrieb:
> > >
> > > > On Tue, 25 Sep 2007, Johannes Sixt wrote:
> > > > > How about:
> > > > >
> > > > > eval "$author_script"
> > > > > GIT_AUTHOR_NAME="$GIT_AUTHOR_NAME" \
> > > > > GIT_AUTHOR_EMAIL="$GIT_AUTHOR_EMAIL" \
> > > > > GIT_AUTHOR_DATE="$GIT_AUTHOR_DATE" \
> > > > > $USE_OUTPUT git commit -F "$MSG" $EDIT_COMMIT
> > > > >
> > > > > and if you dislike that, put the two questionable lines in
> > > > > parenthesis.
> > > >
> > > > That looks ugly. I'd rather have something like
> > > >
> > > > eval "$USE_OUTPUT $author_script git commit -F \"$MSG\" $EDIT_COMMIT"
> > > >
> > > > but I'm not quite certain if that is enough, what with the funny
> > > > characters people put into path names these days ($MSG points to
> > > > "$DOTEST"/message).
> > >
> > > I, too, find it ugly, but I think it's the most readable way to do
> > > it. Your version is certainly underquoted.
> > >
> > > I poked around a bit, but one major obstacle is that the assignments
> > > in $author_script are on separate lines, which you would have to
> > > splice into a single line before you can insert them in the eval.
> >
> > But is your version not underquoted, too? For example, if the author
> > name is, say 'Johannes "Dscho" Schindelin', would your version still
> > get the \" in the name?
>
> No, it's not underquoted; yes, it would still get the \" in the name.
> The shell parses the assignments
>
> GIT_AUTHOR_NAME="$GIT_AUTHOR_NAME"
>
> only once; it does not parse it again after the dq'd string was expanded.
Ah, okay. I'll go with your version then.
Ciao,
Dscho
^ permalink raw reply
* Re: Q: howto rebase
From: Jeff King @ 2007-09-25 15:02 UTC (permalink / raw)
To: lode leroy; +Cc: git
In-Reply-To: <BAY105-F33DC84FACB8B66BFEB9EC8FFB70@phx.gbl>
On Tue, Sep 25, 2007 at 04:46:59PM +0200, lode leroy wrote:
> In "version B" I introduce the "fix c", but in "version D" I realize it
> should have
> been in some other place. (commit D moves the fix to its proper place).
> A-B-C-D-E
>
> Now I want to 'rewrite history'.
> I would like to move commit D after B
> A-B-D'-C'-E
>
> and then fold the commits B and D' into a single commit.
> A-B'-C'-E
>
> I somehow managed to get this done using "rebase -i"
> by exchanging the 2 appropriate lines, and then deleting the second one,
> but I'd like to understand how to do this from the command line...
The essence of git rebase is "move these commits as if they had happened
off of a different base commit." The interactive mode of rebase is
considerably more powerful, in that it allows squashing, deleting, and
arbitrary reordering. To do solve your problem without using "rebase
-i", you could do this:
# make a new branch based on 'B', which is where we want to base our commits
git-checkout -b tmp B
# pick the changes from 'D', but don't commit
git-cherry-pick -n D
# redo 'B' with the new changes
git-commit --amend
now you have a graph like this:
A-B-C-D-E
\
\-B' <-- branch tip
so you need to rebase C-D-E on top of it (and rebase will realize that
'D' has already been applied), with:
git-rebase --onto tmp B master
Converting this to the manpage terminology, "B" is your upstream, and
you want to grab all of the changes from "B" to your "master", but you
want to put them on the newly created B'. Which perhaps is a little
confusing, but that's because git-rebase was designed for a simpler
situation: you and some upstream repo both made commits that the other
doesn't have, and you want to pretend your work is based off of their
most recent version.
You can see that "rebase -i" is a lot more flexible for these sorts of
history re-writing schemes. If you really must do it without user
interaction, I suspect you could use a sed script as your $GIT_EDITOR.
-Peff
^ permalink raw reply
* Re: [PATCH] rebase -i: commit when continuing after "edit"
From: Johannes Sixt @ 2007-09-25 15:01 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Dmitry Potapov, git
In-Reply-To: <Pine.LNX.4.64.0709251528560.28395@racer.site>
Johannes Schindelin schrieb:
> Hi,
>
> On Tue, 25 Sep 2007, Johannes Sixt wrote:
>
>> Johannes Schindelin schrieb:
>>
>>> On Tue, 25 Sep 2007, Johannes Sixt wrote:
>>>> How about:
>>>>
>>>> eval "$author_script"
>>>> GIT_AUTHOR_NAME="$GIT_AUTHOR_NAME" \
>>>> GIT_AUTHOR_EMAIL="$GIT_AUTHOR_EMAIL" \
>>>> GIT_AUTHOR_DATE="$GIT_AUTHOR_DATE" \
>>>> $USE_OUTPUT git commit -F "$MSG" $EDIT_COMMIT
>>>>
>>>> and if you dislike that, put the two questionable lines in parenthesis.
>>> That looks ugly. I'd rather have something like
>>>
>>> eval "$USE_OUTPUT $author_script git commit -F \"$MSG\" $EDIT_COMMIT"
>>>
>>> but I'm not quite certain if that is enough, what with the funny
>>> characters people put into path names these days ($MSG points to
>>> "$DOTEST"/message).
>> I, too, find it ugly, but I think it's the most readable way to do it.
>> Your version is certainly underquoted.
>>
>> I poked around a bit, but one major obstacle is that the assignments in
>> $author_script are on separate lines, which you would have to splice
>> into a single line before you can insert them in the eval.
>
> But is your version not underquoted, too? For example, if the author name
> is, say 'Johannes "Dscho" Schindelin', would your version still get the \"
> in the name?
No, it's not underquoted; yes, it would still get the \" in the name. The
shell parses the assignments
GIT_AUTHOR_NAME="$GIT_AUTHOR_NAME"
only once; it does not parse it again after the dq'd string was expanded.
-- Hannes
^ permalink raw reply
* Re: [PATCH] rebase -i: commit when continuing after "edit"
From: David Kastrup @ 2007-09-25 14:46 UTC (permalink / raw)
To: git
In-Reply-To: <46F91879.6030301@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Johannes Schindelin schrieb:
>> Hi,
>>
>> On Tue, 25 Sep 2007, Johannes Sixt wrote:
>>> How about:
>>>
>>> eval "$author_script"
>>> GIT_AUTHOR_NAME="$GIT_AUTHOR_NAME" \
>>> GIT_AUTHOR_EMAIL="$GIT_AUTHOR_EMAIL" \
>>> GIT_AUTHOR_DATE="$GIT_AUTHOR_DATE" \
>>> $USE_OUTPUT git commit -F "$MSG" $EDIT_COMMIT
>>>
>>> and if you dislike that, put the two questionable lines in parenthesis.
>>
>> That looks ugly. I'd rather have something like
>>
>> eval "$USE_OUTPUT $author_script git commit -F \"$MSG\" $EDIT_COMMIT"
>>
>> but I'm not quite certain if that is enough, what with the funny
>> characters people put into path names these days ($MSG points to
>> "$DOTEST"/message).
>
> I, too, find it ugly, but I think it's the most readable way to do
> it. Your version is certainly underquoted.
Proper quoting in my book would be
eval "$USE_OUTPUT $author_script git commit -F" '"$MSG"' "$EDIT_COMMIT"
(I am not sure I am correct about $EDIT_COMMIT, not having looked at
its definition).
Important is the double quotation of $MSG to keep it as a single argument.
> I poked around a bit, but one major obstacle is that the assignments
> in $author_script are on separate lines, which you would have to
> splice into a single line before you can insert them in the eval.
Hm? Why? Newlines separate assignments just as reliable as spaces
do. They are primarily special to the tty as line separators, not the
shell as such.
--
David Kastrup
^ permalink raw reply
* Re: Q: howto rebase
From: lode leroy @ 2007-09-25 14:54 UTC (permalink / raw)
To: git
In-Reply-To: <b41dbf4a0709250748l52b64155k65b6adb16e8dbcd5@mail.gmail.com>
I'm trying to understand how rebase works, but I need some help to get it.
Suppose I do the following workflow... (see below)
In "version B" I introduce the "fix c", but in "version D" I realize
it should have
been in some other place. (commit D moves the fix to its proper place).
A-B-C-D-E
Now I want to 'rewrite history'.
I would like to move commit D after B
A-B-D'-C'-E
and then fold the commits B and D' into a single commit.
A-B'-C'-E
I somehow managed to get this done using "rebase -i"
by exchanging the 2 appropriate lines, and then deleting the second one,
but I'd like to understand how to do this from the command line...
Could anyone enlighten me? I've read git-rebase(1) several times,
but don't seem to get it right...
cat > file <<EOF
a
b
d
e
g
h
EOF
git add file
git commit -m 'A' -a
cat > file <<EOF
a
b
d
e
g
c
h
EOF
git commit -m 'B' -a
cat > file <<EOF
a
b
d
e
f
g
c
h
EOF
git commit -m 'C' -a
cat > file <<EOF
a
b
c
d
e
f
g
h
EOF
git commit -m 'D' -a
cat > file <<EOF
a
b
c
d
e
f
g
h
i
EOF
git commit -m 'E' -a
^ permalink raw reply
* Re: Q: howto rebase
From: Johannes Schindelin @ 2007-09-25 14:49 UTC (permalink / raw)
To: lode leroy; +Cc: git
In-Reply-To: <BAY105-F33DC84FACB8B66BFEB9EC8FFB70@phx.gbl>
Hi,
On Tue, 25 Sep 2007, lode leroy wrote:
> I'm trying to understand how rebase works, but I need some help to get it.
> Suppose I do the following workflow... (see below)
>
> In "version B" I introduce the "fix c", but in "version D" I realize it
> should have
> been in some other place. (commit D moves the fix to its proper place).
> A-B-C-D-E
>
> Now I want to 'rewrite history'.
> I would like to move commit D after B
> A-B-D'-C'-E
>
> and then fold the commits B and D' into a single commit.
> A-B'-C'-E
>
> I somehow managed to get this done using "rebase -i"
> by exchanging the 2 appropriate lines, and then deleting the second one,
> but I'd like to understand how to do this from the command line...
Almost. Your "fold" is called "squash". So instead of deleting the
second one, you probably wanted to squash it.
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH] Don't use "<unknown>" for unknown values of placeholders and suppress printing of empty user formats.
From: Johannes Schindelin @ 2007-09-25 14:47 UTC (permalink / raw)
To: Michal Vitecek; +Cc: git, Junio C Hamano
In-Reply-To: <20070925143846.GQ22869@mageo.cz>
Hi,
On Tue, 25 Sep 2007, Michal Vitecek wrote:
> ---
>
> Sending the patch again in correct form (hopefully) as instructed by
> Johannes Schindelin. Sorry for the hassle.
Thanks.
> diff --git a/commit.c b/commit.c
> index 99f65ce..c9a1818 100644
> --- a/commit.c
> +++ b/commit.c
> @@ -917,9 +917,6 @@ long format_commit_message(const struct commit *commit, const void *format,
> }
> if (msg[i])
> table[IBODY].value = xstrdup(msg + i);
> - for (i = 0; i < ARRAY_SIZE(table); i++)
> - if (!table[i].value)
> - interp_set_entry(table, i, "<unknown>");
This may have warranted a description in the commit message a la
Instead of setting unknown entries to "<unknown>" in the
interp_table, we teach interpolate() to replace entries with
NULL values by the empty string.
> diff --git a/log-tree.c b/log-tree.c
> index a642371..79502f4 100644
> --- a/log-tree.c
> +++ b/log-tree.c
> @@ -175,14 +175,15 @@ void show_log(struct rev_info *opt, const char *sep)
> * - The pretty-printed commit lacks a newline at the end
> * of the buffer, but we do want to make sure that we
> * have a newline there. If the separator isn't already
> - * a newline, add an extra one.
> + * a newline, add an extra one and do the same for the
> + * user format as well.
Here are still spaces instead of tabs.
These are only minor details; I don't know if Junio wants to fix them
himself.
Ciao,
Dscho
^ permalink raw reply
* Q: howto rebase
From: lode leroy @ 2007-09-25 14:46 UTC (permalink / raw)
To: git
I'm trying to understand how rebase works, but I need some help to get it.
Suppose I do the following workflow... (see below)
In "version B" I introduce the "fix c", but in "version D" I realize it
should have
been in some other place. (commit D moves the fix to its proper place).
A-B-C-D-E
Now I want to 'rewrite history'.
I would like to move commit D after B
A-B-D'-C'-E
and then fold the commits B and D' into a single commit.
A-B'-C'-E
I somehow managed to get this done using "rebase -i"
by exchanging the 2 appropriate lines, and then deleting the second one,
but I'd like to understand how to do this from the command line...
Could anyone enlighten me? I've read git-rebase(1) several times,
but don't seem to get it right...
cat > file <<EOF
a
b
d
e
g
h
EOF
git add file
git commit -m 'A' -a
cat > file <<EOF
a
b
d
e
g
c
h
EOF
git commit -m 'B' -a
cat > file <<EOF
a
b
d
e
f
g
c
h
EOF
git commit -m 'C' -a
cat > file <<EOF
a
b
c
d
e
f
g
h
EOF
git commit -m 'D' -a
cat > file <<EOF
a
b
c
d
e
f
g
h
i
EOF
git commit -m 'E' -a
_________________________________________________________________
A lot of passions? Collect all your personal info on one central location ,
for free! http://get.live.com/live/features
^ permalink raw reply
* [PATCH] Don't use "<unknown>" for unknown values of placeholders and suppress printing of empty user formats.
From: Michal Vitecek @ 2007-09-25 14:38 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin, Junio C Hamano
---
Sending the patch again in correct form (hopefully) as instructed by
Johannes Schindelin. Sorry for the hassle.
builtin-rev-list.c | 3 ++-
commit.c | 3 ---
interpolate.c | 6 +++++-
log-tree.c | 10 ++++++----
t/t6006-rev-list-format.sh | 8 --------
t/t7500-commit.sh | 4 ++--
6 files changed, 15 insertions(+), 19 deletions(-)
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index 3894633..0b74eb3 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -85,7 +85,8 @@ static void show_commit(struct commit *commit)
pretty_print_commit(revs.commit_format, commit, ~0,
&buf, &buflen,
revs.abbrev, NULL, NULL, revs.date_mode);
- printf("%s%c", buf, hdr_termination);
+ if (*buf)
+ printf("%s%c", buf, hdr_termination);
free(buf);
}
maybe_flush_or_die(stdout, "stdout");
diff --git a/commit.c b/commit.c
index 99f65ce..c9a1818 100644
--- a/commit.c
+++ b/commit.c
@@ -917,9 +917,6 @@ long format_commit_message(const struct commit *commit, const void *format,
}
if (msg[i])
table[IBODY].value = xstrdup(msg + i);
- for (i = 0; i < ARRAY_SIZE(table); i++)
- if (!table[i].value)
- interp_set_entry(table, i, "<unknown>");
do {
char *buf = *buf_p;
diff --git a/interpolate.c b/interpolate.c
index 0082677..2f727cd 100644
--- a/interpolate.c
+++ b/interpolate.c
@@ -76,8 +76,12 @@ unsigned long interpolate(char *result, unsigned long reslen,
/* Check for valid interpolation. */
if (i < ninterps) {
value = interps[i].value;
- valuelen = strlen(value);
+ if (!value) {
+ src += namelen;
+ continue;
+ }
+ valuelen = strlen(value);
if (newlen + valuelen + 1 < reslen) {
/* Substitute. */
strncpy(dest, value, valuelen);
diff --git a/log-tree.c b/log-tree.c
index a642371..79502f4 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -175,14 +175,15 @@ void show_log(struct rev_info *opt, const char *sep)
* - The pretty-printed commit lacks a newline at the end
* of the buffer, but we do want to make sure that we
* have a newline there. If the separator isn't already
- * a newline, add an extra one.
+ * a newline, add an extra one and do the same for the
+ * user format as well.
* - unlike other log messages, the one-line format does
* not have an empty line between entries.
*/
extra = "";
- if (*sep != '\n' && opt->commit_format == CMIT_FMT_ONELINE)
+ if (*sep != '\n' && (opt->commit_format == CMIT_FMT_ONELINE || opt->commit_format == CMIT_FMT_USERFORMAT))
extra = "\n";
- if (opt->shown_one && opt->commit_format != CMIT_FMT_ONELINE)
+ if (opt->shown_one && opt->commit_format != CMIT_FMT_ONELINE && opt->commit_format != CMIT_FMT_USERFORMAT)
putchar(opt->diffopt.line_termination);
opt->shown_one = 1;
@@ -298,7 +299,8 @@ void show_log(struct rev_info *opt, const char *sep)
if (opt->show_log_size)
printf("log size %i\n", len);
- printf("%s%s%s", msgbuf, extra, sep);
+ if (*msgbuf)
+ printf("%s%s%s", msgbuf, extra, sep);
free(msgbuf);
}
diff --git a/t/t6006-rev-list-format.sh b/t/t6006-rev-list-format.sh
index ad6d0b8..1e4541a 100755
--- a/t/t6006-rev-list-format.sh
+++ b/t/t6006-rev-list-format.sh
@@ -79,9 +79,7 @@ EOF
test_format encoding %e <<'EOF'
commit 131a310eb913d107dd3c09a65d1651175898735d
-<unknown>
commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
-<unknown>
EOF
test_format subject %s <<'EOF'
@@ -93,9 +91,7 @@ EOF
test_format body %b <<'EOF'
commit 131a310eb913d107dd3c09a65d1651175898735d
-<unknown>
commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
-<unknown>
EOF
test_format colors %Credfoo%Cgreenbar%Cbluebaz%Cresetxyzzy <<'EOF'
@@ -121,9 +117,7 @@ test_format complex-encoding %e <<'EOF'
commit f58db70b055c5718631e5c61528b28b12090cdea
iso8859-1
commit 131a310eb913d107dd3c09a65d1651175898735d
-<unknown>
commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
-<unknown>
EOF
test_format complex-subject %s <<'EOF'
@@ -142,9 +136,7 @@ and it will be encoded in iso8859-1. We should therefore
include an iso8859 character: ÂĄbueno!
commit 131a310eb913d107dd3c09a65d1651175898735d
-<unknown>
commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
-<unknown>
EOF
test_done
diff --git a/t/t7500-commit.sh b/t/t7500-commit.sh
index f11ada8..abbf54b 100755
--- a/t/t7500-commit.sh
+++ b/t/t7500-commit.sh
@@ -81,7 +81,7 @@ test_expect_success 'explicit commit message should override template' '
git add foo &&
GIT_EDITOR=../t7500/add-content git commit --template "$TEMPLATE" \
-m "command line msg" &&
- commit_msg_is "command line msg<unknown>"
+ commit_msg_is "command line msg"
'
test_expect_success 'commit message from file should override template' '
@@ -90,7 +90,7 @@ test_expect_success 'commit message from file should override template' '
echo "standard input msg" |
GIT_EDITOR=../t7500/add-content git commit \
--template "$TEMPLATE" --file - &&
- commit_msg_is "standard input msg<unknown>"
+ commit_msg_is "standard input msg"
'
test_done
--
1.5.3.2
--
fuf (fuf@mageo.cz)
^ permalink raw reply related
* Re: [PATCH] rebase -i: commit when continuing after "edit"
From: Johannes Schindelin @ 2007-09-25 14:31 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Dmitry Potapov, git
In-Reply-To: <46F91879.6030301@viscovery.net>
Hi,
On Tue, 25 Sep 2007, Johannes Sixt wrote:
> Johannes Schindelin schrieb:
>
> > On Tue, 25 Sep 2007, Johannes Sixt wrote:
> > > How about:
> > >
> > > eval "$author_script"
> > > GIT_AUTHOR_NAME="$GIT_AUTHOR_NAME" \
> > > GIT_AUTHOR_EMAIL="$GIT_AUTHOR_EMAIL" \
> > > GIT_AUTHOR_DATE="$GIT_AUTHOR_DATE" \
> > > $USE_OUTPUT git commit -F "$MSG" $EDIT_COMMIT
> > >
> > > and if you dislike that, put the two questionable lines in parenthesis.
> >
> > That looks ugly. I'd rather have something like
> >
> > eval "$USE_OUTPUT $author_script git commit -F \"$MSG\" $EDIT_COMMIT"
> >
> > but I'm not quite certain if that is enough, what with the funny
> > characters people put into path names these days ($MSG points to
> > "$DOTEST"/message).
>
> I, too, find it ugly, but I think it's the most readable way to do it.
> Your version is certainly underquoted.
>
> I poked around a bit, but one major obstacle is that the assignments in
> $author_script are on separate lines, which you would have to splice
> into a single line before you can insert them in the eval.
But is your version not underquoted, too? For example, if the author name
is, say 'Johannes "Dscho" Schindelin', would your version still get the \"
in the name?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] rebase -i: commit when continuing after "edit"
From: Johannes Sixt @ 2007-09-25 14:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Dmitry Potapov, git
In-Reply-To: <Pine.LNX.4.64.0709251439070.28395@racer.site>
Johannes Schindelin schrieb:
> Hi,
>
> On Tue, 25 Sep 2007, Johannes Sixt wrote:
>> How about:
>>
>> eval "$author_script"
>> GIT_AUTHOR_NAME="$GIT_AUTHOR_NAME" \
>> GIT_AUTHOR_EMAIL="$GIT_AUTHOR_EMAIL" \
>> GIT_AUTHOR_DATE="$GIT_AUTHOR_DATE" \
>> $USE_OUTPUT git commit -F "$MSG" $EDIT_COMMIT
>>
>> and if you dislike that, put the two questionable lines in parenthesis.
>
> That looks ugly. I'd rather have something like
>
> eval "$USE_OUTPUT $author_script git commit -F \"$MSG\" $EDIT_COMMIT"
>
> but I'm not quite certain if that is enough, what with the funny
> characters people put into path names these days ($MSG points to
> "$DOTEST"/message).
I, too, find it ugly, but I think it's the most readable way to do it. Your
version is certainly underquoted.
I poked around a bit, but one major obstacle is that the assignments in
$author_script are on separate lines, which you would have to splice into a
single line before you can insert them in the eval.
-- Hannes
^ permalink raw reply
* Re: [PATCH] Move convert-objects to contrib.
From: Johannes Schindelin @ 2007-09-25 14:06 UTC (permalink / raw)
To: Matt Kraai; +Cc: git
In-Reply-To: <20070925140425.GA6061@ftbfs.org>
Hi,
On Tue, 25 Sep 2007, Matt Kraai wrote:
> On Tue, Sep 25, 2007 at 11:01:58AM +0100, Johannes Schindelin wrote:
> > the commit message looks a little bit empty to me. I'd at least
> > mention why convert-objects was needed, why it is no longer needed,
> > and that Linus, the original author, is okay with it.
> >
> > And you might want to use the "-M" flag to format-patch next time
> > (detect renames).
>
> OK, thanks. I've resubmitted the patch, (hopefully) taking both
> suggestions into account.
Yep, thanks, a pleasure to the eye.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Move convert-objects to contrib.
From: Matt Kraai @ 2007-09-25 14:04 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0709251100560.28395@racer.site>
On Tue, Sep 25, 2007 at 11:01:58AM +0100, Johannes Schindelin wrote:
> the commit message looks a little bit empty to me. I'd at least mention
> why convert-objects was needed, why it is no longer needed, and that
> Linus, the original author, is okay with it.
>
> And you might want to use the "-M" flag to format-patch next time (detect
> renames).
OK, thanks. I've resubmitted the patch, (hopefully) taking both
suggestions into account.
--
Matt
^ permalink raw reply
* [PATCH] Move convert-objects to contrib.
From: Matt Kraai @ 2007-09-25 14:03 UTC (permalink / raw)
To: git; +Cc: Matt Kraai
convert-objects was needed to convert from an old-style repository,
which hashed the compressed contents and used a different date format.
Such repositories are presumably no longer common and, if such
conversions are necessary, should be done by writing a frontend for
git-fast-import.
Linus, the original author, is OK with moving it to contrib.
Signed-off-by: Matt Kraai <kraai@ftbfs.org>
---
I've expanded the commit message and used -M to detect renamed
files, based on feedback from Johannes Schindelin.
.gitignore | 1 -
Documentation/cmd-list.perl | 1 -
Makefile | 2 +-
contrib/completion/git-completion.bash | 1 -
.../convert-objects/convert-objects.c | 0
.../convert-objects}/git-convert-objects.txt | 0
6 files changed, 1 insertions(+), 4 deletions(-)
rename convert-objects.c => contrib/convert-objects/convert-objects.c (100%)
rename {Documentation => contrib/convert-objects}/git-convert-objects.txt (100%)
diff --git a/.gitignore b/.gitignore
index 63c918c..e0b91be 100644
--- a/.gitignore
+++ b/.gitignore
@@ -25,7 +25,6 @@ git-clone
git-commit
git-commit-tree
git-config
-git-convert-objects
git-count-objects
git-cvsexportcommit
git-cvsimport
diff --git a/Documentation/cmd-list.perl b/Documentation/cmd-list.perl
index 4ee76ea..1061fd8 100755
--- a/Documentation/cmd-list.perl
+++ b/Documentation/cmd-list.perl
@@ -94,7 +94,6 @@ git-clone mainporcelain
git-commit mainporcelain
git-commit-tree plumbingmanipulators
git-config ancillarymanipulators
-git-convert-objects ancillarymanipulators
git-count-objects ancillaryinterrogators
git-cvsexportcommit foreignscminterface
git-cvsimport foreignscminterface
diff --git a/Makefile b/Makefile
index 0055eef..94b16d0 100644
--- a/Makefile
+++ b/Makefile
@@ -233,7 +233,7 @@ SCRIPTS = $(patsubst %.sh,%,$(SCRIPT_SH)) \
# ... and all the rest that could be moved out of bindir to gitexecdir
PROGRAMS = \
- git-convert-objects$X git-fetch-pack$X \
+ git-fetch-pack$X \
git-hash-object$X git-index-pack$X git-local-fetch$X \
git-fast-import$X \
git-daemon$X \
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index cad842a..e760930 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -299,7 +299,6 @@ __git_commands ()
check-attr) : plumbing;;
check-ref-format) : plumbing;;
commit-tree) : plumbing;;
- convert-objects) : plumbing;;
cvsexportcommit) : export;;
cvsimport) : import;;
cvsserver) : daemon;;
diff --git a/convert-objects.c b/contrib/convert-objects/convert-objects.c
similarity index 100%
rename from convert-objects.c
rename to contrib/convert-objects/convert-objects.c
diff --git a/Documentation/git-convert-objects.txt b/contrib/convert-objects/git-convert-objects.txt
similarity index 100%
rename from Documentation/git-convert-objects.txt
rename to contrib/convert-objects/git-convert-objects.txt
--
1.5.3.2
^ permalink raw reply related
* [PATCH 1/2] gitattributes.txt: Remove a duplicated paragraph about 'ident' and 'crlf' interaction.
From: Johannes Sixt @ 2007-09-25 13:05 UTC (permalink / raw)
To: gitster; +Cc: git, Johannes Sixt
The order in which 'ident' and 'crlf' are carried out is documented a few paragraphs
later again, after 'filter' was introduced.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
I don't have the tools to check whether the formatting is still correct.
-- Hannes
Documentation/gitattributes.txt | 11 -----------
1 files changed, 0 insertions(+), 11 deletions(-)
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index d0e951e..168a598 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -145,17 +145,6 @@ sign `$` upon checkout. Any byte sequence that begins with
with `$Id$` upon check-in.
-Interaction between checkin/checkout attributes
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-In the check-in codepath, the worktree file is first converted
-with `ident` (if specified), and then with `crlf` (again, if
-specified and applicable).
-
-In the check-out codepath, the blob content is first converted
-with `crlf`, and then `ident`.
-
-
`filter`
^^^^^^^^
--
1.5.3.3.gcc9e
^ permalink raw reply related
* Re: [PATCH] rebase -i: commit when continuing after "edit"
From: Johannes Schindelin @ 2007-09-25 13:50 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Dmitry Potapov, git
In-Reply-To: <46F90C95.5060903@viscovery.net>
Hi,
On Tue, 25 Sep 2007, Johannes Sixt wrote:
> Johannes Schindelin schrieb:
> > On Mon, 24 Sep 2007, Junio C Hamano wrote:
> > > > do_next () {
> > > > test -f "$DOTEST"/message && rm "$DOTEST"/message
> > > > test -f "$DOTEST"/author-script && rm "$DOTEST"/author-script
> > > > + test -f "$DOTEST"/amend && rm "$DOTEST"/amend
> > > As you do not check the error from "rm", how are these different from rm
> > > -f "$DOTEST/frotz"?
> >
> > The difference: the user will not see many irritating error messages.
> >
> > I changed this code to use a newly written function "remove_if_exists",
> > which die()s if the file exists and could not be removed.
>
> Why? rm -f does nothing if the file does not exist, and fails if it cannot
> remove an existing file. It all boils down to:
>
> rm -f "$DOTEST"/message "$DOTEST"/author-script \
> "$DOTEST"/amend || exit
You're completely right. I somehow assumed that it would print an
annoying message, but I was wrong.
BTW I am continually amazed at the ease of rebase -i to fix issues like
these in a patch series. Thanks Eric!
> > > > # This is like --amend, but with a different message
> > > > eval "$author_script"
> > > > export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL
> > > > GIT_AUTHOR_DATE
> > > > $USE_OUTPUT git commit -F "$MSG" $EDIT_COMMIT
> > > > ;;
> > > The "export" here makes me somewhat nervous -- no chance these
> > > leak into the next round?
> >
> > I am somewhat wary: I get quoting wrong all the time. Would
> >
> > $USE_OUTPUT $author_script git commit -F "$MSG" $EDIT_COMMIT
> >
> > work? I have the slight suspicion that it would not, since
> >
> > eval "$author_script"
> >
> > needs extra quoting in $author_script, no?
>
> How about:
>
> eval "$author_script"
> GIT_AUTHOR_NAME="$GIT_AUTHOR_NAME" \
> GIT_AUTHOR_EMAIL="$GIT_AUTHOR_EMAIL" \
> GIT_AUTHOR_DATE="$GIT_AUTHOR_DATE" \
> $USE_OUTPUT git commit -F "$MSG" $EDIT_COMMIT
>
> and if you dislike that, put the two questionable lines in parenthesis.
That looks ugly. I'd rather have something like
eval "$USE_OUTPUT $author_script git commit -F \"$MSG\" $EDIT_COMMIT"
but I'm not quite certain if that is enough, what with the funny
characters people put into path names these days ($MSG points to
"$DOTEST"/message).
BTW I just realised that the _same_ issue should have occurred in the
"squash" case, but there I _forgot_ to export the environment variables.
Ciao,
Dscho
^ permalink raw reply
* [PATCH 2/2] gitattributes.txt: Be more to the point in the filter driver description.
From: Johannes Sixt @ 2007-09-25 13:05 UTC (permalink / raw)
To: gitster; +Cc: git, Johannes Sixt
In-Reply-To: <11907255291239-git-send-email-johannes.sixt@telecom.at>
The description was meant to emphasizes that the project should remain
usable even if the filter driver was not used. This makes it more explicit
and removes the "here is rope to hang yourself" paraphrase.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
Documentation/gitattributes.txt | 9 ++++-----
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index 168a598..20cf8ff 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -164,11 +164,10 @@ but makes the filter a no-op passthru.
The content filtering is done to massage the content into a
shape that is more convenient for the platform, filesystem, and
the user to use. The keyword here is "more convenient" and not
-"turning something unusable into usable". In other words, it is
-"hanging yourself because we gave you a long rope" if your
-project uses filtering mechanism in such a way that it makes
-your project unusable unless the checkout is done with a
-specific filter in effect.
+"turning something unusable into usable". In other words, the
+intent is that if someone unsets the filter driver definition,
+or does not have the appropriate filter program, the project
+should still be usable.
Interaction between checkin/checkout attributes
--
1.5.3.3.gcc9e
^ permalink raw reply related
* Re: [PATCH] rebase -i: commit when continuing after "edit"
From: Johannes Sixt @ 2007-09-25 13:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Dmitry Potapov, git
In-Reply-To: <Pine.LNX.4.64.0709251249450.28395@racer.site>
Johannes Schindelin schrieb:
> On Mon, 24 Sep 2007, Junio C Hamano wrote:
>>> do_next () {
>>> test -f "$DOTEST"/message && rm "$DOTEST"/message
>>> test -f "$DOTEST"/author-script && rm "$DOTEST"/author-script
>>> + test -f "$DOTEST"/amend && rm "$DOTEST"/amend
>> As you do not check the error from "rm", how are these different from rm
>> -f "$DOTEST/frotz"?
>
> The difference: the user will not see many irritating error messages.
>
> I changed this code to use a newly written function "remove_if_exists",
> which die()s if the file exists and could not be removed.
Why? rm -f does nothing if the file does not exist, and fails if it cannot
remove an existing file. It all boils down to:
rm -f "$DOTEST"/message "$DOTEST"/author-script \
"$DOTEST"/amend || exit
>>> # This is like --amend, but with a different message
>>> eval "$author_script"
>>> export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE
>>> $USE_OUTPUT git commit -F "$MSG" $EDIT_COMMIT
>>> ;;
>> The "export" here makes me somewhat nervous -- no chance these
>> leak into the next round?
>
> I am somewhat wary: I get quoting wrong all the time. Would
>
> $USE_OUTPUT $author_script git commit -F "$MSG" $EDIT_COMMIT
>
> work? I have the slight suspicion that it would not, since
>
> eval "$author_script"
>
> needs extra quoting in $author_script, no?
How about:
eval "$author_script"
GIT_AUTHOR_NAME="$GIT_AUTHOR_NAME" \
GIT_AUTHOR_EMAIL="$GIT_AUTHOR_EMAIL" \
GIT_AUTHOR_DATE="$GIT_AUTHOR_DATE" \
$USE_OUTPUT git commit -F "$MSG" $EDIT_COMMIT
and if you dislike that, put the two questionable lines in parenthesis.
-- Hannes
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox