* Re: [PATCH] several typos in tutorial
From: Alexey Nezhdanov @ 2005-06-02 12:45 UTC (permalink / raw)
To: git; +Cc: Vincent Hanquez, Linus Torvalds
In-Reply-To: <20050602124143.GA31483@snarc.org>
On thursday, 02 June 2005 16:41 Vincent Hanquez wrote:
> On Thu, Jun 02, 2005 at 04:02:07PM +0400, Alexey Nezhdanov wrote:
> > Git arhives are normally totally self-sufficient, and it's worth noting
>
> ^^^^^^^
> and one more here
Why? It's ok to speak about many [existing] archives here.
--
Respectfully
Alexey Nezhdanov
^ permalink raw reply
* Re: [PATCH] several typos in tutorial
From: Vincent Hanquez @ 2005-06-02 12:41 UTC (permalink / raw)
To: Alexey Nezhdanov; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <200506021602.07258.snake@penza-gsm.ru>
On Thu, Jun 02, 2005 at 04:02:07PM +0400, Alexey Nezhdanov wrote:
> Git arhives are normally totally self-sufficient, and it's worth noting
^^^^^^^
and one more here
--
Vincent Hanquez
^ permalink raw reply
* [PATCH] several typos in tutorial
From: Alexey Nezhdanov @ 2005-06-02 12:02 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List, Alexey Nezhdanov
In-Reply-To: <Pine.LNX.4.58.0505312002160.1876@ppc970.osdl.org>
Signed-off-by: Alexey Nezhdanov <snake@penza-gsm.ru>
---
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -298,7 +298,7 @@ have committed something, we can also le
Unlike "git-diff-files", which showed the difference between the index
file and the working directory, "git-diff-cache" shows the differences
-between a committed _tree_ and the index file. In other words,
+between a committed _tree_ and the working directory. In other words,
git-diff-cache wants a tree to be diffed against, and before we did the
commit, we couldn't do that, because we didn't have anything to diff
against.
@@ -423,8 +423,8 @@ With that, you should now be having some
can explore on your own.
- Copoying archives
- -----------------
+ Copying archives
+ ----------------
Git arhives are normally totally self-sufficient, and it's worth noting
that unlike CVS, for example, there is no separate notion of
^ permalink raw reply
* [COGITO PATCH]Re: Origin handling
From: Santi Béjar @ 2005-06-02 10:18 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <877jhdthhr.fsf@gmail.com>
I propose that the origin of a branch comes from a file in
.git/branches/ of the same name. So the origin of default branch
master is the content of the file .git/branches/master that in
the current practice would be "origin". But we could have the
remote branch "git", being the origin of the local branch
"git_dirs" (the content of .git/branches/git_dirs = "git").
The origin branch is reserved. When you cg-clone the origin is now
called cloned (but "commit-id cloned" = "commit-id origin" while you do
not switch to another branch whith other origin). The transition from
old handling is not in the patch.
So now you can:
cg-clone -s rsync://rsync.kernel.org/pub/scm/git/git.git/
and work in this in your "master" branch with origin "cloned".
You can add another repository:
cg-branch-add pb http://pasky.or.cz/~pasky/dev/git/git-pb.git
cg-pull pb
and if you want to do some modifications based on pb:
cg-branch-add pb-sb pb
ln -s refs/heads/pb-sb .git/HEAD
commit-id pb > .git/HEAD
git-read-tree HEAD
git-checkout-cache -f -q -u -a
and work on your branch.
The last four lines are the work of the hipothetical cg-branch-switch.
Signed-off-by: "Santi Béjar" <sbejar@gmail.com>
---
cg-Xnormid | 6 ++++++
cg-branch-add | 2 +-
cg-clone | 2 +-
cg-commit | 7 ++++++-
cg-init | 9 +++++----
cg-merge | 7 ++++++-
cg-pull | 7 ++++++-
7 files changed, 31 insertions(+), 9 deletions(-)
diff --git a/cg-Xnormid b/cg-Xnormid
--- a/cg-Xnormid
+++ b/cg-Xnormid
@@ -6,6 +6,7 @@
#
# Strings resolve in this order:
# NULL, this, HEAD => .git/HEAD
+# origin => origin of the branch
# <tags>
# <heads>
# short SHA1 (4 or more hex digits)
@@ -19,6 +20,11 @@ id="$1"
if [ ! "$id" ] || [ "$id" = "this" ] || [ "$id" = "HEAD" ]; then
read id < "$_git/HEAD"
+elif [ "$id" = "origin" ]; then
+ branch=$(readlink $_git/HEAD | sed 's@refs/heads/@@')
+ origin=$(cat $_git/branches/$branch)
+ read id < "$_git/refs/heads/$origin"
+
elif [ -r "$_git/refs/tags/$id" ]; then
read id < "$_git/refs/tags/$id"
diff --git a/cg-branch-add b/cg-branch-add
--- a/cg-branch-add
+++ b/cg-branch-add
@@ -40,7 +40,7 @@ location=$2
([ "$name" ] && [ "$location" ]) || usage
(echo $name | egrep -qv '[^a-zA-Z0-9_.@!:-]') || \
die "name contains invalid characters"
-if [ "$name" = "this" ] || [ "$name" = "HEAD" ]; then
+if [ "$name" = "this" ] || [ "$name" = "HEAD" ] || [ "$name" = "origin" ]; then
die "given branch name is reserved"
fi
diff --git a/cg-clone b/cg-clone
--- a/cg-clone
+++ b/cg-clone
@@ -56,4 +56,4 @@ fi
trap "rm -rf $dir" SIGTERM EXIT
cg-init $location || exit $?
trap "" SIGTERM EXIT
-echo "Cloned to $dir/ (origin $location available as branch \"origin\")"
+echo "Cloned to $dir/ (origin $location available as branch \"cloned\")"
diff --git a/cg-commit b/cg-commit
--- a/cg-commit
+++ b/cg-commit
@@ -141,7 +141,12 @@ if [ "$merging" ]; then
[ "$msgs" ] && echo -n 'Merge with '
[ -s $_git/merging-sym ] || cp $_git/merging $_git/merging-sym
for sym in $(cat $_git/merging-sym); do
- uri=$(cat $_git/branches/$sym)
+ if [ $sym = origin ] ; then
+ branch=$(readlink $_git/HEAD | sed 's@refs/heads/@@')
+ uri=$(cat $_git/branches/$branch)
+ else
+ uri=$(cat $_git/branches/$sym)
+ fi
[ "$uri" ] || uri="$sym"
echo "$uri" >>$LOGMSG
[ "$msgs" ] && echo "$uri"
diff --git a/cg-init b/cg-init
--- a/cg-init
+++ b/cg-init
@@ -26,15 +26,16 @@ mkdir $_git/branches
touch $_git/refs/heads/master
if [ "$uri" ]; then
- echo "$uri" >$_git/branches/origin
- cg-pull origin || die "pull failed"
+ echo "$uri" >$_git/branches/cloned
+ echo cloned >$_git/branches/master
+ cg-pull cloned || die "pull failed"
- cp $_git/refs/heads/origin $_git/refs/heads/master
+ cp $_git/refs/heads/cloned $_git/refs/heads/master
git-read-tree HEAD
git-checkout-cache -a
git-update-cache --refresh
- echo "Cloned (origin $uri available as branch \"origin\")"
+ echo "Cloned (cloned $uri available as branch \"cloned\")"
else
git-read-tree # Seed the dircache
find * \( -type f -o -type l \) -print0 | xargs -0r cg-add
diff --git a/cg-pull b/cg-pull
--- a/cg-pull
+++ b/cg-pull
@@ -14,10 +14,15 @@ USAGE="cg-pull [BRANCH_NAME]"
name=$1
-[ "$name" ] || { [ -s $_git/refs/heads/origin ] && name=origin; }
+if [ -z "$name" ]; then
+ branch=$(readlink $_git/HEAD | sed 's@refs/heads/@@')
+ name=$(cat $_git/branches/$branch 2>/dev/null)
+fi
[ "$name" ] || die "where to pull from?"
uri=$(cat "$_git/branches/$name" 2>/dev/null) || die "unknown branch: $name"
+[ -e "$_git/branches/$uri" ] && die "local branches cannot pull"
+
rembranch=master
if echo "$uri" | grep -q '#'; then
rembranch=$(echo $uri | cut -d '#' -f 2)
^ permalink raw reply
* Re: [SCRIPT] cg-rpush & locking
From: Matthias Urlichs @ 2005-06-02 10:04 UTC (permalink / raw)
To: Tony Lindgren
Cc: Daniel Barkalow, Linus Torvalds, Thomas Glanzmann, Nicolas Pitre,
git
In-Reply-To: <20050602073205.GA31482@muru.com>
[-- Attachment #1: Type: text/plain, Size: 1238 bytes --]
Hi,
Tony Lindgren:
> I don't think locking for the duration of the push really is a problem.
> It is unlikely that there would be so many people pushing that it would
> cause inconvenience... Of course it would be nice to optimize it if
> possible.
>
Since an 'atomic' cmpxchg operation is actually easier to program than a
lockfile with timeout handling etc., I would hope so. ;-)
> I would assume the biggest problem for most people is how they can push
> through a firewall. From that point of view it would make sense to do
> the push as a cgi script rather than something over ssh.
When in doubt, do both ... I'd certainly prefer ssh if at all possible.
> And with a cgi script you can of course optimize the locking and use
> tmp files before renaming which are a bit hard to do with rsync.
>
rsync is going away anyway for git usage (long-term), I'd assume. It
certainly becomes more and more ineffective the more our history is
growing.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
No one can guarantee the actions of another.
-- Spock, "Day of the Dove", stardate unknown
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] Miniscule correction of diff-format.txt
From: Christian Meder @ 2005-06-02 9:55 UTC (permalink / raw)
To: torvalds; +Cc: git
Add missing "space" element to the description of the diff-format.
Signed-off-by: Christian Meder <chris@absolutegiganten.org>
---
diff --git a/Documentation/diff-format.txt b/Documentation/diff-format.txt
--- a/Documentation/diff-format.txt
+++ b/Documentation/diff-format.txt
@@ -36,12 +36,13 @@ That is, from the left to the right:
(6) sha1 for "src"; 0{40} if creation or unmerged.
(7) a space.
(8) sha1 for "dst"; 0{40} if creation, unmerged or "look at work tree".
- (9) status, followed by optional "score" number.
- (10) a tab or a NUL when '-z' option is used.
- (11) path for "src"
- (12) a tab or a NUL when '-z' option is used; only exists for C or R.
- (13) path for "dst"; only exists for C or R.
- (14) an LF or a NUL when '-z' option is used, to terminate the record.
+ (9) a space.
+ (10) status, followed by optional "score" number.
+ (11) a tab or a NUL when '-z' option is used.
+ (12) path for "src"
+ (13) a tab or a NUL when '-z' option is used; only exists for C or R.
+ (14) path for "dst"; only exists for C or R.
+ (15) an LF or a NUL when '-z' option is used, to terminate the record.
<sha1> is shown as all 0's if new is a file on the filesystem
and it is out of sync with the cache. Example:
--
Christian Meder, email: chris@absolutegiganten.org
The Way-Seeking Mind of a tenzo is actualized
by rolling up your sleeves.
(Eihei Dogen Zenji)
^ permalink raw reply
* Re: I want to release a "git-1.0"
From: Kay Sievers @ 2005-06-02 8:32 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <m18y1tb55c.fsf@ebiederm.dsl.xmission.com>
On Thu, Jun 02, 2005 at 01:15:59AM -0600, Eric W. Biederman wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
>
> > Anyway, I wrote just a _very_ introductory thing in
> > Documentation/tutorial.txt, I'll try to update and expand on it later. It
> > basically has a really stupid example of "how to set up a new project".
>
> So I need to do a git checkout of the latest version of git to
> read the tutorial? So I can figure out how to use git?
No problem: :)
http://www.kernel.org/git/?p=git/git.git;a=blob;f=Documentation/tutorial.txt
Kay
^ permalink raw reply
* [PATCH] Spelling fixes for git tutorial
From: Peter Hagervall @ 2005-06-02 7:39 UTC (permalink / raw)
To: torvalds; +Cc: git
Fix a few spellos in the otherwise excellent tutorial.
Signed-off-by: Peter Hagervall <hager@cs.umu.se>
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -405,7 +405,7 @@ can do
git log
which shows just the log messages, or if we want to see the log together
-whith the associated patches use the more complex (and much more
+with the associated patches use the more complex (and much more
powerful)
git-whatchanged -p --root
@@ -423,10 +423,10 @@ With that, you should now be having some
can explore on your own.
- Copoying archives
+ Copying archives
-----------------
-Git arhives are normally totally self-sufficient, and it's worth noting
+Git archives are normally totally self-sufficient, and it's worth noting
that unlike CVS, for example, there is no separate notion of
"repository" and "working tree". A git repository normally _is_ the
working tree, with the local git information hidden in the ".git"
@@ -486,7 +486,7 @@ actual core git files. Such a repository
repository.
To create your own local live copy of such a "raw" git repository, you'd
-first create your own subdirectory for the project, adn then copy the
+first create your own subdirectory for the project, and then copy the
raw repository contents into the ".git" directory. For example, to
create your own copy of the git repository, you'd do the following
@@ -512,7 +512,7 @@ older version of a checked out tree you
file first, to tell git-checkout-cache to _force_ overwriting of any old
files).
-You have now successfully copied somebody elses (mine) remote
+You have now successfully copied somebody else's (mine) remote
repository, and checked it out.
[ to be continued.. cvs2git, tagging versions, branches, merging.. ]
^ permalink raw reply
* Re: [SCRIPT] cg-rpush & locking
From: Tony Lindgren @ 2005-06-02 7:32 UTC (permalink / raw)
To: Matthias Urlichs
Cc: Daniel Barkalow, Linus Torvalds, Thomas Glanzmann, Nicolas Pitre,
Tony Lindgren, git
In-Reply-To: <20050602071453.GA16616@kiste.smurf.noris.de>
On Thu, Jun 02, 2005 at 09:14:53AM +0200, Matthias Urlichs wrote:
> Hi,
>
> Daniel Barkalow:
> > If the lock is only to protect against someone else modifying HEAD after
> > we've checked that it is our starting point and before we modify it,
> > there's no reason not to hold the lock while pushing; it wouldn't block
> > anything other than someone doing a quick push in the middle of our long
> > one, and thereby causing us to dump a lot of useless objects on the
> > server (which will become obsolete as we will need to do the merge and
> > push a different version).
> >
> The objects we push aren't going to be obsolete. The server needs them
> anyway, because our HEAD refers to them.
I don't think locking for the duration of the push really is a problem.
It is unlikely that there would be so many people pushing that it would
cause inconvenience... Of course it would be nice to optimize it if
possible.
> What if the connection dies in the middle of a push? You then sit there
> waiting for it, and the lock, to time out. OTOH, an atomic cmpxchg on
> the server can't block and can't timeout.
>
> > you want to have the
> > client watch for the resolution of the other transfer one way or the
> > other, since you're in the current state precisely because you lost on
> > getting the lock and now definitely need the next version.
> >
> I disagree. Given that you need to wait for the upload to finish anyway
> (whether you know it or not ;-) it makes sense to spend the time
> actually uploading -- upload speed is frequently lower than download
> for individuals.
I would assume the biggest problem for most people is how they can push
through a firewall. From that point of view it would make sense to do
the push as a cgi script rather than something over ssh. And with a
cgi script you can of course optimize the locking and use tmp files
before renaming which are a bit hard to do with rsync.
Tony
^ permalink raw reply
* Re: I want to release a "git-1.0"
From: Eric W. Biederman @ 2005-06-02 7:15 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0505312002160.1876@ppc970.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Anyway, I wrote just a _very_ introductory thing in
> Documentation/tutorial.txt, I'll try to update and expand on it later. It
> basically has a really stupid example of "how to set up a new project".
So I need to do a git checkout of the latest version of git to
read the tutorial? So I can figure out how to use git?
Catch 22? :)
Eric
^ permalink raw reply
* Re: [SCRIPT] cg-rpush & locking
From: Matthias Urlichs @ 2005-06-02 7:14 UTC (permalink / raw)
To: Daniel Barkalow
Cc: Linus Torvalds, Thomas Glanzmann, Nicolas Pitre, Tony Lindgren,
git
In-Reply-To: <Pine.LNX.4.21.0506020223570.30848-100000@iabervon.org>
Hi,
Daniel Barkalow:
> If the lock is only to protect against someone else modifying HEAD after
> we've checked that it is our starting point and before we modify it,
> there's no reason not to hold the lock while pushing; it wouldn't block
> anything other than someone doing a quick push in the middle of our long
> one, and thereby causing us to dump a lot of useless objects on the
> server (which will become obsolete as we will need to do the merge and
> push a different version).
>
The objects we push aren't going to be obsolete. The server needs them
anyway, because our HEAD refers to them.
What if the connection dies in the middle of a push? You then sit there
waiting for it, and the lock, to time out. OTOH, an atomic cmpxchg on
the server can't block and can't timeout.
> you want to have the
> client watch for the resolution of the other transfer one way or the
> other, since you're in the current state precisely because you lost on
> getting the lock and now definitely need the next version.
>
I disagree. Given that you need to wait for the upload to finish anyway
(whether you know it or not ;-) it makes sense to spend the time
actually uploading -- upload speed is frequently lower than download
for individuals.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Who was that masked man?
^ permalink raw reply
* Re: [SCRIPT] cg-rpush & locking
From: Daniel Barkalow @ 2005-06-02 6:39 UTC (permalink / raw)
To: Linus Torvalds
Cc: Thomas Glanzmann, Nicolas Pitre, Tony Lindgren, git,
Matthias Urlichs
In-Reply-To: <Pine.LNX.4.58.0506011951150.1876@ppc970.osdl.org>
On Wed, 1 Jun 2005, Linus Torvalds wrote:
>
>
> On Wed, 1 Jun 2005, Thomas Glanzmann wrote:
> >
> > 1. acquire remote lock
> > 2. get remote HEAD
> > 3. if remote HEAD is ahead (not included in our history) abort
> > and free lock.
> > 4. push objects
> > 5. update remote HEAD with local
> > 6. free remote lock.
>
> You really need a specialized client at the other end, because regardless
> of locking, you want to write the objects atomically (ie download them
> into a temp-file, and then do the "rename" thing to make them show up
> all-or-nothing).
>
> Also, I'd suggest a slight modification to avoid keeping the lock for a
> long time, namely to have the lock protect just a quick "compare and
> exchange". So the algorithm would become:
>
> 1. read remote HEAD
> 2. if remote HEAD isn't in our history, abort with "remote is
> ahead"
> 3. calculate the objects needed to push locally
> 4. push them (but accept the possibility that the remote may
> already have them, so have the protocol able to say "got that
> one already"). Make this use the atomic write on the other end.
> 5. do an atomic compare-and-exchange of the remote head with the
> new one (ie only switch the remote HEAD if it still matches
> what we were expecting it to be)
>
> Hmm?
If the lock is only to protect against someone else modifying HEAD after
we've checked that it is our starting point and before we modify it,
there's no reason not to hold the lock while pushing; it wouldn't block
anything other than someone doing a quick push in the middle of our long
one, and thereby causing us to dump a lot of useless objects on the
server (which will become obsolete as we will need to do the merge and
push a different version).
The key is that people can still download the old version until the new
version is there, regardless of the lock; they'll get data about to
go stale, but they would have anyway had they been a few seconds
earlier. The main annoyance would be that you'd be blocked from pushing,
and then have to poll for the other upload to finish before you'd be able
to pull, do the merge, and then push your changes; you want to have the
client watch for the resolution of the other transfer one way or the
other, since you're in the current state precisely because you lost on
getting the lock and now definitely need the next version.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Origin handling
From: Santi Béjar @ 2005-06-02 6:12 UTC (permalink / raw)
To: Git Mailing List
I propose that the origin of a branch comes from a file in
.git/branches/ of the same name. So the origin of default branch
master is the content of the file .git/branches/master that in
the current practice would be "origin". But we could have the
remote branch "git", being the origin of the local branch
"git_dirs" (the content of .git/branches/git_dirs = "git").
What do you think?
Santi
^ permalink raw reply
* Re: [COGITO PATCH] cg-branch-switch and local branches
From: Santi Béjar @ 2005-06-02 6:09 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <877jheqcah.fsf@gmail.com>
Hi,
I have realized that it was overcomplicated and against the
common practice of having .git/HEAD pointing to the current
branch, as I've just seen on a git-switch-branch by Jeff.
But the only thing I miss now is the origin handling.
Sorry for the noise.
Santi
^ permalink raw reply
* Re: [SCRIPT] cg-rpush & locking
From: Linus Torvalds @ 2005-06-02 2:58 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: Nicolas Pitre, Tony Lindgren, git, Matthias Urlichs
In-Reply-To: <20050601065123.GA23358@cip.informatik.uni-erlangen.de>
On Wed, 1 Jun 2005, Thomas Glanzmann wrote:
>
> 1. acquire remote lock
> 2. get remote HEAD
> 3. if remote HEAD is ahead (not included in our history) abort
> and free lock.
> 4. push objects
> 5. update remote HEAD with local
> 6. free remote lock.
You really need a specialized client at the other end, because regardless
of locking, you want to write the objects atomically (ie download them
into a temp-file, and then do the "rename" thing to make them show up
all-or-nothing).
Also, I'd suggest a slight modification to avoid keeping the lock for a
long time, namely to have the lock protect just a quick "compare and
exchange". So the algorithm would become:
1. read remote HEAD
2. if remote HEAD isn't in our history, abort with "remote is
ahead"
3. calculate the objects needed to push locally
4. push them (but accept the possibility that the remote may
already have them, so have the protocol able to say "got that
one already"). Make this use the atomic write on the other end.
5. do an atomic compare-and-exchange of the remote head with the
new one (ie only switch the remote HEAD if it still matches
what we were expecting it to be)
Hmm?
Linus
^ permalink raw reply
* Re: [PATCH] Handle deltified object correctly in git-*-pull family.
From: Junio C Hamano @ 2005-06-02 1:43 UTC (permalink / raw)
To: Linus Torvalds
Cc: Nicolas Pitre,
Daniel Barkalow <barkalow@iabervon.org> Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0506011738080.1876@ppc970.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> Why not just split out the current "unpack_sha1_file()" into two stages:
LT> "unpack_sha1_header()" and the rest.
LT> which is a lot simpler than worrying about callbacks etc.
Alright.
^ permalink raw reply
* Re: [PATCH] Stop inflating the whole SHA1 file only to check size.
From: Junio C Hamano @ 2005-06-02 1:32 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Linus Torvalds,
Daniel Barkalow <barkalow@iabervon.org> Git Mailing List
In-Reply-To: <Pine.LNX.4.63.0506012048330.17354@localhost.localdomain>
>>>>> "NP" == Nicolas Pitre <nico@cam.org> writes:
NP> On Wed, 1 Jun 2005, Junio C Hamano wrote:
>> Using the new unpack_sha1_file_partial() function, stop
>> inflating the whole SHA1 file when rename detector wants to know
>> only the filesize.
NP> Beware.
You are right. I cannot believe how stupid I am, falling into
this trap _just_ _after_ looking at the delta stuff X-<.
Linus please drop that one.
^ permalink raw reply
* Re: I want to release a "git-1.0"
From: Brian O'Mahoney @ 2005-06-02 1:14 UTC (permalink / raw)
To: Nicolas Pitre
Cc: C. Scott Ananian, David Lang, Junio C Hamano, Chris Wedgwood,
Linus Torvalds, Git Mailing List
In-Reply-To: <Pine.LNX.4.63.0506012040310.17354@localhost.localdomain>
Neither are _correct_, both are slang and a new word, but
English is good at that,
represent via a delta, would be traditional,
but 'deltify' sounds nicer.
Nicolas Pitre wrote:
> On Wed, 1 Jun 2005, C. Scott Ananian wrote:
>
>
>>On Wed, 1 Jun 2005, David Lang wrote:
>>
>>
>>>>*1* David says "deltify" and Nico calls it "deltafy". I am not
>>>>a native speaker so I cannot tell, but which one is correct?
>>>
>>>Nico is correct
>>
>>Au contraire. The common *pronunciation* may be 'delta-fy', but the correct
>>spelling should be 'deltify'.
>
>
> Ainsi soit-il alors.
>
> I'm not a native english speaker either so I defer to anyone with better
> english knowledge.
>
>
> Nicolas
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
--
mit freundlichen Grüßen, Brian.
Dr. Brian O'Mahoney
Mobile +41 (0)79 334 8035 Email: omb@bluewin.ch
Bleicherstrasse 25, CH-8953 Dietikon, Switzerland
PGP Key fingerprint = 33 41 A2 DE 35 7C CE 5D F5 14 39 C9 6D 38 56 D5
^ permalink raw reply
* Re: [PATCH] Handle deltified object correctly in git-*-pull family.
From: Linus Torvalds @ 2005-06-02 0:58 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nicolas Pitre,
Daniel Barkalow <barkalow@iabervon.org> Git Mailing List
In-Reply-To: <7v1x7lk8fl.fsf_-_@assigned-by-dhcp.cox.net>
On Wed, 1 Jun 2005, Junio C Hamano wrote:
>
> *** Linus, I have a hook in sha1_file.c to let me figure out the
> *** size of the SHA1 file without fully expanding it. This
> *** patch does not use it, but you already know where I am
> *** heading, so please leave it there ;-).
Argh. This is just adding conceptual complexity without any real
advantage.
Why not just split out the current "unpack_sha1_file()" into two stages:
"unpack_sha1_header()" and the rest.
Then you can just decide to call "unpack_sha1_header()" when you want the
header information.
Hmm. I just committed something like that. If you want to just see the
type of an object, you can map the object in memory, and just do
z_stream stream;
char buffer[100];
if (unpack_sha1_header(&stream, map, mapsize, buffer, sizeof(buffer) < 0)
return NULL;
if (sscanf(buffer, %10s %lu", type, size) != 0)
return NULL;
.. there you have it ..
which is a lot simpler than worrying about callbacks etc.
Linus
^ permalink raw reply
* Re: [PATCH] Stop inflating the whole SHA1 file only to check size.
From: Nicolas Pitre @ 2005-06-02 0:51 UTC (permalink / raw)
To: Junio C Hamano
Cc: Linus Torvalds,
Daniel Barkalow <barkalow@iabervon.org> Git Mailing List
In-Reply-To: <7vpsv5hbm5.fsf@assigned-by-dhcp.cox.net>
On Wed, 1 Jun 2005, Junio C Hamano wrote:
> Using the new unpack_sha1_file_partial() function, stop
> inflating the whole SHA1 file when rename detector wants to know
> only the filesize.
Beware. If you have delta objects you'll get the size of the delta
itself and not the final object size, unless you recurse until a non
delta object is found.
Nicolas
^ permalink raw reply
* Re: [PATCH] Handle deltified object correctly in git-*-pull family.
From: Nicolas Pitre @ 2005-06-02 0:47 UTC (permalink / raw)
To: Junio C Hamano
Cc: Linus Torvalds,
Daniel Barkalow <barkalow@iabervon.org> Git Mailing List
In-Reply-To: <7v1x7lk8fl.fsf_-_@assigned-by-dhcp.cox.net>
On Wed, 1 Jun 2005, Junio C Hamano wrote:
> *** Dan and Nico, could you check this for correctness? I've
> *** tested it with a deltified core GIT repository and pulling
> *** with local-pull from there. I have verified that a pull
> *** that fails with -d flag retrieves the right base-object to
> *** complete a deltified ones.
The delta part looks fine to me.
Nicolas
^ permalink raw reply
* Re: I want to release a "git-1.0"
From: Nicolas Pitre @ 2005-06-02 0:43 UTC (permalink / raw)
To: C. Scott Ananian
Cc: David Lang, Junio C Hamano, Chris Wedgwood, Linus Torvalds,
Git Mailing List
In-Reply-To: <Pine.LNX.4.61.0506011607480.11264@cag.csail.mit.edu>
On Wed, 1 Jun 2005, C. Scott Ananian wrote:
> On Wed, 1 Jun 2005, David Lang wrote:
>
> > > *1* David says "deltify" and Nico calls it "deltafy". I am not
> > > a native speaker so I cannot tell, but which one is correct?
> >
> > Nico is correct
>
> Au contraire. The common *pronunciation* may be 'delta-fy', but the correct
> spelling should be 'deltify'.
Ainsi soit-il alors.
I'm not a native english speaker either so I defer to anyone with better
english knowledge.
Nicolas
^ permalink raw reply
* Re: I want to release a "git-1.0"
From: Junio C Hamano @ 2005-06-01 23:05 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Linus Torvalds, Eric W. Biederman, Git Mailing List
In-Reply-To: <Pine.LNX.4.21.0506011742560.30848-100000@iabervon.org>
>>>>> "DB" == Daniel Barkalow <barkalow@iabervon.org> writes:
DB> It shouldn't be hard to do one, except that locking with
DB> rsync is going to be a pain. I had a patch to make it work
DB> with the rpush/rpull pair, but I didn't get its dependancies
DB> in at the time. I can dust those patches off again if you
DB> want that functionality included.
Talking about pulls, wouldn't it be nicer to (re)name it to
git-ssh-pull, for consistency with others, especially before we
hit 1.0?
^ permalink raw reply
* Re: I want to release a "git-1.0"
From: Junio C Hamano @ 2005-06-01 23:03 UTC (permalink / raw)
To: David Lang; +Cc: Chris Wedgwood, Linus Torvalds, Git Mailing List
In-Reply-To: <Pine.LNX.4.62.0506011304001.21267@qynat.qvtvafvgr.pbz>
>>>>> "DL" == David Lang <david.lang@digitalinsight.com> writes:
>> Internally, git-diff-cache -B -C is used which does use the
>> deltify to locate complete rewrites, renames and copies (that's
>> why the script is so slow). For passing on and assigning blames
>> line by line, parsing "diff --unified=0" output was a lot easier
>> for this script and that was what I did in this quick-and-dirty
>> version.
DL> I was under the impressin that the deltafy stuff was significantly
DL> faster then you are suggeting that it is here
I perhaps phrased it poorly.
The slow part is not a single delta operation, but having to run
many delta operations between all combinations of rename/copy
candidates, which is O(n * m) where n is the number of newly
created files (counting "broken" ones created by -B flag) and m
is the number of (deleted, modified and unmodified) files in the
original tree.
^ permalink raw reply
* Re: I want to release a "git-1.0"
From: Daniel Barkalow @ 2005-06-01 22:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Eric W. Biederman, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0505312002160.1876@ppc970.osdl.org>
On Tue, 31 May 2005, Linus Torvalds wrote:
> On Tue, 31 May 2005, Eric W. Biederman wrote:
> >
> > I way behind the power curve on learning git at this point but
> > one piece of the puzzle that CVS has that I don't believe git does
> > are multiple people committing to the same repository, especially
> > remotely. I don't see that as a down side of git but it is a common
> > way people CVS so it is worth documenting.
>
> It's actually one thing git doesn't do per se.
>
> You have to do a "git-pull-script" from the common repository side,
> there's no "git-push-script". Ugly.
It shouldn't be hard to do one, except that locking with rsync is going to
be a pain. I had a patch to make it work with the rpush/rpull pair, but I
didn't get its dependancies in at the time. I can dust those patches off
again if you want that functionality included.
The patches are essentially:
- make the transport protocol handle things other than objects
- library procedure for locking atomic update of refs files
- fetching refs in general
- rpull/rpush that updates a specified ref file atomically
At least the first would be very nice to get in before 1.0, since it is an
incompatible change to the protocol.
-Daniel
*This .sig left intentionally blank*
^ 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