* Re: [PATCH] Adapt to fuse in kernel 2.6.17
From: Jeff Garzik @ 2006-11-12 19:31 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <200611121956.25481.robin.rosenberg.lists@dewire.com>
Robin Rosenberg wrote:
> This was a patch to GITFS, which may be somewhat unclear from the Subject
> line :)
I blinked, and I missed it. Where can I find gitfs? I've long thought
about doing something like that myself.
Jeff
^ permalink raw reply
* Re: should git download missing objects?
From: Junio C Hamano @ 2006-11-12 19:41 UTC (permalink / raw)
To: Anand Kumria; +Cc: git
In-Reply-To: <ej7fgp$8ca$1@sea.gmane.org>
"Anand Kumria" <wildfire@progsoc.org> writes:
> I did an initial clone of Linus' linux-2.6.git tree, via the git protocol,
> and then managed to accidently delete one of the .pack and
> corresponding .idx files.
>
> I thought that 'cg-fetch' would do the job of bring down the missing pack
> again, and all would be well. Alas this isn't the case.
>
> <http://pastebin.ca/246678>
>
> Pasky, on IRC, indicated that this might be because git-fetch-pack isn't
> downloading missing objects when the git:// protocol is being used.
There are the invariants between refs and objects:
- objects that its refs (files under .git/refs/ hierarchy that
record 40-byte hexadecimal object names) point at are never
missing, or the repository is corrupt.
- objects that are reachable via pointers in another object
that is not missing (a tag points at another object, a commit
points at its tree and its parent commits, and a tree points
at its subtrees and blobs) are never missing, or the repository
is corrupt.
Git tools first fetch missing objects and then update your refs
only when fetch succeeds completely, in order to maintain the
above invariants (a partial fetch does not update your refs).
And these invariants are why:
- fsck-objects start reachability check from the refs;
- commit walkers can stop at your existing refs;
- git native protocols only need to tell the other end what
refs you have, in order for the other end to exclude what you
already have from the set of objects it sends you.
What's missing needs to be determined in a reasonably efficient
manner, and the above invariants allow us not have to do the
equivalent of fsck-objects every time. Being able to trust refs
is fairly fundamental in the fetch operation of git.
I am not opposed to the idea of a new tool to fix a corrupted
repository that has broken the above invariants, perhaps caused
by accidental removal of objects and packs by end users. What
it needs to do would be:
- run fsck-objects to notice what are missing, by noting
"broken link from foo to bar" output messages. Object 'bar'
is what you _ought_ to have according to your refs but you
don't (because you removed the objects that should be there),
and everything that is reachable from it from the other side
needs to be retrieved. Because you do not have 'bar', your
end cannot determine what other objects you happen to have in
your object store are reachable from it and would result in
redundant download.
- run fetch-pack equivalent to get everything reachable
starting at the above missing objects, pretending you do not
have any object, because your refs are not trustworthy.
- run fsck-objects again to make sure that your refs can now be
trusted again.
To implement the second step above, you need to implement a
modified fetch-pack that does not trust any of your refs. It
also needs to ignore what are offered from the other end but
asks the objects you know are missing ('bar' in the above
example). This program needs to talk to a modified upload-pack
running at the other end (let's call it upload-pack-recover),
because usual upload-pack does not serve starting from a random
object that happen to be in its repository, but only starting
from objects that are pointed by its own set of refs to ensure
integrity.
The upload-pack-recover program would need to start traversal
from object 'bar' in the above example, and when it does so, it
should not just run 'rev-list --objects' starting at 'bar'. It
first needs to prove that its object store has everything that
is reachable from 'bar' (the recipient would still end up with
an incomplete repository if it didn't).
What this means is that it needs to prove some of its refs can
reach 'bar' (again, on the upstream end, only refs are trusted,
not mere existence of object is not enough) before sending
objects back. Usual upload-pack do not have to do it because it
refuses to serve starting from anything but what its refs point
at (and by the invariants, the objects pointed at by refs are
guaranteed to be complete [an object is "complete" if no object
that can be reachable is not missing]).
This is needed because the repository might have discarded
branch that used to reach 'bar', and while the object 'bar' was
in a pack but some of its ancestors or component trees and/or
blobs were loose and subsequent git-prune have removed the
latter without removing 'bar'. Mere existence of the object
'bar' does not mean 'bar' is complete.
So coming up with such a pair of programs is not a rocket
science, but it is fairly delicate. I would rather have them as
specialized commands, not a part of everyday commands, even if
you were to implement it.
Since this is not everyday anyway, a far easier way would be to
clone-pack from the upstream into a new repository, take the
pack you downloaded from that new repository and mv it into your
corrupt repository. You can run fsck-objects to see if you got
back everything you lost earlier.
^ permalink raw reply
* Re: [PATCH] Adapt to fuse in kernel 2.6.17
From: Junio C Hamano @ 2006-11-12 19:43 UTC (permalink / raw)
To: Jeff Garzik; +Cc: git
In-Reply-To: <455776A7.6050707@garzik.org>
Jeff Garzik <jeff@garzik.org> writes:
> Robin Rosenberg wrote:
>> This was a patch to GITFS, which may be somewhat unclear from the
>> Subject line :)
>
> I blinked, and I missed it. Where can I find gitfs? I've long
> thought about doing something like that myself.
http://git.or.cz/gitwiki/InterfacesFrontendsAndTools lists it at
http://www.sfgoth.com/~mitch/linux/gitfs/
Fuse seems to be fun.
^ permalink raw reply
* Re: [PATCH] Adapt to fuse in kernel 2.6.17
From: Robin Rosenberg @ 2006-11-12 20:01 UTC (permalink / raw)
To: Jeff Garzik; +Cc: git
In-Reply-To: <455776A7.6050707@garzik.org>
söndag 12 november 2006 20:31 skrev Jeff Garzik:
> Robin Rosenberg wrote:
> > This was a patch to GITFS, which may be somewhat unclear from the Subject
> > line :)
>
> I blinked, and I missed it. Where can I find gitfs? I've long thought
> about doing something like that myself.
It's listed on the wiki and located at
http://www.sfgoth.com/~mitch/linux/gitfs/
^ permalink raw reply
* Re: Shallow clone
From: Junio C Hamano @ 2006-11-12 20:04 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20061112131209.GC7201@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> On Wed, Nov 08, 2006 at 06:59:05PM CET, Aneesh Kumar K.V wrote:
>> diff --git a/Documentation/repository-layout.txt b/Documentation/repository-layout.txt
>> index 275d18b..03a6f77 100644
>> --- a/Documentation/repository-layout.txt
>> +++ b/Documentation/repository-layout.txt
>> @@ -141,3 +141,9 @@ logs/refs/heads/`name`::
>>
>> logs/refs/tags/`name`::
>> Records all changes made to the tag named `name`.
>> +
>> +shallow::
>
> Hmm, shouldn't the shallow file rather belong to the info/ subdirectory?
I think that makes sense.
^ permalink raw reply
* [StGIT PATCH 0/2] mail and import tests
From: Karl Hasselström @ 2006-11-12 21:14 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0611080212q35dae8d0w2642ed1d0189f8fe@mail.gmail.com>
Tests for "stg import" and "stg mail". The later test is not very
ambitious, but it can always be extended later.
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply
* [StGIT PATCH 2/2] Regression test for "stg mail"
From: Karl Hasselström @ 2006-11-12 21:15 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20061112211434.19362.66077.stgit@localhost>
From: Karl Hasselström <kha@treskal.com>
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
t/t1900-mail.sh | 34 ++++++++++++++++++++++++++++++++++
1 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/t/t1900-mail.sh b/t/t1900-mail.sh
new file mode 100755
index 0000000..6a950b4
--- /dev/null
+++ b/t/t1900-mail.sh
@@ -0,0 +1,34 @@
+#!/bin/sh
+# Copyright (c) 2006 Karl Hasselström
+test_description='Test the mail command'
+. ./test-lib.sh
+
+test_expect_success \
+ 'Initialize the StGIT repository' \
+ '
+ for i in 1 2 3 4 5; do
+ touch foo.txt &&
+ echo "line $i" >> foo.txt &&
+ git add foo.txt &&
+ git commit -a -m "Patch $i"
+ done &&
+ stg init &&
+ stg uncommit -n 5 foo
+ '
+
+test_expect_success \
+ 'Put all the patches in an mbox' \
+ 'stg mail --to="Inge Ström <inge@example.com>" -a -m \
+ -t ../../templates/patchmail.tmpl > mbox0'
+
+test_expect_success \
+ 'Import the mbox and compare' \
+ '
+ t1=$(git cat-file -p $(stg id) | grep ^tree)
+ stg pop -a &&
+ stg import -M mbox0 &&
+ t2=$(git cat-file -p $(stg id) | grep ^tree) &&
+ [ "$t1" == "$t2" ]
+ '
+
^ permalink raw reply related
* [StGIT PATCH 1/2] Regression test for "stg import"
From: Karl Hasselström @ 2006-11-12 21:15 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20061112211434.19362.66077.stgit@localhost>
From: Karl Hasselström <kha@treskal.com>
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
t/t1800-import.sh | 85 ++++++++++++++++++++++++++++++++++++++
t/t1800-import/email-8bit | 37 ++++++++++++++++
t/t1800-import/email-mbox | 102 +++++++++++++++++++++++++++++++++++++++++++++
t/t1800-import/email-qp | 37 ++++++++++++++++
t/t1800-import/git-diff | 20 +++++++++
t/t1800-import/gnu-diff | 19 ++++++++
t/t1800-import/stg-export | 26 +++++++++++
7 files changed, 326 insertions(+), 0 deletions(-)
diff --git a/t/t1800-import.sh b/t/t1800-import.sh
new file mode 100755
index 0000000..0c1baa3
--- /dev/null
+++ b/t/t1800-import.sh
@@ -0,0 +1,85 @@
+#!/bin/sh
+# Copyright (c) 2006 Karl Hasselström
+test_description='Test the import command'
+. ./test-lib.sh
+
+test_expect_success \
+ 'Initialize the StGIT repository' \
+ '
+ for x in {do,di,da}{be,bi,bo}{dam,dim,dum}; do
+ echo $x
+ done > foo.txt &&
+ git add foo.txt &&
+ git commit -a -m "initial version" &&
+ stg init
+ '
+
+test_expect_success \
+ 'Apply a patch created with "git diff"' \
+ '
+ stg import ../t1800-import/git-diff &&
+ [ $(git cat-file -p $(stg id) \
+ | grep -c "tree e96b1fba2160890ff600b675d7140d46b022b155") == 1 ] &&
+ stg delete ..
+ '
+
+test_expect_success \
+ 'Apply a patch created with GNU diff' \
+ '
+ stg import ../t1800-import/gnu-diff &&
+ [ $(git cat-file -p $(stg id) \
+ | grep -c "tree e96b1fba2160890ff600b675d7140d46b022b155") == 1 ] &&
+ stg delete ..
+ '
+
+test_expect_success \
+ 'Apply a patch created with "stg export"' \
+ '
+ stg import ../t1800-import/stg-export &&
+ [ $(git cat-file -p $(stg id) \
+ | grep -c "tree e96b1fba2160890ff600b675d7140d46b022b155") == 1 ] &&
+ stg delete ..
+ '
+
+test_expect_success \
+ 'Apply a patch from an 8bit-encoded e-mail' \
+ '
+ stg import -m ../t1800-import/email-8bit &&
+ [ $(git cat-file -p $(stg id) \
+ | grep -c "tree 030be42660323ff2a1958f9ee79589a4f3fbee2f") == 1 ] &&
+ [ $(git cat-file -p $(stg id) \
+ | grep -c "author Inge Ström <inge@power.com>") == 1 ] &&
+ stg delete ..
+ '
+
+test_expect_success \
+ 'Apply a patch from a QP-encoded e-mail' \
+ '
+ stg import -m ../t1800-import/email-qp &&
+ [ $(git cat-file -p $(stg id) \
+ | grep -c "tree 030be42660323ff2a1958f9ee79589a4f3fbee2f") == 1 ] &&
+ [ $(git cat-file -p $(stg id) \
+ | grep -c "author Inge Ström <inge@power.com>") == 1 ] &&
+ stg delete ..
+ '
+
+test_expect_success \
+ 'Apply several patches from an mbox file' \
+ '
+ stg import -M ../t1800-import/email-mbox &&
+ [ $(git cat-file -p $(stg id change-1) \
+ | grep -c "tree 401bef82cd9fb403aba18f480a63844416a2e023") == 1 ] &&
+ [ $(git cat-file -p $(stg id change-1) \
+ | grep -c "author Inge Ström <inge@power.com>") == 1 ] &&
+ [ $(git cat-file -p $(stg id change-2) \
+ | grep -c "tree e49dbce010ec7f441015a8c64bce0b99108af4cc") == 1 ] &&
+ [ $(git cat-file -p $(stg id change-2) \
+ | grep -c "author Inge Ström <inge@power.com>") == 1 ] &&
+ [ $(git cat-file -p $(stg id change-3) \
+ | grep -c "tree 166bbaf27a44aee21ba78c98822a741e6f7d78f5") == 1 ] &&
+ [ $(git cat-file -p $(stg id change-3) \
+ | grep -c "author Inge Ström <inge@power.com>") == 1 ] &&
+ stg delete ..
+ '
+
+test_done
diff --git a/t/t1800-import/email-8bit b/t/t1800-import/email-8bit
new file mode 100644
index 0000000..316fe27
--- /dev/null
+++ b/t/t1800-import/email-8bit
@@ -0,0 +1,37 @@
+From: Inge =?utf-8?q?Str=C3=B6m?= <inge@power.com>
+Subject: [PATCH] test patch
+To: Upstream <foo@bar.baz>
+Date: Sat, 11 Nov 2006 11:58:14 +0100
+Message-ID: <20061111105814.23209.46952.stgit@localhost>
+User-Agent: StGIT/0.11
+MIME-Version: 1.0
+Content-Type: text/plain; charset="utf-8"
+Content-Transfer-Encoding: 8bit
+
+Signed-off-by: Inge Ström <inge@power.com>
+---
+
+ foo.txt | 2 ++
+ 1 files changed, 2 insertions(+), 0 deletions(-)
+
+diff --git a/foo.txt b/foo.txt
+index ad01662..d3cd5b6 100644
+--- a/foo.txt
++++ b/foo.txt
+@@ -3,6 +3,7 @@ dobedim
+ dobedum
+ dobidam
+ dobidim
++pum-pöddelipåm
+ dobidum
+ dobodam
+ dobodim
+@@ -20,6 +21,7 @@ dabedam
+ dabedim
+ dabedum
+ dabidam
++pum-däddelidum
+ dabidim
+ dabidum
+ dabodam
+
diff --git a/t/t1800-import/email-mbox b/t/t1800-import/email-mbox
new file mode 100644
index 0000000..e4103e5
--- /dev/null
+++ b/t/t1800-import/email-mbox
@@ -0,0 +1,102 @@
+From nobody Sat Nov 11 12:45:27 2006
+From: Inge =?utf-8?q?Str=C3=B6m?= <inge@power.com>
+Subject: [PATCH 1/3] Change 1
+To: Upstream <foo@bar.baz>
+Date: Sat, 11 Nov 2006 12:45:27 +0100
+Message-ID: <20061111114527.31778.12942.stgit@localhost>
+User-Agent: StGIT/0.11
+MIME-Version: 1.0
+Content-Type: text/plain; charset="utf-8"
+Content-Transfer-Encoding: 8bit
+Status: RO
+Content-Length: 304
+Lines: 19
+
+Signed-off-by: Inge Ström <inge@power.com>
+---
+
+ foo.txt | 2 +-
+ 1 files changed, 1 insertions(+), 1 deletions(-)
+
+diff --git a/foo.txt b/foo.txt
+index ad01662..91527b1 100644
+--- a/foo.txt
++++ b/foo.txt
+@@ -7,7 +7,7 @@ dobidum
+ dobodam
+ dobodim
+ dobodum
+-dibedam
++dibedad
+ dibedim
+ dibedum
+ dibidam
+
+From nobody Sat Nov 11 12:45:27 2006
+From: Inge =?utf-8?q?Str=C3=B6m?= <inge@power.com>
+Subject: [PATCH 2/3] Change 2
+To: Upstream <foo@bar.baz>
+Date: Sat, 11 Nov 2006 12:45:27 +0100
+Message-ID: <20061111114527.31778.92851.stgit@localhost>
+In-Reply-To: <20061111114527.31778.12942.stgit@localhost>
+References: <20061111114527.31778.12942.stgit@localhost>
+User-Agent: StGIT/0.11
+MIME-Version: 1.0
+Content-Type: text/plain; charset="utf-8"
+Content-Transfer-Encoding: 8bit
+Status: RO
+Content-Length: 296
+Lines: 18
+
+Signed-off-by: Inge Ström <inge@power.com>
+---
+
+ foo.txt | 1 +
+ 1 files changed, 1 insertions(+), 0 deletions(-)
+
+diff --git a/foo.txt b/foo.txt
+index 91527b1..79922d7 100644
+--- a/foo.txt
++++ b/foo.txt
+@@ -18,6 +18,7 @@ dibodim
+ dibodum
+ dabedam
+ dabedim
++dibedam
+ dabedum
+ dabidam
+ dabidim
+
+From nobody Sat Nov 11 12:45:27 2006
+From: Inge =?utf-8?q?Str=C3=B6m?= <inge@power.com>
+Subject: [PATCH 3/3] Change 3
+To: Upstream <foo@bar.baz>
+Date: Sat, 11 Nov 2006 12:45:27 +0100
+Message-ID: <20061111114527.31778.45876.stgit@localhost>
+In-Reply-To: <20061111114527.31778.12942.stgit@localhost>
+References: <20061111114527.31778.12942.stgit@localhost>
+User-Agent: StGIT/0.11
+MIME-Version: 1.0
+Content-Type: text/plain; charset="utf-8"
+Content-Transfer-Encoding: 8bit
+Status: RO
+Content-Length: 278
+Lines: 16
+
+Signed-off-by: Inge Ström <inge@power.com>
+---
+
+ foo.txt | 1 -
+ 1 files changed, 0 insertions(+), 1 deletions(-)
+
+diff --git a/foo.txt b/foo.txt
+index 79922d7..6f978b4 100644
+--- a/foo.txt
++++ b/foo.txt
+@@ -24,5 +24,4 @@ dabidam
+ dabidim
+ dabidum
+ dabodam
+-dabodim
+ dabodum
+
diff --git a/t/t1800-import/email-qp b/t/t1800-import/email-qp
new file mode 100644
index 0000000..1a77c57
--- /dev/null
+++ b/t/t1800-import/email-qp
@@ -0,0 +1,37 @@
+From: Inge =?utf-8?q?Str=C3=B6m?= <inge@power.com>
+Subject: [PATCH] test patch
+To: Upstream <foo@bar.baz>
+Date: Sat, 11 Nov 2006 11:58:14 +0100
+Message-ID: <20061111105814.23209.46952.stgit@localhost>
+User-Agent: StGIT/0.11
+MIME-Version: 1.0
+Content-Type: text/plain; charset="utf-8"
+Content-Transfer-Encoding: quoted-printable
+
+Signed-off-by: Inge Str=C3=B6m <inge@power.com>
+---
+
+ foo.txt | 2 ++
+ 1 files changed, 2 insertions(+), 0 deletions(-)
+
+diff --git a/foo.txt b/foo.txt
+index ad01662..d3cd5b6 100644
+--- a/foo.txt
++++ b/foo.txt
+@@ -3,6 +3,7 @@ dobedim
+ dobedum
+ dobidam
+ dobidim
++pum-p=C3=B6ddelip=C3=A5m
+ dobidum
+ dobodam
+ dobodim
+@@ -20,6 +21,7 @@ dabedam
+ dabedim
+ dabedum
+ dabidam
++pum-d=C3=A4ddelidum
+ dabidim
+ dabidum
+ dabodam
+
diff --git a/t/t1800-import/git-diff b/t/t1800-import/git-diff
new file mode 100644
index 0000000..642e11d
--- /dev/null
+++ b/t/t1800-import/git-diff
@@ -0,0 +1,20 @@
+diff --git a/foo.txt b/foo.txt
+index ad01662..d3cd5b6 100644
+--- a/foo.txt
++++ b/foo.txt
+@@ -3,6 +3,7 @@ dobedim
+ dobedum
+ dobidam
+ dobidim
++dabadadash
+ dobidum
+ dobodam
+ dobodim
+@@ -20,6 +21,7 @@ dabedam
+ dabedim
+ dabedum
+ dabidam
++dadadadash
+ dabidim
+ dabidum
+ dabodam
diff --git a/t/t1800-import/gnu-diff b/t/t1800-import/gnu-diff
new file mode 100644
index 0000000..46b338a
--- /dev/null
+++ b/t/t1800-import/gnu-diff
@@ -0,0 +1,19 @@
+diff -Naur old/foo.txt new/foo.txt
+--- old/foo.txt 2006-11-11 11:26:18.000000000 +0100
++++ new/foo.txt 2006-11-11 11:25:18.000000000 +0100
+@@ -3,6 +3,7 @@
+ dobedum
+ dobidam
+ dobidim
++dabadadash
+ dobidum
+ dobodam
+ dobodim
+@@ -20,6 +21,7 @@
+ dabedim
+ dabedum
+ dabidam
++dadadadash
+ dabidim
+ dabidum
+ dabodam
diff --git a/t/t1800-import/stg-export b/t/t1800-import/stg-export
new file mode 100644
index 0000000..ddcfc3e
--- /dev/null
+++ b/t/t1800-import/stg-export
@@ -0,0 +1,26 @@
+test patch
+---
+
+ foo.txt | 2 ++
+ 1 files changed, 2 insertions(+), 0 deletions(-)
+
+diff --git a/foo.txt b/foo.txt
+index ad01662..d3cd5b6 100644
+--- a/foo.txt
++++ b/foo.txt
+@@ -3,6 +3,7 @@ dobedim
+ dobedum
+ dobidam
+ dobidim
++dabadadash
+ dobidum
+ dobodam
+ dobodim
+@@ -20,6 +21,7 @@ dabedam
+ dabedim
+ dabedum
+ dabidam
++dadadadash
+ dabidim
+ dabidum
^ permalink raw reply related
* [StGIT PATCH] StGIT bash completion
From: Karl Hasselström @ 2006-11-12 21:18 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, Shawn Pearce
From: Karl Hasselström <kha@treskal.com>
A minimal bash completion script for StGIT. It completes the
subcommand names, and options and patch names for some subcommands.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
I'm not good at all at bash programming -- this script was basically
put together by pattern-matching Shawns git completion code -- so
comments are even more welcome than usual.
contrib/stgit-completion.bash | 156 +++++++++++++++++++++++++++++++++++++++++
1 files changed, 156 insertions(+), 0 deletions(-)
diff --git a/contrib/stgit-completion.bash b/contrib/stgit-completion.bash
new file mode 100644
index 0000000..25549fb
--- /dev/null
+++ b/contrib/stgit-completion.bash
@@ -0,0 +1,156 @@
+# bash completion support for StGIT -*- shell-script -*-
+#
+# Copyright (C) 2006, Karl Hasselström <kha@treskal.com>
+# Based on git-completion.sh
+#
+# To use these routines:
+#
+# 1. Copy this file to somewhere (e.g. ~/.stgit-completion.bash).
+#
+# 2. Add the following line to your .bashrc:
+# . ~/.stgit-completion.bash
+
+# The path to .git, or empty if we're not in a repository.
+_gitdir ()
+{
+ echo "$(git rev-parse --git-dir 2>/dev/null)"
+}
+
+# Name of the current branch, or empty if there isn't one.
+_current_branch ()
+{
+ local b=$(git symbolic-ref HEAD 2>/dev/null)
+ echo ${b#refs/heads/}
+}
+
+# List of all applied patches.
+_applied_patches ()
+{
+ local g=$(_gitdir)
+ [ "$g" ] && cat "$g/patches/$(_current_branch)/applied"
+}
+
+# List of all unapplied patches.
+_unapplied_patches ()
+{
+ local g=$(_gitdir)
+ [ "$g" ] && cat "$g/patches/$(_current_branch)/unapplied"
+}
+
+# List of all patches.
+_all_patches ()
+{
+ local b=$(_current_branch)
+ local g=$(_gitdir)
+ [ "$g" ] && cat "$g/patches/$b/applied" "$g/patches/$b/unapplied"
+}
+
+# List of all patches except the current patch.
+_all_other_patches ()
+{
+ local b=$(_current_branch)
+ local g=$(_gitdir)
+ [ "$g" ] && cat "$g/patches/$b/applied" "$g/patches/$b/unapplied" \
+ | grep -v "^$(< $g/patches/$b/current)$"
+}
+
+# Generate completions for patches and patch ranges from the given
+# patch list function, and options from the given list.
+_complete_patch_range ()
+{
+ local patchlist="$1" options="$2"
+ local pfx cur="${COMP_WORDS[COMP_CWORD]}"
+ case "$cur" in
+ *..*)
+ pfx="${cur%..*}.."
+ cur="${cur#*..}"
+ COMPREPLY=($(compgen -P "$pfx" -W "$($patchlist)" -- "$cur"))
+ ;;
+ *)
+ COMPREPLY=($(compgen -W "$options $($patchlist)" -- "$cur"))
+ ;;
+ esac
+}
+
+# Generate completions for options from the given list.
+_complete_options ()
+{
+ local options="$1"
+ COMPREPLY=($(compgen -W "$options" -- "${COMP_WORDS[COMP_CWORD]}"))
+}
+
+_stg_delete ()
+{
+ _complete_patch_range _all_patches "--branch --help"
+}
+
+_stg_goto ()
+{
+ _complete_patch_range _all_other_patches "--help"
+}
+
+_stg_mail ()
+{
+ _complete_patch_range _all_patches \
+ "--all --to --cc --bcc --auto --noreply --version --prefix --template \
+ --cover --edit-cover --edit-patches --sleep --refid --smtp-user \
+ --smtp-password --branch --mbox --help"
+}
+
+_stg_new ()
+{
+ _complete_options "--message --showpatch --author --authname --authemail \
+ --authdate --commname --commemail --help"
+}
+
+_stg_pop ()
+{
+ _complete_patch_range _applied_patches "--all --number --keep --help"
+}
+
+_stg_push ()
+{
+ _complete_patch_range _unapplied_patches "--all --number --reverse \
+ --merged --undo --help"
+}
+
+_stg_status ()
+{
+ _complete_options "--modified --new --deleted --conflict --unknown \
+ --noexclude --reset --help"
+}
+
+_stg ()
+{
+ local i c=1 command
+
+ while [ $c -lt $COMP_CWORD ]; do
+ if [ $c == 1 ]; then
+ command="${COMP_WORDS[c]}"
+ fi
+ c=$((++c))
+ done
+
+ # Complete name of subcommand.
+ if [ $c -eq $COMP_CWORD -a -z "$command" ]; then
+ COMPREPLY=($(compgen \
+ -W "--help --version \
+ $(stg help|grep '^ '|sed 's/ *\([^ ]\) .*/\1/')" \
+ -- "${COMP_WORDS[COMP_CWORD]}"))
+ return;
+ fi
+
+ # Complete arguments to subcommands.
+ case "$command" in
+ delete) _stg_delete ;;
+ goto) _stg_goto ;;
+ mail) _stg_mail ;;
+ new) _stg_new ;;
+ pop) _stg_pop ;;
+ push) _stg_push ;;
+ status) _stg_status ;;
+ *) COMPREPLY=() ;;
+ esac
+}
+
^ permalink raw reply related
* [PATCH] git-update-index(1): fix use of quoting in section title
From: Jonas Fonseca @ 2006-11-12 21:28 UTC (permalink / raw)
To: git
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
Documentation/git-update-index.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt
index 41bb7e1..0e0a3af 100644
--- a/Documentation/git-update-index.txt
+++ b/Documentation/git-update-index.txt
@@ -216,8 +216,8 @@ $ git ls-files -s
------------
-Using "assume unchanged" bit
-----------------------------
+Using ``assume unchanged'' bit
+------------------------------
Many operations in git depend on your filesystem to have an
efficient `lstat(2)` implementation, so that `st_mtime`
--
1.4.3.3.g9621-dirty
--
^ permalink raw reply related
* Re: Shallow clone
From: Junio C Hamano @ 2006-11-12 21:59 UTC (permalink / raw)
To: Sergey Vlasov; +Cc: Alexandre Julliard, Aneesh Kumar K.V, git
In-Reply-To: <20061112205909.f8951300.vsu@altlinux.ru>
Sergey Vlasov <vsu@altlinux.ru> writes:
> This is due to optimization in builtin-pack-objects.c:try_delta():
>
> /*
> * We do not bother to try a delta that we discarded
> * on an earlier try, but only when reusing delta data.
> */
> if (!no_reuse_delta && trg_entry->in_pack &&
> trg_entry->in_pack == src_entry->in_pack)
> return 0;
>
> After removing this part the shallow pack after clone is 2.6M, as it
> should be.
>
> The problem with this optimization is that it is only valid if we are
> repacking either the same set of objects as we did earlier, or its
> superset. But if we are packing a subset of objects, there will be some
> objects in that subset which were delta-compressed in the original pack,
> but base objects for that deltas are not included in our subset -
> therefore we will be unable to reuse existing deltas, and with that
> optimization we will never try to use delta compression for these
> objects.
> ...
> So any partial fetch (shallow or not) from a mostly packed repository
> currently results in a suboptimal pack.
That is correct. How about something like this?
I think the determination of "repacking_superset" may need to be
tweaked because existing packs may have overlaps, and the patch
counts them once per pack.
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 69e5dd3..fb25124 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -64,6 +64,7 @@ struct object_entry {
static unsigned char object_list_sha1[20];
static int non_empty;
static int no_reuse_delta;
+static int repacking_superset;
static int local;
static int incremental;
static int allow_ofs_delta;
@@ -1172,10 +1173,13 @@ static int try_delta(struct unpacked *tr
return -1;
/*
- * We do not bother to try a delta that we discarded
- * on an earlier try, but only when reusing delta data.
+ * When we are packing the superset of objects we have already
+ * packed, we do not bother to try a delta that we discarded
+ * on an earlier try. This heuristic of course should not
+ * kick in when we are not reusing delta, or we know we are
+ * sending a subset of objects from a repository.
*/
- if (!no_reuse_delta && trg_entry->in_pack &&
+ if (!no_reuse_delta && repacking_superset && trg_entry->in_pack &&
trg_entry->in_pack == src_entry->in_pack)
return 0;
@@ -1493,6 +1497,16 @@ static void get_object_list(int ac, cons
traverse_commit_list(&revs, show_commit, show_object);
}
+static int count_packed_objects(void)
+{
+ struct packed_git *p;
+ int cnt = 0;
+
+ for (p = packed_git; p; p = p->next)
+ cnt += num_packed_objects(p);
+ return cnt;
+}
+
int cmd_pack_objects(int argc, const char **argv, const char *prefix)
{
SHA_CTX ctx;
@@ -1631,6 +1645,8 @@ int cmd_pack_objects(int argc, const cha
if (non_empty && !nr_result)
return 0;
+ repacking_superset = count_packed_objects() < nr_result;
+
SHA1_Init(&ctx);
list = sorted_by_sha;
for (i = 0; i < nr_result; i++) {
^ permalink raw reply related
* Re: What's in git.git
From: Johannes Schindelin @ 2006-11-12 22:25 UTC (permalink / raw)
To: David Lang; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0611072009220.2601@qynat.qvtvafvgr.pbz>
Hi,
On Tue, 7 Nov 2006, David Lang wrote:
> On Tue, 7 Nov 2006, Junio C Hamano wrote:
>
> > [pu]
> >
> > Johannes's shallow clone work now should rebase cleanly on top
> > of 'master' although I haven't done so yet. As he said
> > himself the series is waiting for people who have needs for
> > such a feature to raise hands.
>
> I haven't been watching this recently, but if this is what I understand it to
> be (the ability to get a partial repository from upstream and work normally
> from there with the result of data-mineing tools sometimes reporting 'that's
> part of the truncated history' if they hit the cutoff) consider my hand
> raised.
For now, it does not say "part of the truncated history". But yes, shallow
clones are partial copies of remote repositories, by making some commits
"shallow", i.e. grafting an empty set of parents onto them (thereby
pretending that these commits are root commits).
Telling the user that a commit is shallow should not be too hard.
Ciao,
Dscho
^ permalink raw reply
* Re: StGIT repository not clonable?
From: Horst H. von Brand @ 2006-11-12 16:17 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Horst H. von Brand, catalin.marinas, git
In-Reply-To: <20061111123634.GD11224@diana.vm.bytemark.co.uk>
Karl Hasselström <kha@treskal.com> wrote:
> On 2006-11-11 00:56:47 -0300, Horst H. von Brand wrote:
> > I'm trying to update my StGIT repo here, and get a crash from
> > git-http-fetch (git 1.4.3.4). Trying to clone it anew gives:
> >
> > [vonbrand@laptop13 tmp]$ git-clone http://homepage.ntlworld.com/cmarinas/stgit.git
> > error: Unable to start request
> > error: Could not interpret heads/master as something to pull
> >
> > What am I doing wrong?
>
> It works for me, with
>
> $ git --version
> git version 1.4.3.3.g8387
Here it is 1.4.3.4 or 1.4.4.rc2, selfbuilt on i386 (Fedora rawhide up to
date). On sparc, at least 1.4.3.4 works for updating.
> But it's horribly slow. Catalin, have you ever packed that repository?
That isn't the issue for me at least...
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
^ permalink raw reply
* Re: StGIT repository not clonable?
From: Horst H. von Brand @ 2006-11-13 0:12 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Karl Hasselström, git
In-Reply-To: <b0943d9e0611111359t994d688w9bc6aae8e9183fd3@mail.gmail.com>
Catalin Marinas <catalin.marinas@gmail.com> wrote:
> On 11/11/06, Karl Hasselström <kha@treskal.com> wrote:
> > On 2006-11-11 00:56:47 -0300, Horst H. von Brand wrote:
> > > I'm trying to update my StGIT repo here, and get a crash from
> > > git-http-fetch (git 1.4.3.4). Trying to clone it anew gives:
> >
> > It works for me, with
> >
> > $ git --version
> > git version 1.4.3.3.g8387
[...]
> Anyway, thanks to Pasky, you can now pull/clone it over the git
> protocol directly - git://repo.or.cz/stgit.git. This repository is up
> to date. I have a plan to move the main StGIT repository to Pasky's
> server but I'm a bit busy with other things at the moment.
Thanks! But the failure to pull/clone the original would mean something is
wrong with your HTTP repo then (or my git setup). Nobody else seeing this?
Strangely, other HTTP repos (e.g., <http://jonas.nitro.dk/tig/tig.git>,
<http://www.spearce.org/projects/scm/pg.git>) work fine. Perhaps git gets
miscompiled with gcc-4.1.1-32 and CFLAGS='-O2 -fomit-frame-pointer' on
i386?
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
^ permalink raw reply
* Getting new branches from remote repo.
From: Alexander Litvinov @ 2006-11-13 4:33 UTC (permalink / raw)
To: git
Hello list,
I have a trouble I don't know how to solve. When I am cloning remote
repo I automatically get all it's branches stored at my repo (they are
listed at .git/remotes/origin). When someone adds new branch(es) to
remote repo git pull (git fetch) does not automatically add them to my
repo. I have a tool to list all remote branches (git ls-remote --heads
origin) but I can't find how to add interesting (or all) branches to
by repo.
By the way, how can I clone remote repo created by cloning another
repo using git clone --use-separate-remotes ? Even git ls-remote
--heads origin does not show all branches taken from that another
repo.
^ permalink raw reply
* Re: [PATCH] Rework cvsexportcommit to handle binary files for all cases.
From: Junio C Hamano @ 2006-11-13 4:39 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <200611121629.43104.robin.rosenberg@dewire.com>
Robin Rosenberg <robin.rosenberg@dewire.com> writes:
> Now adding, removing and changing binary files works. I added
> test cases to make sure qit works and can be verified by
> others. Som other corner cases were resolved too.
>
> Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
Thanks.
It is necessary to clarify what these other corner cases are in
the commit log message. Three months down the road you yourself
would not remember what they were.
You seem to like:
my $p = "m,^$pathname\$,";
if (grep $p,@array) { do this... }
but this is a bad habit. $pathname can contain regexp
metacharacters or a comma. You should just say:
if (grep { $_ eq $pathname } @arrray) { do this... }
instead. I'd fix them up with the attached patch.
It would also be nice to rework this program so that it can work
with whitespaces in pathnames. I do not think it currently
works with them at all.
It appears that this program was never used in western
hemisphere, by the way ;-).
---
diff --git a/git-cvsexportcommit.perl b/git-cvsexportcommit.perl
index 78c847e..b1cc014 100755
--- a/git-cvsexportcommit.perl
+++ b/git-cvsexportcommit.perl
@@ -1,10 +1,10 @@
#!/usr/bin/perl -w
# Known limitations:
-# - cannot add or remove binary files
# - does not propagate permissions
# - tells "ready for commit" even when things could not be completed
# (eg addition of a binary file)
+# - does not handle whitespace in pathnames at all.
use strict;
use Getopt::Std;
@@ -68,9 +68,9 @@ foreach my $line (@commit) {
if ($stage eq 'headers') {
if ($line =~ m/^parent (\w{40})$/) { # found a parent
push @parents, $1;
- } elsif ($line =~ m/^author (.+) \d+ \+\d+$/) {
+ } elsif ($line =~ m/^author (.+) \d+ [-+]\d+$/) {
$author = $1;
- } elsif ($line =~ m/^committer (.+) \d+ \+\d+$/) {
+ } elsif ($line =~ m/^committer (.+) \d+ [-+]\d+$/) {
$committer = $1;
}
} else {
@@ -165,8 +165,8 @@ foreach my $d (@dirs) {
foreach my $f (@afiles) {
# This should return only one value
if ($f =~ m,(.*)/[^/]*$,) {
- my $p="m,^".$1."\$,";
- next if grep $p,@dirs;
+ my $p = $1;
+ next if (grep { $_ eq $p } @dirs);
}
my @status = grep(m/^File/, safe_pipe_capture('cvs', '-q', 'status' ,$f));
if (@status > 1) { warn 'Strange! cvs status returned more than one line?'};
@@ -219,8 +219,7 @@ print "'Patching' binary files\n";
foreach my $f (@bfiles) {
# check that the file in cvs matches the "old" file
# extract the file to $tmpdir and compare with cmp
- my $p="m/^$f$/";
- if (not(grep $p,@afiles)) {
+ if (not(grep { $_ eq $f } @afiles)) {
my $tree = safe_pipe_capture('git-rev-parse', "$parent^{tree}");
chomp $tree;
my $blob = `git-ls-tree $tree "$f" | cut -f 1 | cut -d ' ' -f 3`;
@@ -234,7 +233,7 @@ foreach my $f (@bfiles) {
}
}
}
- if (not(grep m/^$f$/,@dfiles)) {
+ if (not(grep { $_ eq $f } @dfiles)) {
my $tree = safe_pipe_capture('git-rev-parse', "$commit^{tree}");
chomp $tree;
my $blob = `git-ls-tree $tree "$f" | cut -f 1 | cut -d ' ' -f 3`;
@@ -256,7 +255,7 @@ my $fuzz = $opt_p ? 0 : 2;
print "Patching non-binary files\n";
-if (scalar(@afiles)+scalar(@dfiles)+scalar(@mfiles) ne scalar(@bfiles)) {
+if (scalar(@afiles)+scalar(@dfiles)+scalar(@mfiles) != scalar(@bfiles)) {
print `(git-diff-tree -p $parent -p $commit | patch -p1 -F $fuzz ) 2>&1`;
}
@@ -269,7 +268,7 @@ if (($? >> 8) == 2) {
}
foreach my $f (@afiles) {
- if (grep /^$f$/,@bfiles) {
+ if (grep { $_ eq $f } @bfiles) {
system('cvs', 'add','-kb',$f);
} else {
system('cvs', 'add', $f);
^ permalink raw reply related
* Re: Getting new branches from remote repo.
From: Junio C Hamano @ 2006-11-13 4:49 UTC (permalink / raw)
To: Alexander Litvinov; +Cc: git
In-Reply-To: <6e1787fe0611122033p49671e13xf5b7f95beeba8b06@mail.gmail.com>
"Alexander Litvinov" <litvinov2004@gmail.com> writes:
> I have a trouble I don't know how to solve. When I am cloning remote
> repo I automatically get all it's branches stored at my repo (they are
> listed at .git/remotes/origin). When someone adds new branch(es) to
> remote repo git pull (git fetch) does not automatically add them to my
> repo. I have a tool to list all remote branches (git ls-remote --heads
> origin) but I can't find how to add interesting (or all) branches to
> by repo.
After finding out $that_new_branch's name, add either
Pull: refs/heads/$that_new_branch:refs/heads/$that_new_branch
or if you are in "separate remote" school, then perhaps
Pull: refs/heads/$that_new_branch:refs/remotes/origin/$that_new_branch
to .git/remotes/origin and running git fetch would give you what
you want, I think.
> By the way, how can I clone remote repo created by cloning another
> repo using git clone --use-separate-remotes ? Even git ls-remote
> --heads origin does not show all branches taken from that another
> repo.
Well, the point of "separate remote" is not to pollute local
heads/ namespace with refs that merely track remote repository,
so if you say "ls-remote --heads" you would not see them. They
are not "heads" in that repository.
You would still see them if you say "ls-remote" without --heads.
^ permalink raw reply
* Re: [StGIT PATCH] StGIT bash completion
From: Shawn Pearce @ 2006-11-13 5:04 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Catalin Marinas, git
In-Reply-To: <20061112211813.19959.73406.stgit@localhost>
Karl Hasselstr?m <kha@treskal.com> wrote:
> From: Karl Hasselström <kha@treskal.com>
>
> A minimal bash completion script for StGIT. It completes the
> subcommand names, and options and patch names for some subcommands.
>
> Signed-off-by: Karl Hasselström <kha@treskal.com>
> ---
>
> I'm not good at all at bash programming -- this script was basically
> put together by pattern-matching Shawns git completion code -- so
> comments are even more welcome than usual.
I'm not an StGIT user, but this looks pretty good.
--
^ permalink raw reply
* Re: gitk broken or user error?
From: Shawn Pearce @ 2006-11-13 5:20 UTC (permalink / raw)
To: Seth Falcon; +Cc: git
In-Reply-To: <m2irhkr467.fsf@ziti.local>
Seth Falcon <sethfalcon@gmail.com> wrote:
> I get the following error when invoking gitk with any command line
> argument, for example, 'gitk --all':
>
> ziti:~/proj/R-devel seth$ gitk --all
> Error in startup script: unknown option "-state"
> while executing
> ".bar.view entryconf 3 -state normal"
> invoked from within
> "if {$cmdline_files ne {} || $revtreeargs ne {}} {
> # create a view for the files/dirs specified on the command line
> set curview 1
> set selec..."
> (file "/Users/seth/scm/bin/gitk" line 6298)
You are not alone on this. I see the same thing on my Mac and it
makes it quite difficult to use gitk. However the same version of
gitk does not have this problem on Windows. Its clearly related
to platform differences.
Of course Windows is unable to open a gitk window without it
being collapsed down to only the titlebar, and is also unable to
sucessfully reread the user's ~/.gitk file, but that's another bug...
I really should try to figure out what these problems are, but gitk
is 6323 lines of Tcl/Tk code which I'm not all too familiar with,
and I've got my own growing mass of ~2473 lines of Tcl/Tk code in
git-gui to worry about right now...
--
^ permalink raw reply
* Re: Shallow clone
From: Junio C Hamano @ 2006-11-13 5:29 UTC (permalink / raw)
To: Sergey Vlasov; +Cc: git
In-Reply-To: <7vd57scong.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Sergey Vlasov <vsu@altlinux.ru> writes:
>
>> This is due to optimization in builtin-pack-objects.c:try_delta():
>>
>> /*
>> * We do not bother to try a delta that we discarded
>> * on an earlier try, but only when reusing delta data.
>> */
>> if (!no_reuse_delta && trg_entry->in_pack &&
>> trg_entry->in_pack == src_entry->in_pack)
>> return 0;
>>
>> After removing this part the shallow pack after clone is 2.6M, as it
>> should be.
>>
>> The problem with this optimization is that it is only valid if we are
>> repacking either the same set of objects as we did earlier, or its
>> superset. But if we are packing a subset of objects, there will be some
>> objects in that subset which were delta-compressed in the original pack,
>> but base objects for that deltas are not included in our subset -
>> therefore we will be unable to reuse existing deltas, and with that
>> optimization we will never try to use delta compression for these
>> objects.
>> ...
>> So any partial fetch (shallow or not) from a mostly packed repository
>> currently results in a suboptimal pack.
What we tried to avoid with the original heuristics in commit
51d1e83f was to avoid wasting time on undeltifiable blobs, and
they would be stored as base in the original packs, so I think
the following would fly better (the patch is for maint, for
master we would also check for OBJ_REF_DELTA as well).
---
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 96c069a..84a8749 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -1101,7 +1101,8 @@ static int try_delta(struct unpacked *tr
* on an earlier try, but only when reusing delta data.
*/
if (!no_reuse_delta && trg_entry->in_pack &&
- trg_entry->in_pack == src_entry->in_pack)
+ trg_entry->in_pack == src_entry->in_pack &&
+ trg_entry->in_pack_type != OBJ_DELTA)
return 0;
/*
^ permalink raw reply related
* Re: Getting new branches from remote repo.
From: Alexander Litvinov @ 2006-11-13 5:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8xigar36.fsf@assigned-by-dhcp.cox.net>
> After finding out $that_new_branch's name, add either
>
> Pull: refs/heads/$that_new_branch:refs/heads/$that_new_branch
> You would still see them if you say "ls-remote" without --heads.
Thanks for help, these commands solve my trouble:
1. Get remote branches by 'git ls-remote origin refs/remotes/*'
2. Fetch needed branch by adding: 'Pull:
refs/remotes/origin/BRANCH:refs/heads/BRANCH' into .git/remotes/origin
Is there any way to automaticly edit .git/remotes/origin before
^ permalink raw reply
* Re: Getting new branches from remote repo.
From: Karl Hasselström @ 2006-11-13 9:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alexander Litvinov, git
In-Reply-To: <7v8xigar36.fsf@assigned-by-dhcp.cox.net>
On 2006-11-12 20:49:33 -0800, Junio C Hamano wrote:
> "Alexander Litvinov" <litvinov2004@gmail.com> writes:
>
> > I have a trouble I don't know how to solve. When I am cloning
> > remote repo I automatically get all it's branches stored at my
> > repo (they are listed at .git/remotes/origin). When someone adds
> > new branch(es) to remote repo git pull (git fetch) does not
> > automatically add them to my repo. I have a tool to list all
> > remote branches (git ls-remote --heads origin) but I can't find
> > how to add interesting (or all) branches to by repo.
>
> After finding out $that_new_branch's name, add either
>
> Pull: refs/heads/$that_new_branch:refs/heads/$that_new_branch
>
> or if you are in "separate remote" school, then perhaps
>
> Pull: refs/heads/$that_new_branch:refs/remotes/origin/$that_new_branch
>
> to .git/remotes/origin and running git fetch would give you what you
> want, I think.
There really should be a flag to make git fetch do this job. And if we
use separate remotes, the flag should probably default to "on".
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply
* Re: [ANNOUNCE] qgit-1.5.3
From: Andreas Ericsson @ 2006-11-13 11:30 UTC (permalink / raw)
To: Marco Costalba; +Cc: Git Mailing List, linux-kernel
In-Reply-To: <e5bfff550611110006p44494ed4h2979232bfc8e957c@mail.gmail.com>
Marco Costalba wrote:
>
> Download tarball from http://www.sourceforge.net/projects/qgit
> or directly from git public repository
> git://git.kernel.org/pub/scm/qgit/qgit.git
>
Love the tool, but can't fetch the tag. Did you forget to
$ git push origin 1.5.3
?
git describe tells me that I have qgit-1.5.2-gb764f9b
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: [PATCH] FIX git pull failure with shallow clone changes
From: Johannes Schindelin @ 2006-11-13 12:26 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: git
In-Reply-To: <45541BBE.4070303@gmail.com>
Hi,
I overlooked that the http transport uses the variable "depth" already,
which your patch fixes.
Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Ciao,
Dscho
^ permalink raw reply
* Re: win2k/cygwin cannot handle even moderately sized packs
From: Johannes Schindelin @ 2006-11-13 12:45 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0611070302h50541cd5mf0758afe0d6befda@mail.gmail.com>
Hi,
On Tue, 7 Nov 2006, Alex Riesen wrote:
> For me, it fails even on 332Mb pack:
>
> $ git reset --hard 61bb7fcb
> fatal: packfile .git/objects/pack/pack-ad37...pack cannot be mapped.
>
> Instrumenting the code reveals that it fails on 348876870 bytes.
> Strangely enough, a cygwin program which just reads that pack
> many times without freeing the mem goes up to 1395507480 (1330Mb).
>
> If I replace the malloc (cygwin) with native VirtualAlloc(MEM_COMMIT)
> it reports that "Not enough storage is available to process this command",
> which is just ENOMEM, I think.
This looks to me as if you have NO_MMAP=1 set in your Makefile (which I
also do automatically when compiling on cygwin).
The old problem: Windows does not have fork.
<digression> And before somebody starts cygwin bashing: don't. It is not
cygwin's problem, it is Windows'. The cygwin people worked long and hard
on something truly useful, and it helps me _every_ time I have to work on
a Windows platform (which _is_ utter crap). Some problems of Windows are
so unhideable though, that even cygwin cannot work around them.
</digression>
Cygwin provides a mmap(), which works remarkably well even with the
emulated fork(), but one thing is not possible: since mmap()ed files
have to be _reopened_ after a fork(), and git uses the
open-temp-file-then-delete-it-but-continue-to-use-it paradigm quite often,
we work around it by setting NO_MMAP=1. Again, this is _not_ Cygwin's
fault!
And I think that a mmap() of 332MB would not fail.
Long time ago (to be precise, July 18th), Linus suggested (in Message-Id:
<Pine.LNX.4.64.0607180837260.3386@evo.osdl.org>) to find out which mmap()
calls are _not_ used before a fork(), and not emulate them by malloc().
I never came around to do that, but maybe others do?
Ciao,
Dscho
^ 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