* 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] 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
* [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: 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 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
* 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
* 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
* 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
* Re: Why doesn't git-rerere automatically commit a resolution?
From: Junio C Hamano @ 2006-07-11 6:58 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060711061626.GB11822@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> 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).
After all your merge is conflicting, so it should be sanity
checked. At least you would want to run a compile test and
preferably a whole test cycle if your project has one, before
making the result into a commit.
You _could_ make it to automatically make a commit, and run a
test then if the test does not succeed fix the mismerge with "git
commit --amend", but people are lazy.
> 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?
The philosophy is to optimize the tools to support disciplined
workflows better, and make sure that the users do not have to
worry about automated tools makeing mismerges.
Now, I am not against helping lazy workflows per se, but only on
one condition. Doing so should never make more disciplined
workflows harder or more difficult.
Not merging the index after rerere re-applies a previous
resolution to the working tree file is a deliberate design
decision. During conflict resolution, "git diff" against
unmerged index file is the second most useful command to check
your hand-merge result, and running update-index on these path
automatically robs this useful tool from the user. So, in order
to help more disciplined workflow, a bit of convenience for
lazier people is sacrficed here.
^ permalink raw reply
* Re: Why doesn't git-rerere automatically commit a resolution?
From: Matthias Kestenholz @ 2006-07-11 7:05 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060711061626.GB11822@spearce.org>
* Shawn Pearce (spearce@spearce.org) wrote:
> 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?
>
I am maintaining different websites from one git repository. The
code is almost the same between all versions, but the HTML templates
are not. Sometimes, modified templates in feature branches produce
mismerges which I want to fix up in different ways for different
websites. There, git-rerere doesn't help me at all. It does help
very much with the code and configuration files though.
To conclude, I have rerere enabled, but it does not always do the
right thing, so I am happy that I get a chance to inspect the files
before committing (I could also amend the commit later, but I still
think it's better that the user still needs to acknowledge the
result of the automatic merge.)
Matthias
^ permalink raw reply
* Re: merge-base: update the clean-up postprocessing
From: Junio C Hamano @ 2006-07-11 8:13 UTC (permalink / raw)
To: git; +Cc: A Large Angry SCM
In-Reply-To: <7vejx0cwwj.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> A fixed up version of this patch, along with your updated test,
> is at the tip of "pu".
>
> It does affect the processing time for cases where there are
> more than one merge bases negatively. To compute all merge-base
> for the 23 merges in the kernel reporitory, the old code with
> the "contaminate the well a bit more" clean-up phase takes 2.5
> seconds, while the new code takes 3.9 seconds.
>
> Processing all 2215 merges in the kernel repository (the other
> 2192 merges have one merge-base between the parents) takes 160
> seconds either way. In other words, multi merge-base merges are
> relatively rare and a bit more time spent to clean-up with the
> new code is lost in the noise.
>
> The numbers are taken from /usr/bin/time on an Athron 64X2 3800.
I did a similar test on git.git repository. Numbers are
interesting.
* I have 941 two-head merges. 89 of them are multi-base
merges. This is unproportionally higher compared to the
kernel repository.
* Both the version in "master" (i.e. the one with the horizon
effect) and this version with updated clean-up code produces
identical set of merge bases for all 941 two-head merges.
* The difference in processing time for 941 two-head merges
with both versions is lost within margin of error.
^ permalink raw reply
* [PATCH] t1400-update-ref: set VISUAL=true as well as EDITOR=true
From: Eric Wong @ 2006-07-11 8:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Eric Wong
I have VISUAL set in my environment, and it caused git-commit to
spawn my editor during the test.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
t/t1400-update-ref.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh
index 6a3515d..4f5b6bd 100755
--- a/t/t1400-update-ref.sh
+++ b/t/t1400-update-ref.sh
@@ -190,7 +190,7 @@ test_expect_success \
GIT_COMMITTER_DATE="2005-05-26 23:41" git-commit -F M -a &&
h_OTHER=$(git-rev-parse --verify HEAD) &&
echo FIXED >F &&
- EDITOR=true \
+ EDITOR=true VISUAL=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) &&
--
1.4.1.g710d
^ permalink raw reply related
* Re : 2 questions on git-send-email usage
From: moreau francis @ 2006-07-11 8:46 UTC (permalink / raw)
To: moreau francis, jnareb; +Cc: git
moreau francis wrote:
> (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 ""
ok it works. But wouldn't it make more sense to have by default --in-reply-to ""
when --compose is set ? That would mean "by default all patches are sent
as replies to the email I'm composing" which is usely what happens, no ?
>
> >
> > > 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
>
I think I have found out a clue. The commit message and Signed-off-by are
missing because the header patches are formatted like this:
>From 90df31ca209f85108976d18916f33f352a6ef340 Mon Sep 17 00:00:00 2001
From: Francis <francis.moreau2000@yahoo.fr>
Date: Thu, 8 Jun 2006 09:51:12 +0200
Subject: [PATCH 3/4] step #3: interrupt implementation
(cherry picked from 427778e2e622cdefa2c834edcc19bf102a35bc2d commit)
(cherry picked from fe4692336801fcbb42bb734bb6b6f9c041d63087 commit)
Signed-off-by: Francis <francis_moreau2000@yahoo.fr>
---
2 RETs is missing. One after the Subject line and the other before the
Signed-off-by line. If I add the first missing RET, all works fine. I guess
it's missing because of git-cherry-pick command. But I don't understand
why the last RET is missing
Can anybody tell me why ?
Thanks
Francis
^ permalink raw reply
* Most quality products for anyone who wants to become a champion in bed
From: Andres @ 2006-07-11 9:10 UTC (permalink / raw)
To: git
Good day to you bro!
Achieve astounding results in bed with these products designed to make any man a winner
Most quality products for anyone who wants to become a champion in bed
http://www.xylidinehf.com
The tongue that brings healing is a tree of life, but a deceitful tongue crushes the spirit Feed a cold starve a fever Can one go upon hot coals, and his feet not be burned?
The proof of the pudding is in the eating
^ permalink raw reply
* Re: [PATCH] t1400-update-ref: set VISUAL=true as well as EDITOR=true
From: Junio C Hamano @ 2006-07-11 9:15 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <11526072802855-git-send-email-normalperson@yhbt.net>
Eric Wong <normalperson@yhbt.net> writes:
> I have VISUAL set in my environment, and it caused git-commit to
> spawn my editor during the test.
I think it would be better to remove "EDITOR=: VISUAL=:"
settings from annotate-tests.sh, t1400-update-ref.sh and
t4013-diff-various.sh, and move that to test-lib.sh; there is no
point overriding them differently in each of these automated
tests.
^ permalink raw reply
* [RFC]: Pack-file object format for individual objects (Was: Revisiting large binary files issue.)
From: sf @ 2006-07-11 9:40 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0607101623230.5623@g5.osdl.org>
Linus Torvalds wrote:
...
> 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.
I just stumbled over the same fact and asked myself why there are still
two formats. Wouldn't it make more sense to use the pack-file object
format for individual objects as well?
As it happens individual objects all start with nibble 7 (deflated with
default _zlib_ window size of 32K) whereas in the pack-file object
format nibble 7 indicates delta entries which never occur as individual
files.
Roadmap for using pack-file format as individual object disk format:
Step 1. When reading individual objects from disk check the first nibble
and decode accordingly (see above).
Step 2. When writing individual objects to disk write them in pack-file
object format. Make that optional (config-file parameter, command line
option etc.)?
Step 3. Remove code for (old) individual object disk format.
Please comment.
Regards
Stephan
^ permalink raw reply
* Re: Re : 2 questions on git-send-email usage
From: Franck Bui-Huu @ 2006-07-11 10:08 UTC (permalink / raw)
To: moreau francis, Junio C Hamano; +Cc: jnareb, git
In-Reply-To: <20060711084635.81393.qmail@web25809.mail.ukl.yahoo.com>
moreau francis wrote:
> 2 RETs is missing. One after the Subject line and the other before the
> Signed-off-by line. If I add the first missing RET, all works fine. I guess
> it's missing because of git-cherry-pick command. But I don't understand
> why the last RET is missing
>
> Can anybody tell me why ?
>
Maybe that patch does what you want.
-- >8 --
Subject: [PATCH] Add a newline before appending "Signed-off-by:"
It looks nicer.
Signed-off-by: Franck Bui-Huu <vagabon.xyz@gmail.com>
---
log-tree.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/log-tree.c b/log-tree.c
index ebb49f2..2551a3f 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -19,7 +19,7 @@ static int append_signoff(char *buf, int
char *cp = buf;
/* Do we have enough space to add it? */
- if (buf_sz - at <= strlen(signed_off_by) + signoff_len + 2)
+ if (buf_sz - at <= strlen(signed_off_by) + signoff_len + 3)
return at;
/* First see if we already have the sign-off by the signer */
@@ -34,6 +34,7 @@ static int append_signoff(char *buf, int
return at; /* we already have him */
}
+ buf[at++] = '\n';
strcpy(buf + at, signed_off_by);
at += strlen(signed_off_by);
strcpy(buf + at, signoff);
--
1.4.1.g35c6-dirty
^ permalink raw reply related
* [PATCH] Typo fix
From: Alp Toker @ 2006-07-11 10:19 UTC (permalink / raw)
To: git
Signed-off-by: Alp Toker <alp@atoker.com>
---
Documentation/git-name-rev.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-name-rev.txt b/Documentation/git-name-rev.txt
index 43f8c25..37fbf66 100644
--- a/Documentation/git-name-rev.txt
+++ b/Documentation/git-name-rev.txt
@@ -33,7 +33,7 @@ EXAMPLE
-------
Given a commit, find out where it is relative to the local refs. Say somebody
-wrote you about that phantastic commit 33db5f4d9027a10e477ccf054b2c1ab94f74c85a.
+wrote you about that fantastic commit 33db5f4d9027a10e477ccf054b2c1ab94f74c85a.
Of course, you look into the commit, but that only tells you what happened, but
not the context.
--
1.4.1.g97c7-dirty
^ permalink raw reply related
* [PATCH] git-send-email: Remove redundant Reply-To header
From: Alp Toker @ 2006-07-11 10:19 UTC (permalink / raw)
To: git
In-Reply-To: <11526131791902-git-send-email-alp@atoker.com>
There is no sense in duplicating the sender address in Reply-To as it's
already provided in the From header.
Signed-off-by: Alp Toker <alp@atoker.com>
---
git-send-email.perl | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 64a8eef..1e2777c 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -413,7 +413,6 @@ sub send_message
To: $to
Cc: $cc
Subject: $subject
-Reply-To: $from
Date: $date
Message-Id: $message_id
X-Mailer: git-send-email $gitversion
--
1.4.1.g97c7-dirty
^ permalink raw reply related
* [PATCH] gitweb: Send XHTML as 'application/xhtml+xml' where possible
From: Alp Toker @ 2006-07-11 10:19 UTC (permalink / raw)
To: git
In-Reply-To: <11526131782190-git-send-email-alp@atoker.com>
"The 'text/html' media type [RFC2854] is primarily for HTML, not for
XHTML. In general, this media type is NOT suitable for XHTML."
This patch makes gitweb use content negotiation to conservatively send
pages as Content-Type 'application/xhtml+xml' when the user agent
explicitly claims to support it.
It falls back to 'text/html' even if the user agent appears to
implicitly support 'application/xhtml+xml' due to a '*/*' glob, working
around an insidious bug in Internet Explorer where sending the correct
media type prevents the page from being displayed.
Signed-off-by: Alp Toker <alp@atoker.com>
---
gitweb/gitweb.cgi | 14 ++++++++++++--
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.cgi b/gitweb/gitweb.cgi
index 2e87de4..bd9b9de 100755
--- a/gitweb/gitweb.cgi
+++ b/gitweb/gitweb.cgi
@@ -293,7 +293,17 @@ sub git_header_html {
}
}
}
- print $cgi->header(-type=>'text/html', -charset => 'utf-8', -status=> $status, -expires => $expires);
+ my $content_type;
+ # require explicit support from the UA if we are to send the page as
+ # 'application/xhtml+xml', otherwise send it as plain old 'text/html'.
+ # we have to do this because MSIE sometimes globs '*/*', pretending to
+ # support xhtml+xml but choking when it gets what it asked for.
+ if ($cgi->http('HTTP_ACCEPT') =~ m/(,|;|\s|^)application\/xhtml\+xml(,|;|\s|$)/ && $cgi->Accept('application/xhtml+xml') != 0) {
+ $content_type = 'application/xhtml+xml';
+ } else {
+ $content_type = 'text/html';
+ }
+ print $cgi->header(-type=>$content_type, -charset => 'utf-8', -status=> $status, -expires => $expires);
print <<EOF;
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
@@ -301,7 +311,7 @@ sub git_header_html {
<!-- git web interface v$version, (C) 2005-2006, Kay Sievers <kay.sievers\@vrfy.org>, Christian Gierke -->
<!-- git core binaries version $git_version -->
<head>
-<meta http-equiv="content-type" content="text/html; charset=utf-8"/>
+<meta http-equiv="content-type" content="$content_type; charset=utf-8"/>
<meta name="robots" content="index, nofollow"/>
<title>$title</title>
<link rel="stylesheet" type="text/css" href="$stylesheet"/>
--
1.4.1.g97c7-dirty
^ permalink raw reply related
* [PATCH] gitweb: Use the git binary in the search path by default
From: Alp Toker @ 2006-07-11 10:19 UTC (permalink / raw)
To: git
In-Reply-To: <1152613179634-git-send-email-alp@atoker.com>
Introduce a sensible default for the location of the git binary used by
gitweb. This means one less option to configure when deploying gitweb if
git is in the search path.
This patch also makes invocations of core git commands go through the
'git' binary itself, which might help system administrators lock down
their CGI environment for security.
Signed-off-by: Alp Toker <alp@atoker.com>
---
gitweb/gitweb.cgi | 61 ++++++++++++++++++++++++-----------------------------
1 files changed, 28 insertions(+), 33 deletions(-)
diff --git a/gitweb/gitweb.cgi b/gitweb/gitweb.cgi
index b12417b..0bb46b9 100755
--- a/gitweb/gitweb.cgi
+++ b/gitweb/gitweb.cgi
@@ -22,20 +22,15 @@ our $my_url = $cgi->url();
our $my_uri = $cgi->url(-absolute => 1);
our $rss_link = "";
-# location of the git-core binaries
-our $gitbin = "/usr/bin";
+# core git binary to use, optionally specified as an absolute path
+our $GIT = "git";
# absolute fs-path which will be prepended to the project path
#our $projectroot = "/pub/scm";
our $projectroot = "/home/kay/public_html/pub/scm";
-# version of the git-core binaries
-our $git_version = qx($gitbin/git --version);
-if ($git_version =~ m/git version (.*)$/) {
- $git_version = $1;
-} else {
- $git_version = "unknown";
-}
+# version of the core git binary
+our $git_version = qx($GIT --version) =~ m/git version (.*)$/ ? $1 : "unknown";
# location for temporary files needed for diffs
our $git_temp = "/tmp/gitweb";
@@ -391,7 +386,7 @@ sub die_error {
sub git_get_type {
my $hash = shift;
- open my $fd, "-|", "$gitbin/git-cat-file -t $hash" or return;
+ open my $fd, "-|", "$GIT cat-file -t $hash" or return;
my $type = <$fd>;
close $fd or return;
chomp $type;
@@ -403,7 +398,7 @@ sub git_read_head {
my $oENV = $ENV{'GIT_DIR'};
my $retval = undef;
$ENV{'GIT_DIR'} = "$projectroot/$project";
- if (open my $fd, "-|", "$gitbin/git-rev-parse", "--verify", "HEAD") {
+ if (open my $fd, "-|", $GIT, "rev-parse", "--verify", "HEAD") {
my $head = <$fd>;
close $fd;
if (defined $head && $head =~ /^([0-9a-fA-F]{40})$/) {
@@ -443,7 +438,7 @@ sub git_read_tag {
my %tag;
my @comment;
- open my $fd, "-|", "$gitbin/git-cat-file tag $tag_id" or return;
+ open my $fd, "-|", "$GIT cat-file tag $tag_id" or return;
$tag{'id'} = $tag_id;
while (my $line = <$fd>) {
chomp $line;
@@ -515,7 +510,7 @@ sub git_read_commit {
@commit_lines = @$commit_text;
} else {
$/ = "\0";
- open my $fd, "-|", "$gitbin/git-rev-list --header --parents --max-count=1 $commit_id" or return;
+ open my $fd, "-|", "$GIT rev-list --header --parents --max-count=1 $commit_id" or return;
@commit_lines = split '\n', <$fd>;
close $fd or return;
$/ = "\n";
@@ -613,7 +608,7 @@ sub git_diff_print {
if (defined $from) {
$from_tmp = "$git_temp/gitweb_" . $$ . "_from";
open my $fd2, "> $from_tmp";
- open my $fd, "-|", "$gitbin/git-cat-file blob $from";
+ open my $fd, "-|", "$GIT cat-file blob $from";
my @file = <$fd>;
print $fd2 @file;
close $fd2;
@@ -624,7 +619,7 @@ sub git_diff_print {
if (defined $to) {
$to_tmp = "$git_temp/gitweb_" . $$ . "_to";
open my $fd2, "> $to_tmp";
- open my $fd, "-|", "$gitbin/git-cat-file blob $to";
+ open my $fd, "-|", "$GIT cat-file blob $to";
my @file = <$fd>;
print $fd2 @file;
close $fd2;
@@ -843,7 +838,7 @@ sub git_get_project_config {
$key =~ s/^gitweb\.//;
return if ($key =~ m/\W/);
- my $val = qx($gitbin/git-repo-config --get gitweb.$key);
+ my $val = qx($GIT repo-config --get gitweb.$key);
return ($val);
}
@@ -1065,7 +1060,7 @@ sub git_summary {
"<tr><td>owner</td><td>$owner</td></tr>\n" .
"<tr><td>last change</td><td>$cd{'rfc2822'}</td></tr>\n" .
"</table>\n";
- open my $fd, "-|", "$gitbin/git-rev-list --max-count=17 " . git_read_head($project) or die_error(undef, "Open failed.");
+ open my $fd, "-|", "$GIT rev-list --max-count=17 " . git_read_head($project) or die_error(undef, "Open failed.");
my (@revlist) = map { chomp; $_ } <$fd>;
close $fd;
print "<div>\n" .
@@ -1253,7 +1248,7 @@ sub git_blame {
$hash = git_get_hash_by_path($hash_base, $file_name, "blob")
or die_error(undef, "Error lookup file.");
}
- open ($fd, "-|", "$gitbin/git-annotate", '-l', '-t', '-r', $file_name, $hash_base)
+ open ($fd, "-|", $GIT, "annotate", '-l', '-t', '-r', $file_name, $hash_base)
or die_error(undef, "Open failed.");
git_header_html();
print "<div class=\"page_nav\">\n" .
@@ -1448,7 +1443,7 @@ sub git_get_hash_by_path {
my $tree = $base;
my @parts = split '/', $path;
while (my $part = shift @parts) {
- open my $fd, "-|", "$gitbin/git-ls-tree $tree" or die_error(undef, "Open git-ls-tree failed.");
+ open my $fd, "-|", "$GIT ls-tree $tree" or die_error(undef, "Open git-ls-tree failed.");
my (@entries) = map { chomp; $_ } <$fd>;
close $fd or return undef;
foreach my $line (@entries) {
@@ -1535,7 +1530,7 @@ sub git_blob_plain_mimetype {
sub git_blob_plain {
my $type = shift;
- open my $fd, "-|", "$gitbin/git-cat-file blob $hash" or die_error("Couldn't cat $file_name, $hash");
+ open my $fd, "-|", "$GIT cat-file blob $hash" or die_error("Couldn't cat $file_name, $hash");
$type ||= git_blob_plain_mimetype($fd, $file_name);
@@ -1562,7 +1557,7 @@ sub git_blob {
$hash = git_get_hash_by_path($base, $file_name, "blob") || die_error(undef, "Error lookup file.");
}
my $have_blame = git_get_project_config_bool ('blame');
- open my $fd, "-|", "$gitbin/git-cat-file blob $hash" or die_error(undef, "Open failed.");
+ open my $fd, "-|", "$GIT cat-file blob $hash" or die_error(undef, "Open failed.");
my $mimetype = git_blob_plain_mimetype($fd, $file_name);
if ($mimetype !~ m/^text\//) {
close $fd;
@@ -1628,7 +1623,7 @@ sub git_tree {
}
}
$/ = "\0";
- open my $fd, "-|", "$gitbin/git-ls-tree -z $hash" or die_error(undef, "Open git-ls-tree failed.");
+ open my $fd, "-|", "$GIT ls-tree -z $hash" or die_error(undef, "Open git-ls-tree failed.");
chomp (my (@entries) = <$fd>);
close $fd or die_error(undef, "Reading tree failed.");
$/ = "\n";
@@ -1711,7 +1706,7 @@ # " | " . $cgi->a({-href => "$my
sub git_rss {
# http://www.notestips.com/80256B3A007F2692/1/NAMO5P9UPQ
- open my $fd, "-|", "$gitbin/git-rev-list --max-count=150 " . git_read_head($project) or die_error(undef, "Open failed.");
+ open my $fd, "-|", "$GIT rev-list --max-count=150 " . git_read_head($project) or die_error(undef, "Open failed.");
my (@revlist) = map { chomp; $_ } <$fd>;
close $fd or die_error(undef, "Reading rev-list failed.");
print $cgi->header(-type => 'text/xml', -charset => 'utf-8');
@@ -1731,7 +1726,7 @@ sub git_rss {
last;
}
my %cd = date_str($co{'committer_epoch'});
- open $fd, "-|", "$gitbin/git-diff-tree -r $co{'parent'} $co{'id'}" or next;
+ open $fd, "-|", "$GIT diff-tree -r $co{'parent'} $co{'id'}" or next;
my @difftree = map { chomp; $_ } <$fd>;
close $fd or next;
print "<item>\n" .
@@ -1819,7 +1814,7 @@ sub git_log {
" | " . $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=tree;h=$hash;hb=$hash")}, "tree") . "<br/>\n";
my $limit = sprintf("--max-count=%i", (100 * ($page+1)));
- open my $fd, "-|", "$gitbin/git-rev-list $limit $hash" or die_error(undef, "Open failed.");
+ open my $fd, "-|", "$GIT rev-list $limit $hash" or die_error(undef, "Open failed.");
my (@revlist) = map { chomp; $_ } <$fd>;
close $fd;
@@ -1910,7 +1905,7 @@ sub git_commit {
$root = " --root";
$parent = "";
}
- open my $fd, "-|", "$gitbin/git-diff-tree -r -M $root $parent $hash" or die_error(undef, "Open failed.");
+ open my $fd, "-|", "$GIT diff-tree -r -M $root $parent $hash" or die_error(undef, "Open failed.");
@difftree = map { chomp; $_ } <$fd>;
close $fd or die_error(undef, "Reading diff-tree failed.");
@@ -2152,7 +2147,7 @@ sub git_commitdiff {
if (!defined $hash_parent) {
$hash_parent = $co{'parent'};
}
- open my $fd, "-|", "$gitbin/git-diff-tree -r $hash_parent $hash" or die_error(undef, "Open failed.");
+ open my $fd, "-|", "$GIT diff-tree -r $hash_parent $hash" or die_error(undef, "Open failed.");
my (@difftree) = map { chomp; $_ } <$fd>;
close $fd or die_error(undef, "Reading diff-tree failed.");
@@ -2242,14 +2237,14 @@ sub git_commitdiff {
sub git_commitdiff_plain {
mkdir($git_temp, 0700);
- open my $fd, "-|", "$gitbin/git-diff-tree -r $hash_parent $hash" or die_error(undef, "Open failed.");
+ open my $fd, "-|", "$GIT diff-tree -r $hash_parent $hash" or die_error(undef, "Open failed.");
my (@difftree) = map { chomp; $_ } <$fd>;
close $fd or die_error(undef, "Reading diff-tree failed.");
# try to figure out the next tag after this commit
my $tagname;
my $refs = read_info_ref("tags");
- open $fd, "-|", "$gitbin/git-rev-list HEAD";
+ open $fd, "-|", "$GIT rev-list HEAD";
chomp (my (@commits) = <$fd>);
close $fd;
foreach my $commit (@commits) {
@@ -2320,7 +2315,7 @@ sub git_history {
print "<div class=\"page_path\"><b>/" . esc_html($file_name) . "</b><br/></div>\n";
open my $fd, "-|",
- "$gitbin/git-rev-list --full-history $hash -- \'$file_name\'";
+ "$GIT rev-list --full-history $hash -- \'$file_name\'";
print "<table cellspacing=\"0\">\n";
my $alternate = 0;
while (my $line = <$fd>) {
@@ -2407,7 +2402,7 @@ sub git_search {
my $alternate = 0;
if ($commit_search) {
$/ = "\0";
- open my $fd, "-|", "$gitbin/git-rev-list --header --parents $hash" or next;
+ open my $fd, "-|", "$GIT rev-list --header --parents $hash" or next;
while (my $commit_text = <$fd>) {
if (!grep m/$searchtext/i, $commit_text) {
next;
@@ -2457,7 +2452,7 @@ sub git_search {
if ($pickaxe_search) {
$/ = "\n";
- open my $fd, "-|", "$gitbin/git-rev-list $hash | $gitbin/git-diff-tree -r --stdin -S\'$searchtext\'";
+ open my $fd, "-|", "$GIT rev-list $hash | $GIT diff-tree -r --stdin -S\'$searchtext\'";
undef %co;
my @files;
while (my $line = <$fd>) {
@@ -2528,7 +2523,7 @@ sub git_shortlog {
" | " . $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=tree;h=$hash;hb=$hash")}, "tree") . "<br/>\n";
my $limit = sprintf("--max-count=%i", (100 * ($page+1)));
- open my $fd, "-|", "$gitbin/git-rev-list $limit $hash" or die_error(undef, "Open failed.");
+ open my $fd, "-|", "$GIT rev-list $limit $hash" or die_error(undef, "Open failed.");
my (@revlist) = map { chomp; $_ } <$fd>;
close $fd;
--
1.4.1.g97c7-dirty
^ permalink raw reply related
* [PATCH] gitweb: Include a site name in page titles
From: Alp Toker @ 2006-07-11 10:19 UTC (permalink / raw)
To: git
In-Reply-To: <11526131781900-git-send-email-alp@atoker.com>
Tip Of The Day:
<title>: the most important element of a quality Web page.
This helps users tell one 'git' bookmark apart from the other in their
browser and improves the indexing of gitweb sites in Web search engines.
Signed-off-by: Alp Toker <alp@atoker.com>
---
gitweb/gitweb.cgi | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.cgi b/gitweb/gitweb.cgi
index bd9b9de..b12417b 100755
--- a/gitweb/gitweb.cgi
+++ b/gitweb/gitweb.cgi
@@ -46,6 +46,9 @@ if (! -d $git_temp) {
# target of the home link on top of all pages
our $home_link = $my_uri;
+# name of your site or organization to appear in page titles
+our $site_name = "Untitled";
+
# html text to include at home page
our $home_text = "indextext.html";
@@ -280,7 +283,7 @@ sub git_header_html {
my $status = shift || "200 OK";
my $expires = shift;
- my $title = "git";
+ my $title = "$site_name git";
if (defined $project) {
$title .= " - $project";
if (defined $action) {
@@ -1770,7 +1773,7 @@ sub git_opml {
print "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n".
"<opml version=\"1.0\">\n".
"<head>".
- " <title>Git OPML Export</title>\n".
+ " <title>$site_name Git OPML Export</title>\n".
"</head>\n".
"<body>\n".
"<outline text=\"git RSS feeds\">\n";
--
1.4.1.g97c7-dirty
^ permalink raw reply related
* [PATCH] Install built-ins as symlinks
From: Alp Toker @ 2006-07-11 10:19 UTC (permalink / raw)
To: git
In-Reply-To: <11526131792773-git-send-email-alp@atoker.com>
Doing this now will save headache in the long run, avoiding mismatched
versions of installed utilities and dangling copies of removed or
renamed git commands that still appear to work. It also makes screwups
when packaging git or making system backups less likely.
BusyBox has been doing it this way for years.
Signed-off-by: Alp Toker <alp@atoker.com>
---
Makefile | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index 5b7bac8..cb5a5cc 100644
--- a/Makefile
+++ b/Makefile
@@ -538,7 +538,7 @@ git$X: git.c common-cmds.h $(BUILTIN_OBJ
builtin-help.o: common-cmds.h
$(BUILT_INS): git$X
- rm -f $@ && ln git$X $@
+ ln -sf git$X $@
common-cmds.h: Documentation/git-*.txt
./generate-cmdlist.sh > $@+
@@ -748,7 +748,7 @@ install: all
cp '$(DESTDIR_SQ)$(bindir_SQ)/git$X' \
'$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X'; \
fi
- $(foreach p,$(BUILT_INS), rm -f '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' && ln '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X' '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' ;)
+ $(foreach p,$(BUILT_INS), ln -sf 'git$X' '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' ;)
install-doc:
$(MAKE) -C Documentation install
--
1.4.1.g97c7-dirty
^ permalink raw reply related
* Re: [PATCH] Install built-ins as symlinks
From: Andreas Ericsson @ 2006-07-11 11:15 UTC (permalink / raw)
To: Alp Toker; +Cc: git
In-Reply-To: <11526131792377-git-send-email-alp@atoker.com>
Alp Toker wrote:
> Doing this now will save headache in the long run, avoiding mismatched
> versions of installed utilities and dangling copies of removed or
> renamed git commands that still appear to work. It also makes screwups
> when packaging git or making system backups less likely.
>
> BusyBox has been doing it this way for years.
>
Git has been doing it for a couple of months, although it uses hardlinks
instead of symlinks. Hardlinks are slightly faster and actually consume
a little less hard-disk space, although the differences are so small you
won't notice it unless you do several thousand invocations.
>
> $(BUILT_INS): git$X
> - rm -f $@ && ln git$X $@
> + ln -sf git$X $@
>
The -f option to ln is not very portable, hence the "rm && ln" construct.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] gitweb: Include a site name in page titles
From: Martin Langhoff @ 2006-07-11 11:48 UTC (permalink / raw)
To: Alp Toker; +Cc: git
In-Reply-To: <1152613179634-git-send-email-alp@atoker.com>
> +# name of your site or organization to appear in page titles
> +our $site_name = "Untitled";
I generally agree, but as a default, $ENV{SERVER_NAME} should be better.
cheers,
martin
^ 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