* Re: Cogito: cg-clone doesn't like packed tag objects
From: Linus Torvalds @ 2005-09-27 18:04 UTC (permalink / raw)
To: Ryan Anderson; +Cc: Petr Baudis, H. Peter Anvin, Git Mailing List
In-Reply-To: <20050927173445.GC23034@mythryan2.michonline.com>
On Tue, 27 Sep 2005, Ryan Anderson wrote:
>
> $ cat .git/refs/tags/v2.6.13-rc4
> 7eab951de91d95875ba34ec4c599f37e1208db93
> $ git-rev-parse v2.6.13-rc4
> 7eab951de91d95875ba34ec4c599f37e1208db93
> $ git-rev-parse v2.6.13-rc4^0
> 63953523341bcafe5928bf6e99bffd7db94b471e
> $ git-rev-parse 63953523341bcafe5928bf6e99bffd7db94b471e^0
> 63953523341bcafe5928bf6e99bffd7db94b471e
The point being that if you want to test whether you have the thing the
tag _points_ to, you should verify it.
And that's where the "--verify" flag comes in:
[torvalds@g5 linux]$ git-rev-parse v2.6.11^0 ; echo $?
error: Object 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c is a tree, not a commit
v2.6.11^0
0
and if the object the tag points to didn't exist at _all_ in your object
store, you'd have silently gotten
[torvalds@g5 linux]$ git-rev-parse v2.6.11^0 ; echo $?
v2.6.11^0
0
but if you used "--verify", you'd have at least gotten
[torvalds@g5 linux]$ git-rev-parse --verify v2.6.11^0 ; echo $?
fatal: Needed a single revision
1
which is what you want, I thought.
Linus
^ permalink raw reply
* Re: hared GIT repos (was Re: rsync deprecated but promoted?)
From: A Large Angry SCM @ 2005-09-27 18:36 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: git
In-Reply-To: <pan.2005.09.27.06.35.35.834134@smurf.noris.de>
Matthias Urlichs wrote:
> Hi, Petr Baudis wrote:
>
>>The thing is, rsync is bad - it will happily put
>>duplicate, redundant, and especially unwanted data to your repository,
>>especially when the shared GIT repositories happen.
>
> Speaking of which -- is anybody working on that one?
>
> I find myself in need of a multiuser shared repository that cannot
> be corrupted (i.e. I want to prevent the users from removing objects,
> and replacing a ref with something that is not a child of the sha1 that's
> already there should also be prevented).
>
Yes. Actually just the protocol spec so far. Although, progress has been
interrupted by the process of moving to the SoCal area from Fla.
^ permalink raw reply
* Re: Cogito: cg-clone doesn't like packed tag objects
From: Junio C Hamano @ 2005-09-27 18:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, Tom Prince, git
In-Reply-To: <Pine.LNX.4.58.0509271020530.3308@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Tue, 27 Sep 2005, Junio C Hamano wrote:
>>
>> This is a bit hard and needs some thinking to do cleanly,
>> because what is in info/refs is what is sent from the publisher
>> side over git-native protocol at the beginning of the handshake,
>> and it is not easy to add that to git-native protocol cleanly
>> and backward-compatibly (I think I know how without breaking
>> existing clients, but it is not clean).
>
> Argh.
>
> "git-upload-pack" very much on purpose never sends partial object stores:
> it really doesn't want to send a tag-object for you to even _look_ at
> unless it also sends all the objects that you are missing that the tag
> refers to.
>
> I'd really be much happier with the tag fetching being separate.
What Pasky wants to do, which I misunderstood first and gave
essentially the same response to, is to help this senario:
User tracks git.git#master and nothing else, i.e. she pulls
from my master branch from time to time. The tool notices
that I tagged a commit on the master branch (not necessarily
the tip at the time of pulling) with v0.99.8 tag, which she
has not have, and fetches v0.99.8 tag and stores it under
.git/refs/. Currently Cogito does not let her specify
where on the receiving end to place that tag and always
places it in .git/refs/tags/v0.99.8, but that can be fixed
later.
The current ls-remote (or underlying fetch-pack protocol) does
not help this because the SHA1 given to Cogito is the object
name of the tag, and without fetching the tag object and looking
at what it refers to, Pasky cannot say "Oh, this new v0.99.8 tag
is the commit on the branch being tracked".
The protocol extension I had in mind, which I said is not clean,
is from upload_pack(), in addition to the existing send_ref()
call which sends "object-name refname" list like this:
4899334e96a076bb8780968c5075b214aa80fab9 HEAD
d5bc7eecbbb0b9f6122708bf5cd62f78ebdaafd8 refs/heads/maint
3cc35e29ec252d0dca1139106fbaa70cb9ad6ef1 refs/heads/master
4899334e96a076bb8780968c5075b214aa80fab9 refs/heads/pu
348c4c66dacb1810a9bcd592e72f98a465233488 refs/heads/rc
0918385dbd9656cab0d1d81ba7453d49bbc16250 refs/tags/junio-gpg-pub
d6602ec5194c87b0fc87103ca4d67251c76f233a refs/tags/v0.99
f25a265a342aed6041ab0cc484224d9ca54b6f41 refs/tags/v0.99.1
...
we could send phony entries like this:
b92c9c07fe2d0d89c4f692573583c4753b5355d2 deref/tags/junio-gpg-pub
a3eb250f996bf5e12376ec88622c4ccaabf20ea8 deref/tags/v0.99
78d9d414123ad6f4f522ffecbcd9e4a7562948fd deref/tags/v0.99.1
These phony entries tell the receiver what the tags eventually
resolve to. Pasky could use this to see if he has the named
object from the usual fetch path, and if he finds matches,
ask git-fetch-pack to get them.
We would need to teach git-clone and git-fetch to ignore deref/
if they do not already do so.
^ permalink raw reply
* Re: Cogito: cg-clone doesn't like packed tag objects
From: Linus Torvalds @ 2005-09-27 21:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, Tom Prince, git
In-Reply-To: <7v64sm1hp3.fsf@assigned-by-dhcp.cox.net>
On Tue, 27 Sep 2005, Junio C Hamano wrote:
>
> The protocol extension I had in mind, which I said is not clean,
> is from upload_pack(), in addition to the existing send_ref()
> call which sends "object-name refname" list like this:
>
> 4899334e96a076bb8780968c5075b214aa80fab9 HEAD
...
>
> we could send phony entries like this:
>
> b92c9c07fe2d0d89c4f692573583c4753b5355d2 deref/tags/junio-gpg-pub
> a3eb250f996bf5e12376ec88622c4ccaabf20ea8 deref/tags/v0.99
> 78d9d414123ad6f4f522ffecbcd9e4a7562948fd deref/tags/v0.99.1
Yes, it would work, but I really think that there's no downside to just
having a
git fetch --tags <dest>
since that's just a few lines of trivial code, with no special cases.
Otherwise:
> We would need to teach git-clone and git-fetch to ignore deref/
> if they do not already do so.
in general, it's just a really ugly special case, I think.
Linus
^ permalink raw reply
* Re: Cogito: cg-clone doesn't like packed tag objects
From: Linus Torvalds @ 2005-09-27 21:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, Tom Prince, git
In-Reply-To: <Pine.LNX.4.58.0509271414000.3308@g5.osdl.org>
On Tue, 27 Sep 2005, Linus Torvalds wrote:
>
> Yes, it would work, but I really think that there's no downside to just
> having a
>
> git fetch --tags <dest>
>
> since that's just a few lines of trivial code, with no special cases.
Btw, there are upsides too. Remember how confused people were about your
very own v0.99.7a-d releases? They are _not_ on your main path, so those
tags wouldn't have been picked up even if Petr did his "pick up tags to
stuff you merge automatically" thing.
In fact, if you'd add "--tags" as some kind of automated flag in the
.git/remote/ file, then doing a "git fetch origin" could automatically
fetch tags by default, _without_ having the mistake of fetching them in
general (it probably _does_ make sense to track tags from the origin,
since you get the ones the origin had at "clone" time anyway).
Linus
^ permalink raw reply
* Re: Cogito: cg-clone doesn't like packed tag objects
From: Junio C Hamano @ 2005-09-27 22:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, Tom Prince, git
In-Reply-To: <Pine.LNX.4.58.0509271414000.3308@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Yes, it would work, but I really think that there's no downside to just
> having a
>
> git fetch --tags <dest>
>
> since that's just a few lines of trivial code, with no special cases.
I do not oppose that idea. I was just trying to point out that
'git fetch --tags' does not solve what Pasky wants to do -- in
his ideal world, people track branches, and tags that refer to
objects that are on those tracked branches are automatically
fetched; at the same time tags irrelevant to the tracked
branches are not fetched at all. 'git fetch --tags' would
require the user to slurp in objects on branches she is not
interested in.
^ permalink raw reply
* Re: [PATCH 2/3] Support for partial HTTP transfers
From: Junio C Hamano @ 2005-09-27 22:24 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: git
In-Reply-To: <20050927171912.GC1377@reactrix.com>
Nick Hengeveld <nickh@reactrix.com> writes:
> On Tue, Sep 27, 2005 at 10:09:49AM -0700, Junio C Hamano wrote:
>
>> True. What I meant by "interesting" is that two is reading from
>> what one is writing.
>
> Excellent point. Given the potential for problems related to this
> issue or to compressed representation, would it make sense to enable
> partial transfers via a command-line option and leave the feature
> disabled by default?
Here is what I think. Multiple transfers at the same time, if
it becomes problem in pratcice, should be prevented at the upper
layer anyway, so this "interesting" problem is a moot point. So
I'd say let's not worry about that.
Doing partial transfer support for packs and indices would be
more useful addition to your code than dealing with the above --
packs are much bigger than individual objects and would get much
bigger benefit from restartable download.
Different compressed representation is just a theoretical
curiosity and we do not know if it is a problem in practice. As
long as you can detect the situation and die, it would be OK, I
think.
^ permalink raw reply
* Re: [PATCH] Fix default pull not to do an unintended Octopus.
From: Junio C Hamano @ 2005-09-27 22:24 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200509271635.12907.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> On Tuesday 27 September 2005 14:54, you wrote:
>> Yes. I'm actually inclined to keep this setup, simply because it is
>>
>> * easy
>> * simple
>> * sufficient in most of the cases
>
> I would almost say: sufficient for all cases.
> The .git/remotes stuff is about providing a shortcut for remote
> repositories and about defaults for this repository.
> I am not really sure this is needed, and this second use of a name
> (additionally to head names) can be confusing.
I suspect you've never played with remote repositories with 47
different heads.
^ permalink raw reply
* Re: [PATCH 0/3] http-fetch enhancements
From: Nick Hengeveld @ 2005-09-28 2:39 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Nick Hengeveld, git
In-Reply-To: <Pine.LNX.4.63.0509261823590.23242@iabervon.org>
On Mon, Sep 26, 2005 at 03:29:02PM -0700, Daniel Barkalow wrote:
> If you happen to know how to have curl do multiple simultaneous downloads,
> that would be a big performance win, and I should be able to explain how
> to get this to work. I haven't gotten around to learning libcurl well
> enough to do the flow control.
The curl multi interface looks pretty straightforward. What did you have
in mind as far as which requests would be running concurrently and how they
would need to be limited?
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* [PATCH] Use git-update-ref in scripts.
From: Junio C Hamano @ 2005-09-28 2:45 UTC (permalink / raw)
To: Git Mailing List; +Cc: Linus Torvalds
In-Reply-To: <Pine.LNX.4.58.0509251153090.3308@g5.osdl.org>
This uses the git-update-ref command in scripts for safer updates.
Also places where we used to read HEAD ref by using "cat" were fixed
to use git-rev-parse. This will matter when we start using symbolic
references.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* Requesting extra sets of eyeballs from the list for stupid
mistakes.
git-applypatch.sh | 5 +++--
git-commit.sh | 4 +++-
git-fetch.sh | 34 ++++++++++++++++++----------------
git-merge.sh | 9 +++++----
git-octopus.sh | 2 +-
git-pull.sh | 6 +++---
git-rebase.sh | 5 +++--
git-reset.sh | 2 +-
git-resolve.sh | 4 ++--
9 files changed, 39 insertions(+), 32 deletions(-)
7bae83d5754a1afb8e64f9de17f1dc34d0022f0a
diff --git a/git-applypatch.sh b/git-applypatch.sh
--- a/git-applypatch.sh
+++ b/git-applypatch.sh
@@ -108,9 +108,10 @@ fi
tree=$(git-write-tree) || exit 1
echo Wrote tree $tree
-commit=$(git-commit-tree $tree -p $(cat "$GIT_DIR"/HEAD) < "$final") || exit 1
+parent=$(git-rev-parse --verify HEAD) &&
+commit=$(git-commit-tree $tree -p $parent <"$final") || exit 1
echo Committed: $commit
-echo $commit > "$GIT_DIR"/HEAD
+git-update-ref HEAD $commit $parent || exit
if test -x "$GIT_DIR"/hooks/post-applypatch
then
diff --git a/git-commit.sh b/git-commit.sh
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -159,7 +159,9 @@ if [ ! -r "$GIT_DIR/HEAD" ]; then
exit 1
fi
PARENTS=""
+ current=
else
+ current=$(git-rev-parse --verify HEAD)
if [ -f "$GIT_DIR/MERGE_HEAD" ]; then
PARENTS="-p HEAD "`sed -e 's/^/-p /' "$GIT_DIR/MERGE_HEAD"`
fi
@@ -220,7 +222,7 @@ if test -s .cmitchk
then
tree=$(git-write-tree) &&
commit=$(cat .cmitmsg | git-commit-tree $tree $PARENTS) &&
- echo $commit > "$GIT_DIR/HEAD" &&
+ git-update-ref HEAD $commit $current &&
rm -f -- "$GIT_DIR/MERGE_HEAD"
else
echo >&2 "* no commit message? aborting commit."
diff --git a/git-fetch.sh b/git-fetch.sh
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -105,14 +105,16 @@ fast_forward_local () {
else
echo >&2 "* $1: storing $3"
fi
- echo "$2" >"$GIT_DIR/$1" ;;
+ git-update-ref "$1" "$2"
+ ;;
refs/heads/*)
- # NEEDSWORK: use the same cmpxchg protocol here.
- echo "$2" >"$GIT_DIR/$1.lock"
- if test -f "$GIT_DIR/$1"
+ # $1 is the ref being updated.
+ # $2 is the new value for the ref.
+ local=$(git-rev-parse --verify "$1^0" 2>/dev/null)
+ if test "$local"
then
- local=$(git-rev-parse --verify "$1^0") &&
+ # Require fast-forward.
mb=$(git-merge-base "$local" "$2") &&
case "$2,$mb" in
$local,*)
@@ -120,34 +122,34 @@ fast_forward_local () {
;;
*,$local)
echo >&2 "* $1: fast forward to $3"
+ git-update-ref "$1" "$2" "$local"
;;
*)
false
;;
esac || {
echo >&2 "* $1: does not fast forward to $3;"
- case "$force,$single_force" in
- t,* | *,t)
+ case ",$force,$single_force," in
+ *,t,*)
echo >&2 " forcing update."
+ git-update-ref "$1" "$2" "$local"
;;
*)
- mv "$GIT_DIR/$1.lock" "$GIT_DIR/$1.remote"
- echo >&2 " leaving it in '$1.remote'"
+ echo >&2 " not updating."
;;
esac
}
else
- echo >&2 "* $1: storing $3"
+ echo >&2 "* $1: storing $3"
+ git-update-ref "$1" "$2"
fi
- test -f "$GIT_DIR/$1.lock" &&
- mv "$GIT_DIR/$1.lock" "$GIT_DIR/$1"
;;
esac
}
case "$update_head_ok" in
'')
- orig_head=$(cat "$GIT_DIR/HEAD" 2>/dev/null)
+ orig_head=$(git-rev-parse --verify HEAD 2>/dev/null)
;;
esac
@@ -184,7 +186,7 @@ do
rsync://*)
TMP_HEAD="$GIT_DIR/TMP_HEAD"
rsync -L -q "$remote/$remote_name" "$TMP_HEAD" || exit 1
- head=$(git-rev-parse TMP_HEAD)
+ head=$(git-rev-parse --verify TMP_HEAD)
rm -f "$TMP_HEAD"
test "$rsync_slurped_objects" || {
rsync -av --ignore-existing --exclude info \
@@ -261,10 +263,10 @@ case ",$update_head_ok,$orig_head," in
*,, | t,* )
;;
*)
- curr_head=$(cat "$GIT_DIR/HEAD" 2>/dev/null)
+ curr_head=$(git-rev-parse --verify HEAD 2>/dev/null)
if test "$curr_head" != "$orig_head"
then
- echo "$orig_head" >$GIT_DIR/HEAD
+ git-update-ref HEAD "$orig_head"
die "Cannot fetch into the current branch."
fi
;;
diff --git a/git-merge.sh b/git-merge.sh
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -114,8 +114,9 @@ case "$#,$common" in
# Again the most common case of merging one remote.
echo "Updating from $head to $1."
git-update-index --refresh 2>/dev/null
- git-read-tree -u -m $head "$1" || exit 1
- git-rev-parse --verify "$1^0" > "$GIT_DIR/HEAD"
+ git-read-tree -u -m $head "$1" &&
+ new_head=$(git-rev-parse --verify "$1^0") &&
+ git-update-ref HEAD "$new_head" "$head" || exit 1
summary "$1"
dropsave
exit 0
@@ -218,9 +219,9 @@ then
do
parents="$parents -p $remote"
done
- result_commit=$(echo "$merge_msg" | git-commit-tree $result_tree $parents)
+ result_commit=$(echo "$merge_msg" | git-commit-tree $result_tree $parents) || exit
echo "Committed merge $result_commit, made by $wt_strategy."
- echo $result_commit >"$GIT_DIR/HEAD"
+ git-update-ref HEAD $result_commit $head
summary $result_commit
dropsave
exit 0
diff --git a/git-octopus.sh b/git-octopus.sh
--- a/git-octopus.sh
+++ b/git-octopus.sh
@@ -86,5 +86,5 @@ esac
result_commit=$(git-fmt-merge-msg <"$GIT_DIR/FETCH_HEAD" |
git-commit-tree $MRT $PARENT)
echo "Committed merge $result_commit"
-echo $result_commit >"$GIT_DIR"/HEAD
+git-update-ref HEAD $result_commit $head
git-diff-tree -p $head $result_commit | git-apply --stat
diff --git a/git-pull.sh b/git-pull.sh
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -6,10 +6,10 @@
. git-sh-setup || die "Not a git archive"
-orig_head=$(cat "$GIT_DIR/HEAD") || die "Pulling into a black hole?"
+orig_head=$(git-rev-parse --verify HEAD) || die "Pulling into a black hole?"
git-fetch --update-head-ok "$@" || exit 1
-curr_head=$(cat "$GIT_DIR/HEAD")
+curr_head=$(git-rev-parse --verify HEAD)
if test "$curr_head" != "$orig_head"
then
# The fetch involved updating the current branch.
@@ -38,4 +38,4 @@ case "$merge_head" in
esac
merge_name=$(git-fmt-merge-msg <"$GIT_DIR/FETCH_HEAD")
-git-resolve "$(cat "$GIT_DIR"/HEAD)" $merge_head "$merge_name"
+git-resolve "$curr_head" $merge_head "$merge_name"
diff --git a/git-rebase.sh b/git-rebase.sh
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -33,7 +33,8 @@ test "$different1$different2" = "" ||
die "Your working tree does not match $ours_symbolic."
git-read-tree -m -u $ours $upstream &&
-git-rev-parse --verify "$upstream^0" >"$GIT_DIR/HEAD" || exit
+new_head=$(git-rev-parse --verify "$upstream^0") &&
+git-update-ref HEAD "$new_head" || exit
tmp=.rebase-tmp$$
fail=$tmp-fail
@@ -50,7 +51,7 @@ do
continue ;;
esac
echo >&2 "* Applying: $msg"
- S=`cat "$GIT_DIR/HEAD"` &&
+ S=$(git-rev-parse --verify HEAD) &&
git-cherry-pick --replay $commit || {
echo >&2 "* Not applying the patch and continuing."
echo $commit >>$fail
diff --git a/git-reset.sh b/git-reset.sh
--- a/git-reset.sh
+++ b/git-reset.sh
@@ -60,7 +60,7 @@ then
else
rm -f "$GIT_DIR/ORIG_HEAD"
fi
-echo "$rev" >"$GIT_DIR/HEAD"
+git-update-ref HEAD "$rev"
case "$reset_type" in
--hard )
diff --git a/git-resolve.sh b/git-resolve.sh
--- a/git-resolve.sh
+++ b/git-resolve.sh
@@ -45,7 +45,7 @@ case "$common" in
"$head")
echo "Updating from $head to $merge."
git-read-tree -u -m $head $merge || exit 1
- echo $merge > "$GIT_DIR"/HEAD
+ git-update-ref HEAD "$merge"
git-diff-tree -p $head $merge | git-apply --stat
dropheads
exit 0
@@ -99,6 +99,6 @@ if [ $? -ne 0 ]; then
fi
result_commit=$(echo "$merge_msg" | git-commit-tree $result_tree -p $head -p $merge)
echo "Committed merge $result_commit"
-echo $result_commit > "$GIT_DIR"/HEAD
+git-update-ref HEAD "$result_commit"
git-diff-tree -p $head $result_commit | git-apply --stat
dropheads
^ permalink raw reply
* Re: [PATCH 0/3] http-fetch enhancements
From: Daniel Barkalow @ 2005-09-28 3:37 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: Nick Hengeveld, git
In-Reply-To: <20050928023947.GA385@reactrix.com>
On Tue, 27 Sep 2005, Nick Hengeveld wrote:
> On Mon, Sep 26, 2005 at 03:29:02PM -0700, Daniel Barkalow wrote:
>
> > If you happen to know how to have curl do multiple simultaneous downloads,
> > that would be a big performance win, and I should be able to explain how
> > to get this to work. I haven't gotten around to learning libcurl well
> > enough to do the flow control.
>
> The curl multi interface looks pretty straightforward. What did you have
> in mind as far as which requests would be running concurrently and how they
> would need to be limited?
The way fetch.c calls the functions, there's a prefetch() that indicates
that a given object is needed, and a fetch() that is responsible for
making sure the object is available when it returns (or returning an
error). It is arranged such that the same list of hashes is given to each
of the functions in the same order.
One method is to send requests in prefetch() and accept responses in
fetch(); this is what git-ssh-pull now does. This seems in practice to
lead to ~100 outstanding requests at the high point, which is great for
throughput, but I'm not sure how polite it is. IIRC, browsers tend to do
~4 simultaneous connections, or at least used to.
The other method is to keep track of what you're fetching, and block in
prefetch() if too many connections are in use until some connections are
free, or in fetch() if that is called before the download is complete.
Note that it should theoretically be possible to make additional requests
on the same connection, provided it's "keep alive", even before reading
the response, so long as the code is able to figure out what happened if
the server actually closes it (after the first request) instead of serving
the later ones.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* gitk: More vi like cursor move
From: Yasushi SHOJI @ 2005-09-28 3:32 UTC (permalink / raw)
To: git
Hello,
Just synced git and see that gitk now have vi like key binding.
however, IMHO, cursor move doesn't feel like vi.
If the attached patch make sense to people on the list, I'd like to
send formated email/patch to Paul.
regards,
--
yashi
diff --git a/gitk b/gitk
--- a/gitk
+++ b/gitk
@@ -497,9 +497,10 @@ proc makewindow {} {
bindkey n "selnextline 1"
bindkey z "goback"
bindkey x "goforw"
+ bindkey h "goback"
bindkey i "selnextline -1"
- bindkey k "selnextline 1"
- bindkey j "goback"
+ bindkey k "selnextline -1"
+ bindkey j "selnextline 1"
bindkey l "goforw"
bindkey b "$ctext yview scroll -1 pages"
bindkey d "$ctext yview scroll 18 units"
^ permalink raw reply
* [PATCH] Fix git-pull output message
From: Robert Watson @ 2005-09-28 10:02 UTC (permalink / raw)
To: git, Junio C Hamano
(git)$ git-pull
Fetching refs/heads/master from
http://www.kernel.org/pub/scm/git/git.git using http
* committish: 3cc35e29ec252d0dca1139106fbaa70cb9ad6ef1
branch 'master' of http://www.kernel.org/pub/scm/git/git
* refs/heads/origin: same as branch 'master' of
http://www.kernel.org/pub/scm/git/git
Already up-to-date. Yeeah!
Notice that the git.git directory is truncated. It seems the
intension is to truncate at the .git
directory level. The following patch fixes it.
diff --git a/git-fetch.sh b/git-fetch.sh
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -70,7 +70,7 @@ append_fetch_head () {
*)
note_="$remote_name of " ;;
esac
- remote_1_=$(expr "$remote_" : '\(.*\)\.git/*$') &&
+ remote_1_=$(expr "$remote_" : '\(.*/\)\.git/*$') &&
remote_="$remote_1_"
note_="$note_$remote_"
^ permalink raw reply
* Re: [PATCH] Fix git-pull output message
From: Junio C Hamano @ 2005-09-28 11:00 UTC (permalink / raw)
To: Robert Watson; +Cc: git
In-Reply-To: <72499e3b05092803027175bab0@mail.gmail.com>
Robert Watson <robert.oo.watson@gmail.com> writes:
> Notice that the git.git directory is truncated. It seems the
> intension is to truncate at the .git directory level.
c5434dead6a52a48c520dfa3d8ed24dc3673ab1a commit introduced this
behaviour, and we kept it ever since.
It may look a bit weird when it is applied to git.git/, but the
intention is to shorten the log message without losing much
information. ".../torvalds/linux-2.6.git" is similarly
shortened to ".../torvalds/linux-2.6".
You can see 'git log' output in the kernel repository and look
for commit log messages of merge commits, and notice all those
repository names with trailing ".git" stripped.
^ permalink raw reply
* Re: More Porcelains?
From: Vincent Hanquez @ 2005-09-28 11:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Nick Hengeveld
In-Reply-To: <7v64sn8hml.fsf_-_@assigned-by-dhcp.cox.net>
On Mon, Sep 26, 2005 at 05:43:46PM -0700, Junio C Hamano wrote:
> Now you made me curious.
>
> How many of you are working on your own Porcelains, announced or
> unannounced? I know about Cogito and StGIT ;-). In a distant
> past I have heard of something called JIT but I think it is now
> defunct. Matthias Urlichs said he is doing something with
> Python. Anybody else?
Hi Junio,
Well, I kinda work on one written in C using a libgit (using exec of git
executable for the moment) It doesn't do that much at the moment:
commiting, adding files, removing files.
At some point I'ld like to have a very integrated and easy to use
porcelain, but for now that's more a learning git by practice kind of
project.
Cheers,
--
Vincent Hanquez
^ permalink raw reply
* [PATCH] Make some needlessly global stuff static
From: Peter Hagervall @ 2005-09-28 12:04 UTC (permalink / raw)
To: junkio; +Cc: git
Insert 'static' where appropriate.
Signed-off-by: Peter Hagervall <hager@cs.umu.se>
---
fsck-objects.c | 4 ++--
http-fetch.c | 4 ++--
update-ref.c | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/fsck-objects.c b/fsck-objects.c
--- a/fsck-objects.c
+++ b/fsck-objects.c
@@ -30,7 +30,7 @@ static void objreport(struct object *obj
fputs("\n", stderr);
}
-int objerror(struct object *obj, const char *err, ...)
+static int objerror(struct object *obj, const char *err, ...)
{
va_list params;
va_start(params, err);
@@ -39,7 +39,7 @@ int objerror(struct object *obj, const c
return -1;
}
-int objwarning(struct object *obj, const char *err, ...)
+static int objwarning(struct object *obj, const char *err, ...)
{
va_list params;
va_start(params, err);
diff --git a/http-fetch.c b/http-fetch.c
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -26,7 +26,7 @@ struct alt_base
struct alt_base *next;
};
-struct alt_base *alt = NULL;
+static struct alt_base *alt = NULL;
static SHA_CTX c;
static z_stream stream;
@@ -345,7 +345,7 @@ static int fetch_pack(struct alt_base *r
return 0;
}
-int fetch_object(struct alt_base *repo, unsigned char *sha1)
+static int fetch_object(struct alt_base *repo, unsigned char *sha1)
{
char *hex = sha1_to_hex(sha1);
char *filename = sha1_file_name(sha1);
diff --git a/update-ref.c b/update-ref.c
--- a/update-ref.c
+++ b/update-ref.c
@@ -6,7 +6,7 @@ static const char git_update_ref_usage[]
#define MAXDEPTH 5
-const char *resolve_ref(const char *path, unsigned char *sha1)
+static const char *resolve_ref(const char *path, unsigned char *sha1)
{
int depth = MAXDEPTH, len;
char buffer[256];
^ permalink raw reply
* git cvsimport?
From: Wolfgang Denk @ 2005-09-28 12:40 UTC (permalink / raw)
To: git
I have problems importing a CVS repository:
-> git cvsimport -v -d :pserver:denx@cvs.semihalf.com:/cvs -C /home/git/duts duts
cvs_direct initialized to CVSROOT /cvs
cvs rlog: Logging duts
cvs rlog: Logging duts/core
NOTICE: used alternate strip path /home/cvs/duts/core/duts
DONE; creating master branch
cp: cannot stat `/home/git/duts/.git/refs/heads/origin': No such file or directory
usage: git-read-tree (<sha> | -m [-u | -i] <sha1> [<sha2> [<sha3>]])
checkout failed: 256
-> git --version
git version 0.99.7
Am I doing anything wrong here?
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Mandrell: "You know what I think?"
Doctor: "Ah, ah that's a catch question. With a brain your size you
don't think, right?"
- Dr. Who
^ permalink raw reply
* [PATCH] Fix git-add argument parsing
From: Timo Hirvonen @ 2005-09-28 14:27 UTC (permalink / raw)
To: junkio; +Cc: git
Complain if no arguments given instead of adding all files
to the index.
Signed-off-by: Timo Hirvonen <tihirvon@gmail.com>
---
git-add.sh | 44 ++++++++++++++++++++++++++++++--------------
1 files changed, 30 insertions(+), 14 deletions(-)
60d2803555831a9a9bfa2d97cec5ab2fbed1fb2c
diff --git a/git-add.sh b/git-add.sh
--- a/git-add.sh
+++ b/git-add.sh
@@ -1,23 +1,39 @@
#!/bin/sh
+usage()
+{
+ echo "usage: git add [-n] [-v] <file>..."
+ exit 1
+}
+
show_only=
verbose=
-while : ; do
- case "$1" in
- -n)
- show_only=true
- verbose=true
- ;;
- -v)
- verbose=true
- ;;
- *)
- break
- ;;
- esac
- shift
+while test $# -gt 0
+do
+ case "$1" in
+ -n)
+ show_only=true
+ verbose=true
+ ;;
+ -v)
+ verbose=true
+ ;;
+ --)
+ shift
+ break
+ ;;
+ -*)
+ usage
+ ;;
+ *)
+ break
+ ;;
+ esac
+ shift
done
+test $# -eq 0 && usage
+
GIT_DIR=$(git-rev-parse --git-dir) || exit
global_exclude=
if [ -f "$GIT_DIR/info/exclude" ]; then
^ permalink raw reply
* index file screwed up
From: Chuck Lever @ 2005-09-28 15:06 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 949 bytes --]
i was working with a version of git that had a bug in add_cache_entry()
that introduced a sorting error in my index.
[cel@dexter main]$ stg refresh -f
Refreshing patch "git-switch-branch"...AUTHORS: unmerged
(098c1d3e9fe5c39b859ccff6c7d36d2c193d1b62)
AUTHORS: unmerged (098c1d3e9fe5c39b859ccff6c7d36d2c193d1b62)
COPYING: unmerged (d60c31a97a544b53039088d14fe9114583c0efc3)
COPYING: unmerged (d60c31a97a544b53039088d14fe9114583c0efc3)
INSTALL: unmerged (8d2bebd9d1824f1b7af5cfe6fbd11f9cbfde6d74)
INSTALL: unmerged (8d2bebd9d1824f1b7af5cfe6fbd11f9cbfde6d74)
MANIFEST.in: unmerged (581d0be2a5fb3569b06681b7d559f1279aa4104b)
MANIFEST.in: unmerged (581d0be2a5fb3569b06681b7d559f1279aa4104b)
README: unmerged (184ded8e08cb92a14b79c79f9919469ba352ab70)
README: unmerged (184ded8e08cb92a14b79c79f9919469ba352ab70)
...
fatal: git-write-tree: verify_merged: not able to write tree
stg refresh: git-write-tree failed
[cel@dexter main]$
how do i recover?
[-- Attachment #2: cel.vcf --]
[-- Type: text/x-vcard, Size: 439 bytes --]
begin:vcard
fn:Chuck Lever
n:Lever;Charles
org:Network Appliance, Incorporated;Linux NFS Client Development
adr:535 West William Street, Suite 3100;;Center for Information Technology Integration;Ann Arbor;MI;48103-4943;USA
email;internet:cel@citi.umich.edu
title:Member of Technical Staff
tel;work:+1 734 763 4415
tel;fax:+1 734 763 4434
tel;home:+1 734 668 1089
x-mozilla-html:FALSE
url:http://www.monkey.org/~cel/
version:2.1
end:vcard
^ permalink raw reply
* Re: git cvsimport?
From: Sven Verdoolaege @ 2005-09-28 15:18 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: git
In-Reply-To: <20050928124029.1BF6D352B7B@atlas.denx.de>
On Wed, Sep 28, 2005 at 02:40:29PM +0200, Wolfgang Denk wrote:
>
> I have problems importing a CVS repository:
>
> -> git cvsimport -v -d :pserver:denx@cvs.semihalf.com:/cvs -C /home/git/duts duts
> cvs_direct initialized to CVSROOT /cvs
> cvs rlog: Logging duts
> cvs rlog: Logging duts/core
> NOTICE: used alternate strip path /home/cvs/duts/core/duts
> DONE; creating master branch
> cp: cannot stat `/home/git/duts/.git/refs/heads/origin': No such file or directory
> usage: git-read-tree (<sha> | -m [-u | -i] <sha1> [<sha2> [<sha3>]])
> checkout failed: 256
> -> git --version
> git version 0.99.7
>
> Am I doing anything wrong here?
>
What does
cvsps -u -A --cvs-direct --root :pserver:denx@cvs.semihalf.com:/cvs duts
say ?
skimo
^ permalink raw reply
* Re: [PATCH] Use git-update-ref in scripts.
From: Linus Torvalds @ 2005-09-28 15:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vpsqtykor.fsf_-_@assigned-by-dhcp.cox.net>
On Tue, 27 Sep 2005, Junio C Hamano wrote:
>
> This uses the git-update-ref command in scripts for safer updates.
Looks good.
git-resolve might want to verify the old head. On the other hand, it looks
like it's being phased out, so maybe nobody cares?
Linus
^ permalink raw reply
* Re: [PATCH] Fix git-pull output message
From: Linus Torvalds @ 2005-09-28 15:29 UTC (permalink / raw)
To: Robert Watson; +Cc: git, Junio C Hamano
In-Reply-To: <72499e3b05092803027175bab0@mail.gmail.com>
On Wed, 28 Sep 2005, Robert Watson wrote:
>
> Notice that the git.git directory is truncated. It seems the
> intension is to truncate at the .git
> directory level. The following patch fixes it.
No, the intention really is to remove the ".git" at the end. At least
that's how I use it.
I like seeing my merges say
Merge branch 'for-linus' from master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband
even though the _real_ directory was ".../infiniband.git/", simply because
the ".git" doesn't really add any extra information when you're already in
git.
_outside_ of git, the ".git" tells you something: it tells you that you're
entering a git archive. But when merging in git, that part is kind of
taken for granted, isn't it?
This also matches what "git-receive-pack" and "git-upload-pack" does:
...
/* chdir to the directory. If that fails, try appending ".git" */
if (chdir(dir) < 0) {
if (chdir(mkpath("%s.git", dir)) < 0)
die("unable to cd to %s", dir);
}
/* If we have a ".git" directory, chdir to it */
chdir(".git");
...
Note how it _both_ will append ".git" to the directory name (if it can't
find one without ".git" _and_ will try to chdir to a ".git" directory
_within_ the directory name.
So if you use the native pack ssh interfaces, you really can say
git pull master.kernel.org:.../infiniband
because the tools (well, the "native pack" ones - not the http/rsync/scp
ones) will automatically DTRT.
Linus
^ permalink raw reply
* Re: index file screwed up
From: Linus Torvalds @ 2005-09-28 15:37 UTC (permalink / raw)
To: Chuck Lever; +Cc: git
In-Reply-To: <433AB170.90608@citi.umich.edu>
On Wed, 28 Sep 2005, Chuck Lever wrote:
>
> i was working with a version of git that had a bug in add_cache_entry()
> that introduced a sorting error in my index.
>
> [cel@dexter main]$ stg refresh -f
> Refreshing patch "git-switch-branch"...AUTHORS: unmerged
> (098c1d3e9fe5c39b859ccff6c7d36d2c193d1b62)
> AUTHORS: unmerged (098c1d3e9fe5c39b859ccff6c7d36d2c193d1b62)
> COPYING: unmerged (d60c31a97a544b53039088d14fe9114583c0efc3)
> COPYING: unmerged (d60c31a97a544b53039088d14fe9114583c0efc3)
> INSTALL: unmerged (8d2bebd9d1824f1b7af5cfe6fbd11f9cbfde6d74)
> INSTALL: unmerged (8d2bebd9d1824f1b7af5cfe6fbd11f9cbfde6d74)
> MANIFEST.in: unmerged (581d0be2a5fb3569b06681b7d559f1279aa4104b)
> MANIFEST.in: unmerged (581d0be2a5fb3569b06681b7d559f1279aa4104b)
> README: unmerged (184ded8e08cb92a14b79c79f9919469ba352ab70)
> README: unmerged (184ded8e08cb92a14b79c79f9919469ba352ab70)
> ...
> fatal: git-write-tree: verify_merged: not able to write tree
> stg refresh: git-write-tree failed
>
> [cel@dexter main]$
>
> how do i recover?
You don't. Your index is toast.
Let's hope you didn't write any unsorted trees with _earlier_ (non-merge)
commits.
Do this:
- build a new and trustworthy git somewhere else (from a tar-file if
nothing else). Install it.
- get rid of the index and any half-way data in your working tree (you
might want to save any diffs with "git diff HEAD" first, but I suspect
you don't really care, since the changes came from some stg stuff, so
you can always re-create them, no?)
git reset --hard HEAD
- run fsck, to verify that all your trees are sorted (if they aren't, you
be screwed, but "git-convert-objects" should be able to fix it for
you - possibly with some additional logic).
git-fsck-objects --full
- restart and try again.
That _should_ get you running again.
Linus
^ permalink raw reply
* Re: git cvsimport?
From: Wolfgang Denk @ 2005-09-28 15:49 UTC (permalink / raw)
To: skimo; +Cc: git
In-Reply-To: <20050928151812.GS15165MdfPADPa@greensroom.kotnet.org>
In message <20050928151812.GS15165MdfPADPa@greensroom.kotnet.org> you wrote:
>
> > I have problems importing a CVS repository:
...
> What does
> cvsps -u -A --cvs-direct --root :pserver:denx@cvs.semihalf.com:/cvs duts
> say ?
-> cvsps -u -A --cvs-direct --root :pserver:denx@cvs.semihalf.com:/cvs duts
connect error: Network is unreachable
cvs rlog: cannot find module `duts' - ignored
But "cvs -d :pserver:denx@cvs.semihalf.com:/cvs co duts" works fine...
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
I have a very small mind and must live with it. -- Edsger Dijkstra
^ permalink raw reply
* Re: git cvsimport?
From: Sven Verdoolaege @ 2005-09-28 16:04 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: git
In-Reply-To: <20050928154955.EB723353BE5@atlas.denx.de>
On Wed, Sep 28, 2005 at 05:49:55PM +0200, Wolfgang Denk wrote:
> In message <20050928151812.GS15165MdfPADPa@greensroom.kotnet.org> you wrote:
> >
> > > I have problems importing a CVS repository:
> ...
> > What does
> > cvsps -u -A --cvs-direct --root :pserver:denx@cvs.semihalf.com:/cvs duts
> > say ?
>
> -> cvsps -u -A --cvs-direct --root :pserver:denx@cvs.semihalf.com:/cvs duts
> connect error: Network is unreachable
> cvs rlog: cannot find module `duts' - ignored
Does leaving out the --cvs-direct have any effect ?
skimo
^ 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