* Reflog support status
From: Shawn Pearce @ 2006-07-11 6:34 UTC (permalink / raw)
To: git
My recent flurry of patches tonight (looks to be 5 total, 6
counting the user.name/user.email bug fix) should now include
reasonably useful information messages anytime a ref which has an
associated reflog gets updated, unless the update was made by one
of the following:
git-archimport
git-cvsimport
git-svnimport
git-receive-pack
Which is pretty reasonable.
I'll try to tackle git-receive-pack tomorrow night, but the reason
I have been putting it off is it would die a horrible death (exit
anyway) if it attempts to update a logged ref and GIT_COMMITTER_IDENT
can't be determined. But if the repository owner has enabled
reflogging exiting is probably the right thing to do in that case...
I'd also like to parameterize git-am's reflog entries the way I
did with git-merge, this way git-rebase will report as 'rebase'
in the log rather than 'am'. Again, I'll see if I can get that
done tomorrow night.
Junio: do you happen to still have that reflog program you put
together? I'm wondering if maybe we shouldn't include a git-reflog
to cat the reflog file in a more human friendly format than the
timestamps contained within the file, not to mention maybe also do
oneline commit pretty printing.
--
Shawn.
^ permalink raw reply
* Log ref changes made by resolve.
From: Shawn Pearce @ 2006-07-11 6:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Since git-resolve is essentially a form of git-merge record any
ref updates it makes similiar to how git-merge would record them.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
I have to ask: Should git-resolve just be calling git-merge? It
does a fraction of what git-merge does yet it also can do the
basic fast-forward and in-index merge that git-merge does...
git-resolve.sh | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/git-resolve.sh b/git-resolve.sh
index 1c7aaef..a7bc680 100755
--- a/git-resolve.sh
+++ b/git-resolve.sh
@@ -15,6 +15,7 @@ dropheads() {
head=$(git-rev-parse --verify "$1"^0) &&
merge=$(git-rev-parse --verify "$2"^0) &&
+merge_name="$2" &&
merge_msg="$3" || usage
#
@@ -43,7 +44,8 @@ case "$common" in
"$head")
echo "Updating from $head to $merge"
git-read-tree -u -m $head $merge || exit 1
- git-update-ref HEAD "$merge" "$head"
+ git-update-ref -m "resolve $merge_name: Fast forward" \
+ HEAD "$merge" "$head"
git-diff-tree -p $head $merge | git-apply --stat
dropheads
exit 0
@@ -100,6 +102,7 @@ if [ $? -ne 0 ]; then
fi
result_commit=$(echo "$merge_msg" | git-commit-tree $result_tree -p $head -p $merge)
echo "Committed merge $result_commit"
-git-update-ref HEAD "$result_commit" "$head"
+git-update-ref -m "resolve $merge_name: In-index merge" \
+ HEAD "$result_commit" "$head"
git-diff-tree -p $head $result_commit | git-apply --stat
dropheads
--
1.4.1.gc48f
^ permalink raw reply related
* Why doesn't git-rerere automatically commit a resolution?
From: Shawn Pearce @ 2006-07-11 6:16 UTC (permalink / raw)
To: git
I'm curious... I have a pair of topic branches which don't merge
together cleanly by recursive (due to conflicting hunks in the
same line segments). I enabled git-rerere, ran the merge, fixed
up the hunks and committed it. git-rerere built its cache, as
the next time I pulled the two topic branches together and got
the same conflicts it correctly regenerated the prior resolution
(and printed a message saying as much).
But it git-rerere left the files unmerged in the index and it
doesn't generate a commit for the merge, even though there are no
merge conflicts remaining. I expected it to update the index (to
merge the stages) and to generate a commit if possible; especially
in this case as I was pulling the exact same two commits together
again with the exact same merge base commit.
So I'm wondering why doesn't it try to finish the merge? Was there
a really deep rooted reason behind it or was it simply easier/safer
to let the user sort out the working directory state every time?
--
Shawn.
^ permalink raw reply
* [PATCH] Log ref changes made by quiltimport.
From: Shawn Pearce @ 2006-07-11 6:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
When importing a quilt patch to a branch which has a reflog record
the update to HEAD with a log message indicating the change was
made by quiltimport and what patch caused the change.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
Aside from git-resolve and git-clone this is the last shell script
which didn't include a log message when invoking update-ref. So
here it is. :-)
git-quiltimport.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-quiltimport.sh b/git-quiltimport.sh
index 86b51ab..9f16e18 100755
--- a/git-quiltimport.sh
+++ b/git-quiltimport.sh
@@ -112,7 +112,7 @@ for patch_name in $(cat "$QUILT_PATCHES/
git-apply --index -C1 "$tmp_patch" &&
tree=$(git-write-tree) &&
commit=$((echo "$SUBJECT"; echo; cat "$tmp_msg") | git-commit-tree $tree -p $commit) &&
- git-update-ref HEAD $commit || exit 4
+ git-update-ref -m "quiltimport: $patch_name" HEAD $commit || exit 4
fi
done
rm -rf $tmp_dir || exit 5
--
1.4.1.gc48f
^ permalink raw reply related
* Re: 2 questions on git-send-email usage
From: moreau francis @ 2006-07-11 6:09 UTC (permalink / raw)
To: jnareb; +Cc: git
(please let me CCed when replying)
2006/7/10, Jakub Narebski <jnareb@gmail.com>:
> moreau francis wrote:
>
> > I'm wondering what am I supposed to answer when git-send-email
> > is asking me :
> >
> > Message-ID to be used as In-Reply-To for the first email?
> >
> > I'm running this command:
> >
> > $ git-send-email --no-signed-off-by-cc --no-chain-reply-to --to \
> > foo@bar.com --compose /tmp/patch/
> >
> > to write an introductory message, and all patches are sent as replies to
> > this introductory email sent.
>
> Empty string (i.e. RET) should do if you don't want to attach your series of
> patches somewhere in existing thread.
ok I'll try
--in-reply-to ""
>
> > I also noticed that git-send-email removes the commit message of each
> > patches I sent, I don't think this is the normal behaviour though. What
> > am I missing ?
>
> Are patches formatted using git-format-patch?
>
yes
Francis
^ permalink raw reply
* [PATCH] Log ref changes made by git-merge and git-pull.
From: Shawn Pearce @ 2006-07-11 5:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
When git-merge updates HEAD as a result of a merge record what
happened during the merge into the reflog associated with HEAD
(if any). The log reports who caused the update (git-merge or
git-pull, by invoking git-merge), what the remote ref names were
and the type of merge process used.
The merge information can be useful when reviewing a reflog for
a branch such as `master` where fast forward and trivial in index
merges might be common as the user tracks an upstream.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
git-merge.sh | 17 ++++++++++++++---
git-pull.sh | 3 ++-
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/git-merge.sh b/git-merge.sh
index 24e3b50..a9cfafb 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -58,7 +58,13 @@ squash_message () {
}
finish () {
- test '' = "$2" || echo "$2"
+ if test '' = "$2"
+ then
+ rlogm="$rloga"
+ else
+ echo "$2"
+ rlogm="$rloga: $2"
+ fi
case "$squash" in
t)
echo "Squash commit -- not updating HEAD"
@@ -70,7 +76,7 @@ finish () {
echo "No merge message -- not updating HEAD"
;;
*)
- git-update-ref HEAD "$1" "$head" || exit 1
+ git-update-ref -m "$rlogm" HEAD "$1" "$head" || exit 1
;;
esac
;;
@@ -88,6 +94,7 @@ finish () {
esac
}
+rloga=
while case "$#" in 0) break ;; esac
do
case "$1" in
@@ -117,6 +124,9 @@ do
die "available strategies are: $all_strategies" ;;
esac
;;
+ --reflog-action=*)
+ rloga=`expr "z$1" : 'z-[^=]*=\(.*\)'`
+ ;;
-*) usage ;;
*) break ;;
esac
@@ -131,6 +141,7 @@ shift
# All the rest are remote heads
test "$#" = 0 && usage ;# we need at least one remote head.
+test "$rloga" = '' && rloga="merge: $@"
remoteheads=
for remote
@@ -316,7 +327,7 @@ if test '' != "$result_tree"
then
parents=$(git-show-branch --independent "$head" "$@" | sed -e 's/^/-p /')
result_commit=$(echo "$merge_msg" | git-commit-tree $result_tree $parents) || exit
- finish "$result_commit" "Merge $result_commit, made by $wt_strategy."
+ finish "$result_commit" "Merge made by $wt_strategy."
dropsave
exit 0
fi
diff --git a/git-pull.sh b/git-pull.sh
index d337bf4..f380437 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -102,5 +102,6 @@ case "$strategy_args" in
esac
merge_name=$(git-fmt-merge-msg <"$GIT_DIR/FETCH_HEAD") || exit
-git-merge $no_summary $no_commit $squash $strategy_args \
+git-merge "--reflog-action=pull $*" \
+ $no_summary $no_commit $squash $strategy_args \
"$merge_name" HEAD $merge_head
--
1.4.1.gc48f
^ permalink raw reply related
* Re: [PATCH] Avoid C++ comments, use C comments instead
From: Pavel Roskin @ 2006-07-11 5:17 UTC (permalink / raw)
To: Olivier Galibert; +Cc: git
In-Reply-To: <20060710114117.GA62514@dspnet.fr.eu.org>
Hello!
On Mon, 2006-07-10 at 13:41 +0200, Olivier Galibert wrote:
> Supporting old, not-standard-anymore compilers has a cost in
> maintainability, by precluding the use of better constructs (//
> comments, declarations near initialisation, struct initializers...).
> Additionally, it gets harder and harder to have people test for them.
Sorry for one more addition to this thread. I just want to clear some
misunderstanding. The whole point of fixing the comments is to make is
easier to test for other compatibility issues using gcc.
For gcc to report post-c89 features, "-pedantic -std=c89" should be
supplied. This option makes gcc report the c99 comments as errors and
other c99 features as warnings. The errors would stand in the way of
finding the warnings.
I'm not saying all non-c89 constructs should be fixed, but if we get a
report that some feature is not working with some compiler, we could
compile git with "-pedantic -std=c89", find corresponding warnings and
fix them. The comments would stand in the way for somebody using gcc.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: reflog doesn't note that commit was --amend-ed, and doesn't record pulls
From: Shawn Pearce @ 2006-07-11 3:38 UTC (permalink / raw)
To: Junio C Hamano, Jakub Narebski; +Cc: git
In-Reply-To: <e8uhvg$5o1$2@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> wrote:
> Reflog doesn't seem also to record pulls (e.g. master branch): pulls has
> empty reflog message part.
Fixed with the patch below. git-merge doesn't record the merges yet,
so some changes made by git-pull still aren't logged as nicely as
one would like. But don't fear, that will be coming soon. :-)
-->--
Log ref changes made by git-fetch and git-pull.
When git-fetch updates a reference record in the associated reflog
what type of update took place and who caused it (git-fetch or
git-pull, by invoking git-fetch).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
git-fetch.sh | 20 +++++++++++++++-----
git-pull.sh | 2 +-
2 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/git-fetch.sh b/git-fetch.sh
index 48818f8..5e4c4d6 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -11,6 +11,7 @@ LF='
'
IFS="$LF"
+rloga=fetch
no_tags=
tags=
append=
@@ -51,6 +52,9 @@ do
-k|--k|--ke|--kee|--keep)
keep=--keep
;;
+ --reflog-action=*)
+ rloga=`expr "z$1" : 'z-[^=]*=\(.*\)'`
+ ;;
-*)
usage
;;
@@ -75,6 +79,9 @@ refs=
rref=
rsync_slurped_objects=
+rloga="$rloga $remote_nick"
+test "$remote_nick" == "$remote" || rloga="$rloga $remote"
+
if test "" = "$append"
then
: >"$GIT_DIR/FETCH_HEAD"
@@ -149,11 +156,12 @@ fast_forward_local () {
[ "$verbose" ] && echo >&2 "* $1: same as $3"
else
echo >&2 "* $1: updating with $3"
+ git-update-ref -m "$rloga: updating tag" "$1" "$2"
fi
else
echo >&2 "* $1: storing $3"
+ git-update-ref -m "$rloga: storing tag" "$1" "$2"
fi
- git-update-ref "$1" "$2"
;;
refs/heads/* | refs/remotes/*)
@@ -174,7 +182,7 @@ fast_forward_local () {
*,$local)
echo >&2 "* $1: fast forward to $3"
echo >&2 " from $local to $2"
- git-update-ref "$1" "$2" "$local"
+ git-update-ref -m "$rloga: fast-forward" "$1" "$2" "$local"
;;
*)
false
@@ -184,7 +192,7 @@ fast_forward_local () {
case ",$force,$single_force," in
*,t,*)
echo >&2 " forcing update."
- git-update-ref "$1" "$2" "$local"
+ git-update-ref -m "$rloga: forced-update" "$1" "$2" "$local"
;;
*)
echo >&2 " not updating."
@@ -194,7 +202,7 @@ fast_forward_local () {
}
else
echo >&2 "* $1: storing $3"
- git-update-ref "$1" "$2"
+ git-update-ref -m "$rloga: storing head" "$1" "$2"
fi
;;
esac
@@ -422,7 +430,9 @@ case ",$update_head_ok,$orig_head," in
curr_head=$(git-rev-parse --verify HEAD 2>/dev/null)
if test "$curr_head" != "$orig_head"
then
- git-update-ref HEAD "$orig_head"
+ git-update-ref \
+ -m "$rloga: Undoing incorrectly fetched HEAD." \
+ HEAD "$orig_head"
die "Cannot fetch into the current branch."
fi
;;
diff --git a/git-pull.sh b/git-pull.sh
index 076785c..d337bf4 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -45,7 +45,7 @@ do
done
orig_head=$(git-rev-parse --verify HEAD) || die "Pulling into a black hole?"
-git-fetch --update-head-ok "$@" || exit 1
+git-fetch --update-head-ok --reflog-action=pull "$@" || exit 1
curr_head=$(git-rev-parse --verify HEAD)
if test "$curr_head" != "$orig_head"
--
1.4.1.gc48f
^ permalink raw reply related
* Re: [PATCH] Eliminate Scalar::Util usage from private-Error.pm
From: Randal L. Schwartz @ 2006-07-11 3:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <7v4pxo7vk4.fsf@assigned-by-dhcp.cox.net>
>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
Junio> Petr Baudis <pasky@suse.cz> writes:
>> We used just the blessed() routine so steal it from Scalar/Util.pm. ;-)
>> (Unfortunately, Scalar::Util is not bundled with older Perl versions.)
Junio> Eh, but aren't we going to rip out the try{}catch{} stuff to
Junio> avoid extra closures?
Heh. Yeah, didn't notice that. I keep cutting down the trees,
but the forest remains. :)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: reflog doesn't note that commit was --amend-ed, and doesn't record pulls
From: Shawn Pearce @ 2006-07-11 2:48 UTC (permalink / raw)
To: Jakub Narebski, Junio C Hamano; +Cc: git
In-Reply-To: <e8uhvg$5o1$2@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> wrote:
> Additionally, while reflog records git-reset invocations, it doesn't
> distinguish between an ordinary commit, and commit --amend (which I do
> a lot, most time because of forgotten update-index; yes, I know about commit
> -a option ;-). Well, you can extract this information looking at current
> and previous commit sha1, but it would be nice to have it noted somewhat in
> message part of reflog.
I'm attaching a patch below which fixes this. It denotes the 4
major types of commits: initial, normal, amend, merge.
> Reflog doesn't seem also to record pulls (e.g. master branch): pulls has
> empty reflog message part.
Yea, that's a 'TODO' item. Now that someone is complaining about
it I'll see if I can't get a fix done later tonight for it.
Its probably going to be a few patches: one for git-merge and
another for receive-pack.c.
-->--
Record the type of commit operation in the reflog.
If committing a merge (.git/MERGE_HEAD exists), an initial tree
(no HEAD) or using --amend to amend the prior commit then denote
the subtype of commit in the reflog. This helps to distinguish
amended or merge commits from normal commits.
In the case of --amend the prior sha1 is probably the commit which
is being thrown away in favor of the new commit. Since it is likely
that the old commit doesn't have any ref pointing to it anymore
it can be interesting to know why that the commit was replaced
and orphaned.
In the case of a merge the prior sha1 is probably the first parent
of the new merge commit. Consequently having its prior sha1 in the
reflog is slightly less interesting but its still informative to
know the commit was the result of a merge which had to be completed
by hand.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
git-commit.sh | 6 +++++-
t/t1400-update-ref.sh | 19 ++++++++++++++++---
2 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/git-commit.sh b/git-commit.sh
index 22c4ce8..05eccfe 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -635,9 +635,12 @@ fi
PARENTS="-p HEAD"
if test -z "$initial_commit"
then
+ rloga='commit'
if [ -f "$GIT_DIR/MERGE_HEAD" ]; then
+ rloga='commit (merge)'
PARENTS="-p HEAD "`sed -e 's/^/-p /' "$GIT_DIR/MERGE_HEAD"`
elif test -n "$amend"; then
+ rloga='commit (amend)'
PARENTS=$(git-cat-file commit HEAD |
sed -n -e '/^$/q' -e 's/^parent /-p /p')
fi
@@ -649,6 +652,7 @@ else
fi
PARENTS=""
current=
+ rloga='commit (initial)'
fi
if test -z "$no_edit"
@@ -724,7 +728,7 @@ then
fi &&
commit=$(cat "$GIT_DIR"/COMMIT_MSG | git-commit-tree $tree $PARENTS) &&
rlogm=$(sed -e 1q "$GIT_DIR"/COMMIT_MSG) &&
- git-update-ref -m "commit: $rlogm" HEAD $commit $current &&
+ git-update-ref -m "$rloga: $rlogm" HEAD $commit $current &&
rm -f -- "$GIT_DIR/MERGE_HEAD" &&
if test -f "$NEXT_INDEX"
then
diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh
index df3e993..6a3515d 100755
--- a/t/t1400-update-ref.sh
+++ b/t/t1400-update-ref.sh
@@ -188,17 +188,30 @@ test_expect_success \
echo OTHER >F &&
GIT_AUTHOR_DATE="2005-05-26 23:41" \
GIT_COMMITTER_DATE="2005-05-26 23:41" git-commit -F M -a &&
- h_OTHER=$(git-rev-parse --verify HEAD)
+ h_OTHER=$(git-rev-parse --verify HEAD) &&
+ echo FIXED >F &&
+ EDITOR=true \
+ GIT_AUTHOR_DATE="2005-05-26 23:44" \
+ GIT_COMMITTER_DATE="2005-05-26 23:44" git-commit --amend &&
+ h_FIXED=$(git-rev-parse --verify HEAD) &&
+ echo TEST+FIXED >F &&
+ echo Merged initial commit and a later commit. >M &&
+ echo $h_TEST >.git/MERGE_HEAD &&
+ GIT_AUTHOR_DATE="2005-05-26 23:45" \
+ GIT_COMMITTER_DATE="2005-05-26 23:45" git-commit -F M &&
+ h_MERGED=$(git-rev-parse --verify HEAD)
rm -f M'
cat >expect <<EOF
-$Z $h_TEST $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> 1117150200 +0000 commit: add
+$Z $h_TEST $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> 1117150200 +0000 commit (initial): add
$h_TEST $h_OTHER $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> 1117150860 +0000 commit: The other day this did not work.
+$h_OTHER $h_FIXED $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> 1117151040 +0000 commit (amend): The other day this did not work.
+$h_FIXED $h_MERGED $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> 1117151100 +0000 commit (merge): Merged initial commit and a later commit.
EOF
test_expect_success \
'git-commit logged updates' \
'diff expect .git/logs/$m'
-unset h_TEST h_OTHER
+unset h_TEST h_OTHER h_FIXED h_MERGED
test_expect_success \
'git-cat-file blob master:F (expect OTHER)' \
--
1.4.1.gc48f
^ permalink raw reply related
* Re: [PATCH] Eliminate Scalar::Util usage from private-Error.pm
From: Junio C Hamano @ 2006-07-11 1:57 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060711005354.5911.62525.stgit@machine.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> We used just the blessed() routine so steal it from Scalar/Util.pm. ;-)
> (Unfortunately, Scalar::Util is not bundled with older Perl versions.)
Eh, but aren't we going to rip out the try{}catch{} stuff to
avoid extra closures?
^ permalink raw reply
* Re: [PATCH] Eliminate Scalar::Util usage from private-Error.pm
From: Randal L. Schwartz @ 2006-07-11 1:42 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <867j2knckf.fsf@blue.stonehenge.com>
>>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:
>>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:
Randal> sub blessed {
Randal> my $item = shift;
Randal> local $@; # don't kill an outer $@
Randal> ref $item and eval { $item->can('can') };
Randal> }
Randal> Oops, lose the local $@ line. Just found out this is a broken
Randal> thing in current Perls. The rest is good though.
And thirdly, ignore what I *just* said, and concentrate on what I *previously*
said, becaused my testing was off.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: [PATCH] Eliminate Scalar::Util usage from private-Error.pm
From: Randal L. Schwartz @ 2006-07-11 1:40 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <86bqrwncnq.fsf@blue.stonehenge.com>
>>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:
Randal> sub blessed {
Randal> my $item = shift;
Randal> local $@; # don't kill an outer $@
Randal> ref $item and eval { $item->can('can') };
Randal> }
Oops, lose the local $@ line. Just found out this is a broken
thing in current Perls. The rest is good though.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: [PATCH] Eliminate Scalar::Util usage from private-Error.pm
From: Randal L. Schwartz @ 2006-07-11 1:38 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20060711005354.5911.62525.stgit@machine.or.cz>
>>>>> "Petr" == Petr Baudis <pasky@suse.cz> writes:
Petr> We used just the blessed() routine so steal it from Scalar/Util.pm. ;-)
Petr> (Unfortunately, Scalar::Util is not bundled with older Perl versions.)
Wow. That's sure the long way around for what I would use this for:
sub blessed {
my $item = shift;
local $@; # don't kill an outer $@
ref $item and eval { $item->can('can') };
}
We call it "doing the can-can". :)
And this solution has the advantage that it doesn't pollute UNIVERSAL.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* [PATCH] Eliminate Scalar::Util usage from private-Error.pm
From: Petr Baudis @ 2006-07-11 0:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20060710130046.GW29115@pasky.or.cz>
We used just the blessed() routine so steal it from Scalar/Util.pm. ;-)
(Unfortunately, Scalar::Util is not bundled with older Perl versions.)
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
perl/private-Error.pm | 20 ++++++++++++++++----
1 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/perl/private-Error.pm b/perl/private-Error.pm
index ebd0749..848e82b 100644
--- a/perl/private-Error.pm
+++ b/perl/private-Error.pm
@@ -43,8 +43,6 @@ sub throw_Error_Simple
# Exported subs are defined in Error::subs
-use Scalar::Util ();
-
sub import {
shift;
local $Exporter::ExportLevel = $Exporter::ExportLevel + 1;
@@ -290,6 +288,20 @@ use vars qw(@EXPORT_OK @ISA %EXPORT_TAGS
@ISA = qw(Exporter);
+
+# Stolen from Scalar::Util:
+
+# Hope nobody defines a sub by this name
+sub UNIVERSAL::a_sub_not_likely_to_be_here { ref($_[0]) }
+
+sub blessed ($) {
+ local($@, $SIG{__DIE__}, $SIG{__WARN__});
+ length(ref($_[0]))
+ ? eval { $_[0]->a_sub_not_likely_to_be_here }
+ : undef
+}
+
+
sub run_clauses ($$$\@) {
my($clauses,$err,$wantarray,$result) = @_;
my $code = undef;
@@ -312,7 +324,7 @@ sub run_clauses ($$$\@) {
$i -= 2;
next CATCHLOOP;
}
- elsif(Scalar::Util::blessed($err) && $err->isa($pkg)) {
+ elsif(blessed($err) && $err->isa($pkg)) {
$code = $catch->[$i+1];
while(1) {
my $more = 0;
@@ -421,7 +433,7 @@ sub try (&;$) {
if (defined($err))
{
- if (Scalar::Util::blessed($err) && $err->can('throw'))
+ if (blessed($err) && $err->can('throw'))
{
throw $err;
}
^ permalink raw reply related
* Re: [PATCH] Avoid C++ comments, use C comments instead
From: Junio C Hamano @ 2006-07-11 0:34 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060711001504.GA10700@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> Olivier Galibert <galibert@pobox.com> wrote:
>>
>> Maybe git can be perfectly happy with c89. I don't know. I know the
>> linux kernel requires c99, mostly for the struct initializers. My
>> point was that staying at the c89 level has a maintainance cost, and a
>> cost/benefit analysis should be done to decide whether it is a good
>> idea.
I am generally in favor of the effect C99 struct and array
initializers have on the readability, but we also need to
balance that with the reality. The patch is only about a few
structs and one array if I recall correctly isn't it?
What Olivier says is perfectly correct, and after "cost/benefit
analysis", I would have to say avoiding some C99 is fine if that
makes people's life on some major non-Linux platforms easier.
C99 clean-up is already in the "master", so please do not waste
more bandwidth nor time on this issue, but instead spend time
elsewhere to make our system better for more people ;-).
Thanks.
^ permalink raw reply
* Re: git-update-ref (reflog) uses bogus author ident information
From: Shawn Pearce @ 2006-07-11 0:32 UTC (permalink / raw)
To: Jakub Narebski, Junio C Hamano; +Cc: git
In-Reply-To: <20060711002754.GB10700@spearce.org>
Shawn Pearce <spearce@spearce.org> wrote:
> Allow user.name and user.email to drive reflog entry.
>
> Apparently calling setup_ident() after git_config causes the
> user.name and user.email values read from the config file to be
> replaced with the data obtained from the host. This means that
> users who have setup their email address in user.email will instead
> be writing reflog entries with their hostname.
>
> Moving setup_ident() to before git_config in update-ref resolves
> this ordering problem.
Whoops, I forgot this line: :-)
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
> ---
> builtin-update-ref.c | 1 +
> refs.c | 1 -
> 2 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/builtin-update-ref.c b/builtin-update-ref.c
> index 00333c7..83094ab 100644
> --- a/builtin-update-ref.c
> +++ b/builtin-update-ref.c
> @@ -12,6 +12,7 @@ int cmd_update_ref(int argc, const char
> unsigned char sha1[20], oldsha1[20];
> int i;
>
> + setup_ident();
> setup_git_directory();
> git_config(git_default_config);
>
> diff --git a/refs.c b/refs.c
> index 2d9c1dc..56db394 100644
> --- a/refs.c
> +++ b/refs.c
> @@ -379,7 +379,6 @@ static int log_ref_write(struct ref_lock
> lock->log_file, strerror(errno));
> }
>
> - setup_ident();
> committer = git_committer_info(1);
> if (msg) {
> maxlen = strlen(committer) + strlen(msg) + 2*40 + 5;
> --
> 1.4.1.gc48f
^ permalink raw reply
* Re: git-update-ref (reflog) uses bogus author ident information
From: Shawn Pearce @ 2006-07-11 0:27 UTC (permalink / raw)
To: Jakub Narebski, Junio C Hamano; +Cc: git
In-Reply-To: <e8uele$o7t$2@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> wrote:
> git-log reports
>
> commit 059111c9381ce1444d17c8fc35606b0aa417ca42
> Author: Jakub Narebski <jnareb@gmail.com>
> Date: Sat Jul 8 18:52:35 2006 +0200
>
> configure.ac vertical whitespace usage cleanup
>
> git-var -l shows:
>
> GIT_COMMITTER_IDENT=Jakub Narebski <jnareb@gmail.com> 1152564452 +0200
> GIT_AUTHOR_IDENT=Jakub Narebski <jnareb@gmail.com> 1152564452 +0200
>
> BUT in git/.git/logs/refs/heads/autoconf I have (broken into lines):
> fe7b45a419ae62ed96148d98f6aba8710a6f6245
> 059111c9381ce1444d17c8fc35606b0aa417ca42
> Jakub Narebski <jnareb@roke.D-201> 1152377555 +0200
> commit: configure.ac vertical whitespace usage cleanu
>
> where "roke.D-201" are results of "hostname -f" on my computer, and are
> suitable _only_ for my small private local network.
>
> Bug or a feature?
This is definately a bug. The reflog uses the same ident code
that commit-tree uses, with the idea that GIT_COMMITTER_IDENT would
drive the entry in the reflog, as you expected it to.
Looking in refs.c at log_ref_write its invoking setup_ident()
then git_committer_info(1). git_committer_info should be using
the environment variables (GIT_COMMITTER_NAME, GIT_COMMITTER_EMAIL,
GIT_COMMITTER_DATE) with defaults back to the gecos values. Based
on that it would seem that the user data in .git/config is being
ignored... Hm.
So you must be expecting .git/config to be supplying your data but
its getting overrwritten by setup_ident() in log_ref_write.
Here's the bug fix. Sorry about that one. That bug has been in
there since the reflog code was first put into GIT. :-)
-->--
Allow user.name and user.email to drive reflog entry.
Apparently calling setup_ident() after git_config causes the
user.name and user.email values read from the config file to be
replaced with the data obtained from the host. This means that
users who have setup their email address in user.email will instead
be writing reflog entries with their hostname.
Moving setup_ident() to before git_config in update-ref resolves
this ordering problem.
---
builtin-update-ref.c | 1 +
refs.c | 1 -
2 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-update-ref.c b/builtin-update-ref.c
index 00333c7..83094ab 100644
--- a/builtin-update-ref.c
+++ b/builtin-update-ref.c
@@ -12,6 +12,7 @@ int cmd_update_ref(int argc, const char
unsigned char sha1[20], oldsha1[20];
int i;
+ setup_ident();
setup_git_directory();
git_config(git_default_config);
diff --git a/refs.c b/refs.c
index 2d9c1dc..56db394 100644
--- a/refs.c
+++ b/refs.c
@@ -379,7 +379,6 @@ static int log_ref_write(struct ref_lock
lock->log_file, strerror(errno));
}
- setup_ident();
committer = git_committer_info(1);
if (msg) {
maxlen = strlen(committer) + strlen(msg) + 2*40 + 5;
--
1.4.1.gc48f
^ permalink raw reply related
* Re: Items not covered by repository-layout.txt
From: Junio C Hamano @ 2006-07-11 0:23 UTC (permalink / raw)
To: jnareb; +Cc: git
In-Reply-To: <e8uhjg$5o1$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Could you then tell me what is the format of FETCH_HEAD and what other *_HEADs
> can be seen in $GIT_DIR (MERGE_HEAD?)?
Which essentially is that you are telling me to do that, but I
am a bit busy this week.
If you can use the source to figure them out, that would be
great; otherwise this can wait or others can chime in.
For FETCH_HEAD fmt-merge-msg and git-pull would be helpful.
The general format is, one entry per line:
object name <TAB> merge-marker <TAB> notes
where merge-marker is either empty (for commits to be merged by
git-pull that called git-fetch) or not-for-merge, and notes is a
human readable comment that describes where that object came
from. Note that this is read both by humans _AND_ machine;
fmt-merge-msg relies on how it is stated.
Others "git grep -e _HEAD -- '*.sh'" perhaps.
ORIG_HEAD - used to keep the value of HEAD before we do
anything we might regret
MERGE_HEAD - one or more commit object names that are
being merged into the current branch during
a merge.
MERGE_MSG - generated message for an automerge.
^ permalink raw reply
* Re: [PATCH] Avoid C++ comments, use C comments instead
From: Shawn Pearce @ 2006-07-11 0:15 UTC (permalink / raw)
To: Olivier Galibert; +Cc: git
In-Reply-To: <20060710235122.GB26528@dspnet.fr.eu.org>
Olivier Galibert <galibert@pobox.com> wrote:
> On Tue, Jul 11, 2006 at 02:25:44AM +0300, Yakov Lerner wrote:
> > I am writing in order to ask, whether there maybe
> > some c99-to-c89 source convertor that can be
> > automatically applied to the .c before compiling with
> > pre-c99 compiler ?
>
> Comments are easy. Moving declarations without breaking initializers
> is harder. Rewriting the struct initializers is pretty much
> impossible without the tool turning into a full-blown C parser.
>
> Maybe git can be perfectly happy with c89. I don't know. I know the
> linux kernel requires c99, mostly for the struct initializers. My
> point was that staying at the c89 level has a maintainance cost, and a
> cost/benefit analysis should be done to decide whether it is a good
> idea. Answering "get a C compiler", as is being done for some years
> now for people not wanting prototypes, is an option not to neglect.
GIT 1.2.3 had a lot more struct initializers than GIT 1.4.1 has. So
apparently it was cleaner to remove a few of them in some cases then
it was to keep them in. But that's besides the point.
I can understand the core maintainers not wanting to apply my patch
and lose the benefits of c99, and if I have to I'll carry a private
branch with that patch and hand-edit future versions as necessary
to get the same result... but I'd hate to see another user have
to do the same work for the same reason.
I'm not a big contributor to GIT (I certainly don't contribute
nearly as much code as most others) and I'm also not a big user of
GIT (I don't develop for the Linux kernel) so I not expecting the
core to drop to c89 just for me and this old compiler. :-)
After reading this thread I'm thinking that this probably shouldn't
get merged in and that I should carry the tweaks locally to get
GIT to build on the only compiler I have available on that system.
Now that GIT 1.4.1 is installed on there I'm unlikely to upgrade it
for at least 6 months, as I'm using only the very low level plumbing
(git-read-tree, git-write-tree, git-update-index, git-repack).
Remerging these c99 downgrades at that time shouldn't be a huge
issue for me since its probably going to be done so infrequently.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] fix git-repack for use with GIT_TRACE
From: Junio C Hamano @ 2006-07-11 0:11 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: git
In-Reply-To: <E1FzvZG-0002C1-UN@moooo.ath.cx>
Matthias Lederhofer <matled@gmx.net> writes:
> Ok, this patch should fix this. Instead of "echo abort" another more
> meaningful message could be used.
"git-rev-list died with exit code $?" perhaps.
> I checked the other scripts which
> redirect stderr and they should be fine. In the tests I found
> t/t1200-tutorial.sh:38
> t/t1300-repo-config.sh:276
> t/t5500-fetch-pack.sh:66
> redirecting stderr, which probably fail which GIT_TRACE.
Probably t/test-lib.sh should unset GIT_TRACE then like it does
for other environment variables.
^ permalink raw reply
* Re: [PATCH] Avoid C++ comments, use C comments instead
From: Olivier Galibert @ 2006-07-10 23:51 UTC (permalink / raw)
To: git
In-Reply-To: <f36b08ee0607101625y6eaec83ck22dd20b4f27a1846@mail.gmail.com>
On Tue, Jul 11, 2006 at 02:25:44AM +0300, Yakov Lerner wrote:
> I am writing in order to ask, whether there maybe
> some c99-to-c89 source convertor that can be
> automatically applied to the .c before compiling with
> pre-c99 compiler ?
Comments are easy. Moving declarations without breaking initializers
is harder. Rewriting the struct initializers is pretty much
impossible without the tool turning into a full-blown C parser.
Maybe git can be perfectly happy with c89. I don't know. I know the
linux kernel requires c99, mostly for the struct initializers. My
point was that staying at the c89 level has a maintainance cost, and a
cost/benefit analysis should be done to decide whether it is a good
idea. Answering "get a C compiler", as is being done for some years
now for people not wanting prototypes, is an option not to neglect.
OG.
^ permalink raw reply
* Re: [PATCH] Avoid C++ comments, use C comments instead
From: Olivier Galibert @ 2006-07-10 23:42 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Paul Serice, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0607110049470.29667@wbgn013.biozentrum.uni-wuerzburg.de>
On Tue, Jul 11, 2006 at 12:55:59AM +0200, Johannes Schindelin wrote:
> Judging by what you say, one could get the impression you'd have not much
> sympathy for people being stuck with non-C99 compilers.
More and more these people are stuck with such a compiler because they
want to be.
> Just look at it: if the OS vendor just does not _care_, and you blame the
> vendor for not providing something newer, the vendor does not _care_ about
> your complaint either. But the user does.
Well, I'm not talking about git here, but I'm not really interested in
making my code harder to maintain just to provide more value for said
vendor.
> However, there is a more important point to be made. If you are complying
> with an older standard, you get more users. More users = more bug testers.
On such systems, what you tend to find is bugs of the system, or
simply different, and sometimes somewhat nonsensical, implementations
of some compromise-happy standards like POSIX.
> And there were quite a few occasions where I found bugs by trying to run
> on a different platform, which was less forgiving than Linux. These are
> bugs you have a harder time to spot on Linux, _because_ Linux is so nice.
> But they will surface. And they will be a PITA to find.
And how many bugs or "features" of the platform did you have to code
around before finding a genuine bug?
> Anyway, it is best practice for a reason to program portably. (Well, at
> least if you are not living in Redmont.)
If "programming portably" meant catering to the oldest standards, then
you shouldn't even use prototypes or ansi-style function declarations.
After all, some people may be stuck with the old sun (or was it hp?)
compiler that was k&r only. And limit the filenames to 14 characters.
Also, you shouldn't require gtk, python, perl, fire or the wheel.
OG.
^ permalink raw reply
* Re: Revisiting large binary files issue.
From: Linus Torvalds @ 2006-07-10 23:28 UTC (permalink / raw)
To: Carl Baldwin; +Cc: git
In-Reply-To: <20060710230132.GA11132@hpsvcnb.fc.hp.com>
On Mon, 10 Jul 2006, Carl Baldwin wrote:
>
> When I set the window to 0 I one more issue. Even though the blobs are
> already compressed on disk I still seem to pay the penalty of inflating
> them into memory and then deflating them into the pack. When the window
> size is 0 this is just wasted cycles. With large binary files these
> wasted cycles slow down the push/fetch operation considerably. Couldn't
> the compressed blobs be copied into the pack without first deflating
> them in this 0 window case?
The problem is that the individual object disk format isn't actually the
same as the pack-file object format for one object. The header is
different: a pack-file uses a very dense bit packing, while the individual
object format is a bit less dense.
Sad, really, but it means that right now you can only re-use data that was
already packed (when the format matches).
Linus
^ permalink raw reply
* Re: [PATCH] Avoid C++ comments, use C comments instead
From: Yakov Lerner @ 2006-07-10 23:25 UTC (permalink / raw)
Cc: git
In-Reply-To: <Pine.LNX.4.63.0607110049470.29667@wbgn013.biozentrum.uni-wuerzburg.de>
On 7/11/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Mon, 10 Jul 2006, Olivier Galibert wrote:
>
> > On Mon, Jul 10, 2006 at 02:14:17PM -0500, Paul Serice wrote:
> > > If you want to write portable code, you have to take into account
> > > different operating systems _and_ different compilers. Writing your
> > > code for just a single compiler is almost as bad as writing your code
> > > for just a single operating system.
> >
> > Hmmm, that was not so much about gcc-specific code than which kind of
> > C you want to code to, the one from 1973, the one from 1989 or the one
> > from 1999? I personally don't have much sympathy for the OS vendors
> > giving you an older standard C compiler and selling you the up-to-date
> > one.
>
> Judging by what you say, one could get the impression you'd have not much
> sympathy for people being stuck with non-C99 compilers.
>
> Just look at it: if the OS vendor just does not _care_, and you blame the
> vendor for not providing something newer, the vendor does not _care_ about
> your complaint either. But the user does.
>
> However, there is a more important point to be made. If you are complying
> with an older standard, you get more users. More users = more bug testers.
>
> And there were quite a few occasions where I found bugs by trying to run
> on a different platform, which was less forgiving than Linux. These are
> bugs you have a harder time to spot on Linux, _because_ Linux is so nice.
> But they will surface. And they will be a PITA to find.
>
> Anyway, it is best practice for a reason to program portably. (Well, at
> least if you are not living in Redmont.)
Back in the beginning of nineties, c89 was new and the
prototypes was not yet impemented on many compilers.
One good trick of the time was automatic
source conversion. This protoize/unprotoize tool converted
sources from non-prototyped form to
prototyped, and the other way. (There was also #ifdef-trick
which was ugly as hell for the same purpose, and the __P()
macro trick, which was less ugly).
The benefit was that you got the benefit of both worlds,
(1) the benefit of prototypes when compiler was c89-compliant, and
(2) compilability with pre-c89 compilers when needed.
I am writing in order to ask, whether there maybe
some c99-to-c89 source convertor that can be
automatically applied to the .c before compiling with
pre-c99 compiler ?
Yakov
^ 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