* Re: Change in "git checkout" behaviour between 1.6.0.2 and 1.6.0.3
From: Bruce Stephens @ 2008-11-12 17:44 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git, Junio C Hamano
In-Reply-To: <491B131D.2050501@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
[...]
> Bisecting gives:
>
>
> 5521883490e85f4d973141972cf16f89a79f1979 is first bad commit
> commit 5521883490e85f4d973141972cf16f89a79f1979
> Author: Junio C Hamano <gitster@pobox.com>
> Date: Sun Sep 7 19:49:25 2008 -0700
>
> checkout: do not lose staged removal
I got the same, which is reassuring.
Looks like a deliberate change with (what seems to me to be) an
unfortunate interaction with "git clone -n"
^ permalink raw reply
* Re: [PATCH] fix pack.packSizeLimit and --max-pack-size handling
From: Junio C Hamano @ 2008-11-12 17:46 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jon Nelson, git
In-Reply-To: <alpine.LFD.2.00.0811121109420.27509@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> First, pack.packSizeLimit and --max-pack-size didn't use the same base
> unit which was confusing. They both use MiB now.
>
> Also, if the limit was sufficiently low, having a single object written
> could bust the limit (by design), but caused the remaining allowed size
> to go negative for subsequent objects, which for an unsigned variable is
> a rather huge limit.
>
> Signed-off-by: Nicolas Pitre <nico@cam.org>
> ---
> @@ -1844,7 +1848,7 @@ static int git_pack_config(const char *k, const char *v, void *cb)
> return 0;
> }
> if (!strcmp(k, "pack.packsizelimit")) {
> - pack_size_limit_cfg = git_config_ulong(k, v);
> + pack_size_limit_cfg = git_config_ulong(k, v) * 1024 * 1024;
The fix to tweak the limit for subsequent split pack is a good thing to
have, but this change would break existing repositories where people
specified 20971520 (or worse yet "20m") to limit the size to 20MB.
I think --max-pack-size is what should be fixed to use git_parse_ulong()
to match the configuration, if you find the discrepancy disturbing.
^ permalink raw reply
* Re: [PATCH] contrib/hooks/post-receive-email: send individual mails to recipients
From: Junio C Hamano @ 2008-11-12 17:49 UTC (permalink / raw)
To: Michael Adam; +Cc: git, Andy Parkins
In-Reply-To: <E1L0ITB-00Bv9t-72@intern.SerNet.DE>
Michael Adam <obnox@samba.org> writes:
> This changes the behaviour of post-receive-email when a list of recipients
> (separated by commas) is specified as hooks.mailinglist. With this modification,
> an individual mail is sent out for each recipient entry in the list, instead
> of sending a single mail with all the recipients in the "To: " field.
Why can that be an improvement?
^ permalink raw reply
* Re: Newbie questions regarding jgit
From: Farrukh Najmi @ 2008-11-12 17:56 UTC (permalink / raw)
To: git
In-Reply-To: <491AE91C.4020402@wellfleetsoftware.com>
So far I have figured out how to get the treeWalk for the path filter as
shown below.
Now I am lost as to how to get the blob associated with the treeWalk.
TIA for your help.
/**
* Gets the content of specified file in git Repo.
*
* @parameter relativePath the relative path in jitRepo for desired
file to get
* @parameter versionName the versionName for the desired file. It
will be unmarshalled from String to ObjectId.
* @return the content of the desired file version packaged as a
DataHandler.
*/
public DataHandler get(String relativePath, String versionName)
throws RepositoryException {
ObjectId retrieveStart = repository.resolve(versionName);
RevWalk revWalk = new RevWalk(repository);
RevCommit entry = revWalk.parseCommit(retrieveStart);
RevTree revTree = entry.getTree();
TreeWalk treeWalk = TreeWalk.forPath(repository,
relativePath, revTree);
//Not sure how to get the blob next
}
Farrukh Najmi wrote:
....
> For my immediate needs, I need to implement a GitRepository class with
> two methods using gjit as shown below. I would appreciate any guidance
> and pseudo-code examples on how to implement these methods. Please
> keep in mind that I am just getting to know git itself and gjit was
> key to my considering git over Mercurial and other distributed VCSs.
>
> public class GitRepositoryManager {
>
> Repository gitRepo;
>
> ...
>
> /**
> * Gets the content of specified file in git Repo.
> *
> * @parameter relativePath the relative path in jitRepo for
> desired file to get
> * @parameter versionName the versionName for the desired file. It
> will be unmarshalled from String to ObjectId.
> * @return the content of the desired file version packaged as a
> DataHandler.
> */
> public DataHandler get(String relativePath, String versionName)
> throws RepositoryException {
> DataHandler dh = null;
>
> ...
> return dh;
> }
>
> /**
> * Creates a new version of specified version of file in git Repo.
> *
> * @parameter relativePath the relative path in jitRepo for
> desired file to get
> * @parameter versionName the versionName for the desired file. It
> will be unmarshalled from String to ObjectId.
> * @parameter content the content of the new version for specified
> file packaged as a DataHandler.
> */
> public void update(String relativePath, String versionName,
> DataHandler content) throws RepositoryException {
> ...
> }
>
> }
>
> Farrukh Najmi wrote:
>> Jonas Fonseca wrote:
>> ...
>>>
>>>> Now I am wondering where to begin to learn how to do the equivalent
>>>> of the
>>>> following commands via the gjit Java API:
>>>>
>>>> * git add /file/
>>>> * git rm /file/
>>>> * git mv /file
>>>> * Whatever is the git way to get a specific version of a file
>>>>
>>>
>>> JGit currently has two APIs for working with the index, which will
>>> allow you to add, remove and move data around in the tree. In nbgit I
>>> ended up using GitIndex, which I found easier to figure out. As I
>>> understand it, in the long run you want to use the DirCache API, but
>>> it is still a work in progress.
>>>
>>
>> I am happy to use GitIndex now and switch to DirCache API later when
>> it is ready.
>> Can I please get some pseudo-code fragments on how to do the use
>> cases I identified above?
>> The javadoc is still not obvious to me.
>>>
>>>> I am hoping that there aremore docs, samples, tutorials etc.
>>>> somewhere that
>>>> I am missing. Thanks for any help you can provide. Some pointers or
>>>> code
>>>> fragments would be terrific.
>>>>
>>>
>>> I started working on a tutorial for JGit, but didn't get very far so
>>> it mostly consists of stub pages.
>>>
>>> - http://code.google.com/docreader/#p=egit&s=egit&t=JGitTutorial
>>>
>>> I have been working on moving the tutorial to maven project before
>>> starting to write the more code heavy topics. This would make it
>>> possible to include code snippets in the tutorial, while also allowing
>>> to compile and test the examples.
>>>
>>
>> The wiki is an awesome resource even in its current state. Thank you.
>> I would be glad to help contribute improvements to wiki if you give me
>> write privilege. What I could do is take the help I get from the list
>> and
>> then update wiki carefully as appropriate if you want me to help.
>>
>> Thanks again to all of you for helping get me bootstrapped with gjit
>> and git.
>>
>
>
--
Regards,
Farrukh Najmi
Web: http://www.wellfleetsoftware.com
^ permalink raw reply
* Re: [PATCH] contrib/hooks/post-receive-email: send individual mails to recipients
From: Michael Adam @ 2008-11-12 17:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael Adam, git, Andy Parkins
In-Reply-To: <7vfxlwq1gn.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 782 bytes --]
Junio C Hamano wrote:
> Michael Adam <obnox@samba.org> writes:
>
> > This changes the behaviour of post-receive-email when a list of recipients
> > (separated by commas) is specified as hooks.mailinglist. With this modification,
> > an individual mail is sent out for each recipient entry in the list, instead
> > of sending a single mail with all the recipients in the "To: " field.
>
> Why can that be an improvement?
My use case is that I have a repository where I want to send
commit messages to an "official" mailing list and to a private
recipient list that might not want to be seen on the official
mailing list.
If this is not generally useful, I could make it optional or
add s/th like a secondary mailing list argument to hooks.
Cheers - Michael
[-- Attachment #2: Type: application/pgp-signature, Size: 206 bytes --]
^ permalink raw reply
* Re: [PATCH] fix pack.packSizeLimit and --max-pack-size handling
From: Jon Nelson @ 2008-11-12 17:58 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <alpine.LFD.2.00.0811121109420.27509@xanadu.home>
On Wed, Nov 12, 2008 at 10:17 AM, Nicolas Pitre <nico@cam.org> wrote:
> First, pack.packSizeLimit and --max-pack-size didn't use the same base
> unit which was confusing. They both use MiB now.
>
> Also, if the limit was sufficiently low, having a single object written
> could bust the limit (by design), but caused the remaining allowed size
> to go negative for subsequent objects, which for an unsigned variable is
> a rather huge limit.
>
> Signed-off-by: Nicolas Pitre <nico@cam.org>
The patch does appear to resolve the issue!
--
Jon
^ permalink raw reply
* [PATCH 4/6] repack: don't repack local objects in packs with .keep file
From: Brandon Casey @ 2008-11-12 17:59 UTC (permalink / raw)
To: gitster; +Cc: peff, git, spearce, nico, Brandon Casey
In-Reply-To: <WFmMnhNsYRw3IUD8hZk59Ll3-y-Spr-gg7enTTiJoZ2xRB8K4w13wAlZBhI9MXJqCLarfq3OODE@cipher.nrlssc.navy.mil>
If the user created a .keep file for a local pack, then it can be inferred
that the user does not want those objects repacked.
This fixes the repack bug tested by t7700.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
git-repack.sh | 2 +-
t/t7700-repack.sh | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-repack.sh b/git-repack.sh
index d39eb6c..8bb2201 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -83,7 +83,7 @@ case ",$all_into_one," in
esac
args="$args $local $quiet $no_reuse$extra"
-names=$(git pack-objects --non-empty --all --reflog $args </dev/null "$PACKTMP") ||
+names=$(git pack-objects --honor-pack-keep --non-empty --all --reflog $args </dev/null "$PACKTMP") ||
exit 1
if [ -z "$names" ]; then
if test -z "$quiet"; then
diff --git a/t/t7700-repack.sh b/t/t7700-repack.sh
index 7aaff0b..356afe3 100755
--- a/t/t7700-repack.sh
+++ b/t/t7700-repack.sh
@@ -4,7 +4,7 @@ test_description='git repack works correctly'
. ./test-lib.sh
-test_expect_failure 'objects in packs marked .keep are not repacked' '
+test_expect_success 'objects in packs marked .keep are not repacked' '
echo content1 > file1 &&
echo content2 > file2 &&
git add . &&
--
1.6.0.3.552.g12334
^ permalink raw reply related
* [PATCH 6/6] builtin-gc.c: use new pack_keep bitfield to detect .keep file existence
From: Brandon Casey @ 2008-11-12 17:59 UTC (permalink / raw)
To: gitster; +Cc: peff, git, spearce, nico, Brandon Casey
In-Reply-To: <WFmMnhNsYRw3IUD8hZk59At-5jc1rZU5GaB35sb1epRZ6zwd7IMw9V94SQyEliIEyriM4J5j3AM@cipher.nrlssc.navy.mil>
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
builtin-gc.c | 12 +-----------
1 files changed, 1 insertions(+), 11 deletions(-)
diff --git a/builtin-gc.c b/builtin-gc.c
index 7af65bb..781df60 100644
--- a/builtin-gc.c
+++ b/builtin-gc.c
@@ -131,19 +131,9 @@ static int too_many_packs(void)
prepare_packed_git();
for (cnt = 0, p = packed_git; p; p = p->next) {
- char path[PATH_MAX];
- size_t len;
- int keep;
-
if (!p->pack_local)
continue;
- len = strlen(p->pack_name);
- if (PATH_MAX <= len + 1)
- continue; /* oops, give up */
- memcpy(path, p->pack_name, len-5);
- memcpy(path + len - 5, ".keep", 6);
- keep = access(p->pack_name, F_OK) && (errno == ENOENT);
- if (keep)
+ if (p->pack_keep)
continue;
/*
* Perhaps check the size of the pack and count only
--
1.6.0.3.552.g12334
^ permalink raw reply related
* [PATCH 5/6] repack: do not fall back to incremental repacking with [-a|-A]
From: Brandon Casey @ 2008-11-12 17:59 UTC (permalink / raw)
To: gitster; +Cc: peff, git, spearce, nico, Brandon Casey
In-Reply-To: <WFmMnhNsYRw3IUD8hZk59PVSBNnWW0Ot3Am0gtsYesn_-APZGMYcRjOXaJqcBZo4pwvAKF-s_s0@cipher.nrlssc.navy.mil>
When repack is called with either the -a or -A option, the user has
requested to repack all objects including those referenced by the
alternates mechanism. Currently, if there are no local packs without
.keep files, then repack will call pack-objects with the
'--unpacked --incremental' options which causes it to exclude alternate
packed objects. So, remove this fallback.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
git-repack.sh | 11 ++++-------
1 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/git-repack.sh b/git-repack.sh
index 8bb2201..4d313d1 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -71,13 +71,10 @@ case ",$all_into_one," in
existing="$existing $e"
fi
done
- fi
- if test -z "$args"
- then
- args='--unpacked --incremental'
- elif test -n "$unpack_unreachable"
- then
- args="$args $unpack_unreachable"
+ if test -n "$args" -a -n "$unpack_unreachable"
+ then
+ args="$args $unpack_unreachable"
+ fi
fi
;;
esac
--
1.6.0.3.552.g12334
^ permalink raw reply related
* [PATCH 2/6] packed_git: convert pack_local flag into a bitfield and add pack_keep
From: Brandon Casey @ 2008-11-12 17:59 UTC (permalink / raw)
To: gitster; +Cc: peff, git, spearce, nico, Brandon Casey, Brandon Casey
In-Reply-To: <WFmMnhNsYRw3IUD8hZk59JmvLQlpuqo-hsW2L51xXUJ0ETOpVPtrZvZzBrrquDq1PlXDGK5BhsQ@cipher.nrlssc.navy.mil>
From: Brandon Casey <drafnel@gmail.com>
pack_keep will be set when a pack file has an associated .keep file.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
cache.h | 3 ++-
sha1_file.c | 5 +++++
2 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/cache.h b/cache.h
index eda7028..37ab457 100644
--- a/cache.h
+++ b/cache.h
@@ -686,7 +686,8 @@ extern struct packed_git {
int index_version;
time_t mtime;
int pack_fd;
- int pack_local;
+ unsigned pack_local:1,
+ pack_keep:1;
unsigned char sha1[20];
/* something like ".git/objects/pack/xxxxx.pack" */
char pack_name[FLEX_ARRAY]; /* more */
diff --git a/sha1_file.c b/sha1_file.c
index ab2b520..f2b25bd 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -841,6 +841,11 @@ struct packed_git *add_packed_git(const char *path, int path_len, int local)
return NULL;
}
memcpy(p->pack_name, path, path_len);
+
+ strcpy(p->pack_name + path_len, ".keep");
+ if (!access(p->pack_name, F_OK))
+ p->pack_keep = 1;
+
strcpy(p->pack_name + path_len, ".pack");
if (stat(p->pack_name, &st) || !S_ISREG(st.st_mode)) {
free(p);
--
1.6.0.3.552.g12334
^ permalink raw reply related
* repack and .keep series
From: Brandon Casey @ 2008-11-12 17:59 UTC (permalink / raw)
To: gitster; +Cc: peff, git, spearce, nico
In-Reply-To: <NRnq_JA3Ngz2v6EUhSwtVu5zewgvJgLsW85zZZqzrYE@cipher.nrlssc.navy.mil>
Here is an updated series built on top of master.
What follows is the 6 patches that were sent, but are
not in next.
-brandon
^ permalink raw reply
* [PATCH 1/6] t7700: demonstrate mishandling of objects in packs with a .keep file
From: Brandon Casey @ 2008-11-12 17:59 UTC (permalink / raw)
To: gitster; +Cc: peff, git, spearce, nico, Brandon Casey, Brandon Casey
In-Reply-To: <WFmMnhNsYRw3IUD8hZk59MeWg__Hu_J0586FDlwkv7_Bb80SFy_3xVB_YmBMzdF0byAGksl5Rnk@cipher.nrlssc.navy.mil>
From: Brandon Casey <drafnel@gmail.com>
Objects residing in pack files that have an associated .keep file are not
supposed to be repacked into new pack files, but they are.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
t/t7700-repack.sh | 38 ++++++++++++++++++++++++++++++++++++++
1 files changed, 38 insertions(+), 0 deletions(-)
create mode 100755 t/t7700-repack.sh
diff --git a/t/t7700-repack.sh b/t/t7700-repack.sh
new file mode 100755
index 0000000..7aaff0b
--- /dev/null
+++ b/t/t7700-repack.sh
@@ -0,0 +1,38 @@
+#!/bin/sh
+
+test_description='git repack works correctly'
+
+. ./test-lib.sh
+
+test_expect_failure 'objects in packs marked .keep are not repacked' '
+ echo content1 > file1 &&
+ echo content2 > file2 &&
+ git add . &&
+ git commit -m initial_commit &&
+ # Create two packs
+ # The first pack will contain all of the objects except one
+ git rev-list --objects --all | grep -v file2 |
+ git pack-objects pack > /dev/null &&
+ # The second pack will contain the excluded object
+ packsha1=$(git rev-list --objects --all | grep file2 |
+ git pack-objects pack) &&
+ touch -r pack-$packsha1.pack pack-$packsha1.keep &&
+ objsha1=$(git verify-pack -v pack-$packsha1.idx | head -n 1 |
+ sed -e "s/^\([0-9a-f]\{40\}\).*/\1/") &&
+ mv pack-* .git/objects/pack/ &&
+ git repack -A -d -l &&
+ git prune-packed &&
+ for p in .git/objects/pack/*.idx; do
+ idx=$(basename $p)
+ test "pack-$packsha1.idx" = "$idx" && continue
+ if git verify-pack -v $p | egrep "^$objsha1"; then
+ found_duplicate_object=1
+ echo "DUPLICATE OBJECT FOUND"
+ break
+ fi
+ done &&
+ test -z "$found_duplicate_object"
+'
+
+test_done
+
--
1.6.0.3.552.g12334
^ permalink raw reply related
* [PATCH 3/6] pack-objects: new option --honor-pack-keep
From: Brandon Casey @ 2008-11-12 17:59 UTC (permalink / raw)
To: gitster; +Cc: peff, git, spearce, nico, Brandon Casey
In-Reply-To: <WFmMnhNsYRw3IUD8hZk59Bod6u3kdkWtabbRw1_B1XS8U8eP3drqEMEsFa_-Q_Qu-xrbOsLcdzo@cipher.nrlssc.navy.mil>
This adds a new option to pack-objects which will cause it to ignore an
object which appears in a local pack which has a .keep file, even if it
was specified for packing.
This option will be used by the porcelain repack.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
Documentation/git-pack-objects.txt | 5 +++++
builtin-pack-objects.c | 7 +++++++
2 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-pack-objects.txt b/Documentation/git-pack-objects.txt
index 8c354bd..f9fac2c 100644
--- a/Documentation/git-pack-objects.txt
+++ b/Documentation/git-pack-objects.txt
@@ -109,6 +109,11 @@ base-name::
The default is unlimited, unless the config variable
`pack.packSizeLimit` is set.
+--honor-pack-keep::
+ This flag causes an object already in a local pack that
+ has a .keep file to be ignored, even if it appears in the
+ standard input.
+
--incremental::
This flag causes an object already in a pack ignored
even if it appears in the standard input.
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 15b80db..ddec341 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -71,6 +71,7 @@ static int reuse_delta = 1, reuse_object = 1;
static int keep_unreachable, unpack_unreachable, include_tag;
static int local;
static int incremental;
+static int ignore_packed_keep;
static int allow_ofs_delta;
static const char *base_name;
static int progress = 1;
@@ -703,6 +704,8 @@ static int add_object_entry(const unsigned char *sha1, enum object_type type,
return 0;
if (local && !p->pack_local)
return 0;
+ if (ignore_packed_keep && p->pack_local && p->pack_keep)
+ return 0;
}
}
@@ -2048,6 +2051,10 @@ int cmd_pack_objects(int argc, const char **argv, const char *prefix)
incremental = 1;
continue;
}
+ if (!strcmp("--honor-pack-keep", arg)) {
+ ignore_packed_keep = 1;
+ continue;
+ }
if (!prefixcmp(arg, "--compression=")) {
char *end;
int level = strtoul(arg+14, &end, 0);
--
1.6.0.3.552.g12334
^ permalink raw reply related
* Re: [PATCH v2] contrib/hooks/post-receive-email: send individual mails to recipients
From: Junio C Hamano @ 2008-11-12 18:01 UTC (permalink / raw)
To: Michael Adam; +Cc: Johannes Sixt, git, Andy Parkins
In-Reply-To: <E1L0JjD-00ByqG-1I@intern.SerNet.DE>
Michael Adam <obnox@samba.org> writes:
> Johannes Sixt wrote:
>> Michael Adam schrieb:
>> > This changes the behaviour of post-receive-email when a list of recipients
>> > (separated by commas) is specified as hooks.mailinglist. With this modification,
>> > an individual mail is sent out for each recipient entry in the list, instead
>> > of sending a single mail with all the recipients in the "To: " field.
>>
>> I don't think this is well-behaved:
> ...
> Your concerns are surely valid.
> Maybe it would be useful to make this optional?
What benefit could anybody possibly get by making this optional?
If you do not want to show multiple names on To: header to the mail
recipients, there already is a well-known solution, and it is called
(surprise!) mailing list ;-)
^ permalink raw reply
* Re: [PATCH v2 1/3] t7700: demonstrate mishandling of objects in packs with a .keep file
From: Junio C Hamano @ 2008-11-12 18:10 UTC (permalink / raw)
To: Brandon Casey; +Cc: Jeff King, Shawn O. Pearce, Git Mailing List, Nicolas Pitre
In-Reply-To: <NRnq_JA3Ngz2v6EUhSwtVu5zewgvJgLsW85zZZqzrYE@cipher.nrlssc.navy.mil>
Brandon Casey <casey@nrlssc.navy.mil> writes:
> Jeff King wrote:
>> On Mon, Nov 03, 2008 at 02:37:05PM -0600, Brandon Casey wrote:
>>
>>> This version replaces the use of 'head -n -1' with a grep, and should work on
>>> all platforms.
>>
>> Hmm. I'm not sure what happened, but the version in 'next' has "head -n
>> -1" in it.
>
> Well, there were so many revisions, I probably should have re-rolled the
> whole series....
> ...
> if that's the way we want to go. I'm not partial to the phrase honor-pack-keep,
> but I don't think ignore-pack-keep is appropriate, and it's the best I've come
> up with.
Ok, care to send in a series in incremental updates format, please?
^ permalink raw reply
* Re: hosting git on a nfs
From: Linus Torvalds @ 2008-11-12 18:14 UTC (permalink / raw)
To: David Brown; +Cc: Thomas Koch, git, dabe
In-Reply-To: <20081112173651.GA9127@linode.davidb.org>
On Wed, 12 Nov 2008, David Brown wrote:
>
> We had occasionally run into locking problems with 1.5.4.x with
> renames between different directories. This should be fixed in
> 1.6.0.3, but we have since migrated to a server model so I don't have
> any way of testing this.
I suspect it also depends very much on the particular client/server
combination. Renaming across directories is one of those NFS things that
some servers don't mind at all.
> The configuration we did find completely unworkable was using git with
> the work tree on NFS.
Doing an 'lstat()' on every single file in the tree would tend to do that
to you, yes. Even with a fast network and a good NFS server, we're talking
millisecond-range latencies, and if your tree has tens of thousands of
files, you're going to have each "git diff" take several seconds.
NFS metadata caching can help, but not all clients do it, and even clients
that _do_ do it tend to have rather low timeouts or rather limited cache
sizes, so doing "git diff" twice may speed up the second one only if it's
done really back-to-back - if even then.
And once you get used to "git diff" being instantaneous, I don't think
anybody is ever agan willing to go back to it taking "a few seconds" (and
depending on speed of network/server and size of project, the "few" can be
quite many ;)
So putting the work-tree on NFS certainly _works_, but yes, from a
performance angle it is going to be really irritatingly slower. I don't
even think the newer versions of NFS will help with directory and
attribute caching - the delegations are per-file afaik, and there is no
good support for extending the caching to directories.
That said, I don't think git is any _worse_ than anybody else in the
"worktree on NFS" model. A "git diff" will still be superior ot a CVS diff
in every way. It's just that when people compare to their home machines
where they have the work tree on local disk and aggressively cached, when
they then use a NFS work-tree, they'll likely be very very disappointed.
Linus
^ permalink raw reply
* Re: [PATCH] contrib/hooks/post-receive-email: send individual mails to recipients
From: Junio C Hamano @ 2008-11-12 18:18 UTC (permalink / raw)
To: Michael Adam; +Cc: git, Andy Parkins
In-Reply-To: <E1L0Jyh-00Bzdi-7r@intern.SerNet.DE>
Michael Adam <obnox@samba.org> writes:
> Junio C Hamano wrote:
>> Michael Adam <obnox@samba.org> writes:
>>
>> > This changes the behaviour of post-receive-email when a list of recipients
>> > (separated by commas) is specified as hooks.mailinglist. With this modification,
>> > an individual mail is sent out for each recipient entry in the list, instead
>> > of sending a single mail with all the recipients in the "To: " field.
>>
>> Why can that be an improvement?
>
> My use case is that I have a repository where I want to send
> commit messages to an "official" mailing list and to a private
> recipient list that might not want to be seen on the official
> mailing list.
Ah. What you want is a capability to add Bcc:, not a misfeature to run
the log formatter repeatedly wasting cycles only to generate the same
message contents.
^ permalink raw reply
* Re: [PATCH v2 1/3] t7700: demonstrate mishandling of objects in packs with a .keep file
From: Junio C Hamano @ 2008-11-12 18:19 UTC (permalink / raw)
To: Brandon Casey; +Cc: Jeff King, Shawn O. Pearce, Git Mailing List, Nicolas Pitre
In-Reply-To: <7v7i78q0go.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Brandon Casey <casey@nrlssc.navy.mil> writes:
>
>> Jeff King wrote:
>>> On Mon, Nov 03, 2008 at 02:37:05PM -0600, Brandon Casey wrote:
>>>
>>>> This version replaces the use of 'head -n -1' with a grep, and should work on
>>>> all platforms.
>>>
>>> Hmm. I'm not sure what happened, but the version in 'next' has "head -n
>>> -1" in it.
>>
>> Well, there were so many revisions, I probably should have re-rolled the
>> whole series....
>> ...
>> if that's the way we want to go. I'm not partial to the phrase honor-pack-keep,
>> but I don't think ignore-pack-keep is appropriate, and it's the best I've come
>> up with.
>
> Ok, care to send in a series in incremental updates format, please?
Nah, nevermind. I see you already sent a replacement series overriding what
is in 'next'.
^ permalink raw reply
* [PATCH] fix pack.packSizeLimit and --max-pack-size handling
From: Nicolas Pitre @ 2008-11-12 18:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jon Nelson, git
In-Reply-To: <7vk5b8q1l4.fsf@gitster.siamese.dyndns.org>
First, pack.packSizeLimit and --max-pack-size didn't use the same base
unit which was confusing. They both use suffixable value arguments now.
Also, if the limit was sufficiently low, having a single object written
could bust the limit (by design), but caused the remaining allowed size
to go negative for subsequent objects, which for an unsigned variable is
a rather huge limit.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
On Wed, 12 Nov 2008, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > First, pack.packSizeLimit and --max-pack-size didn't use the same base
> > unit which was confusing. They both use MiB now.
> >
> > Also, if the limit was sufficiently low, having a single object written
> > could bust the limit (by design), but caused the remaining allowed size
> > to go negative for subsequent objects, which for an unsigned variable is
> > a rather huge limit.
> >
> > Signed-off-by: Nicolas Pitre <nico@cam.org>
> > ---
>
> > @@ -1844,7 +1848,7 @@ static int git_pack_config(const char *k, const char *v, void *cb)
> > return 0;
> > }
> > if (!strcmp(k, "pack.packsizelimit")) {
> > - pack_size_limit_cfg = git_config_ulong(k, v);
> > + pack_size_limit_cfg = git_config_ulong(k, v) * 1024 * 1024;
>
> The fix to tweak the limit for subsequent split pack is a good thing to
> have, but this change would break existing repositories where people
> specified 20971520 (or worse yet "20m") to limit the size to 20MB.
>
> I think --max-pack-size is what should be fixed to use git_parse_ulong()
> to match the configuration, if you find the discrepancy disturbing.
Fair enough.
diff --git a/Documentation/git-pack-objects.txt b/Documentation/git-pack-objects.txt
index 1c4fb43..d60409a 100644
--- a/Documentation/git-pack-objects.txt
+++ b/Documentation/git-pack-objects.txt
@@ -104,10 +104,11 @@ base-name::
default.
--max-pack-size=<n>::
- Maximum size of each output packfile, expressed in MiB.
+ Maximum size of each output packfile.
If specified, multiple packfiles may be created.
The default is unlimited, unless the config variable
- `pack.packSizeLimit` is set.
+ `pack.packSizeLimit` is set. The size can be suffixed with
+ "k", "m", or "g".
--incremental::
This flag causes an object already in a pack ignored
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 0c4649c..9c4333b 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -75,7 +75,7 @@ static int allow_ofs_delta;
static const char *base_name;
static int progress = 1;
static int window = 10;
-static uint32_t pack_size_limit, pack_size_limit_cfg;
+static unsigned long pack_size_limit, pack_size_limit_cfg;
static int depth = 50;
static int delta_search_threads = 1;
static int pack_to_stdout;
@@ -245,8 +245,12 @@ static unsigned long write_object(struct sha1file *f,
type = entry->type;
/* write limit if limited packsize and not first object */
- limit = pack_size_limit && nr_written ?
- pack_size_limit - write_offset : 0;
+ if (!pack_size_limit || !nr_written)
+ limit = 0;
+ else if (pack_size_limit <= write_offset)
+ limit = 1;
+ else
+ limit = pack_size_limit - write_offset;
if (!entry->delta)
usable_delta = 0; /* no delta */
@@ -2103,11 +2107,10 @@ int cmd_pack_objects(int argc, const char **argv, const char *prefix)
continue;
}
if (!prefixcmp(arg, "--max-pack-size=")) {
- char *end;
- pack_size_limit_cfg = 0;
- pack_size_limit = strtoul(arg+16, &end, 0) * 1024 * 1024;
- if (!arg[16] || *end)
+ if (!git_parse_ulong(arg+16, &pack_size_limit))
usage(pack_usage);
+ else
+ pack_size_limit_cfg = 0;
continue;
}
if (!prefixcmp(arg, "--window=")) {
^ permalink raw reply related
* Re: Newbie questions regarding jgit
From: Jonas Fonseca @ 2008-11-12 18:30 UTC (permalink / raw)
To: Farrukh Najmi; +Cc: git
In-Reply-To: <491B18C4.2070000@wellfleetsoftware.com>
On Wed, Nov 12, 2008 at 18:56, Farrukh Najmi
<farrukh@wellfleetsoftware.com> wrote:
> So far I have figured out how to get the treeWalk for the path filter as
> shown below.
> Now I am lost as to how to get the blob associated with the treeWalk. TIA
> for your help.
For ideas take a look at how the NetBeans git plugin accomplishes some
of the most common git tasks take a look at the GitCommand.java file.
It contains code for adding and removing files, committing updates to
the index. There is also some code trying to get "git-status"
information, but it is not very smart or clean. Something equivalent
to "git cat-file" (getting the blob data) can be seen at line 120:
- http://github.com/myabc/nbgit/tree/master/src/org/nbgit/util/GitCommand.java#L120
Sorry, I should have suggested this earlier.
--
Jonas Fonseca
^ permalink raw reply
* running out of memory when doing a clone of a large repository?
From: Paul E. Rybski @ 2008-11-12 18:49 UTC (permalink / raw)
To: git
Hi,
I've recently started evaluating git for use on one of my projects. I
used git-svn to convert a fairly large subversion repository and one of
its branches into two separate git repositories following the
instructions found here:
http://www.simplisticcomplexity.com/2008/03/05/cleanly-migrate-your-subversion-repository-to-a-git-repository/
>From that, I created a 1.5G repository from the trunk of the subversion
repo and a 1.1G repository from one of the branches. I then tried to
clone the repositories from one machine to another via ssh and the
smaller 1.1G repository of the subversion branch (with 1932 commits)
came over just fine but the larger 1.5G repository of the subversion
trunk (5865 commits) died with the following error:
remote: Counting objects: 48415, done.
remote: warning: suboptimal pack - out of memory
error: git-upload-pack: git-pack-objects died with error.
fatal: git-upload-pack: aborting due to possible repository corruption
on the remote side.
remote: aborting due to possible repository corruption on the remote side.
fatal: early EOF
fatal: index-pack failed
Is this simply because the git repository is too large for the machine
that's trying to send it over ssh? Is there a way to restrict the
memory usage of git or do I need to get more RAM or somehow not import
the full subversion history of my original trunk?
I'm using Ubuntu 8.04.1 on both machines and using the Ubuntu packages
of git version 1.5.4.3. The machine holding the repository is a 5-year
old AthlonXP 3200 with 1G RAM and 32-bit Ubuntu. The machine I'm
cloning the repository on is a more recent Intel Dual Core Quad Q6600
with 4GRAM and 64-bit Ubuntu.
Any advice would be greatly appreciated.
Thanks!
-Paul
--
Paul E. Rybski, Ph.D., Systems Scientist
The Robotics Institute, Carnegie Mellon University
Phone: 412-268-7417, Fax: 412-268-7350
Web: http://www.cs.cmu.edu/~prybski
^ permalink raw reply
* Re: [PATCH] git-diff: Add --staged as a synonym for --cached.
From: Jeff King @ 2008-11-12 19:15 UTC (permalink / raw)
To: Avery Pennarun
Cc: Johannes Schindelin, Junio C Hamano, Björn Steinbrink,
David Symonds, git, Stephan Beyer
In-Reply-To: <32541b130811120739t95455d8n9b8056a8033491c3@mail.gmail.com>
On Wed, Nov 12, 2008 at 10:39:21AM -0500, Avery Pennarun wrote:
> > I thought about that at first, too, but the working tree is even more
> > painful. You would have to hash every changed file on the filesystem to
> > create the tree object.
>
> Is that so bad? You have to read all those files anyway in order to
> do a diff.
I don't know for sure, as I haven't tried it. But you would need to read
them twice (once to hash, and then once to diff) plus the extra
computation time of hashing. So assuming you have a decent cache, you
pay the disk access only once.
Maybe it would be negligible, but I would have to see numbers to be
convinced either way.
-Peff
^ permalink raw reply
* Re: Change in "git checkout" behaviour between 1.6.0.2 and 1.6.0.3
From: Junio C Hamano @ 2008-11-12 19:15 UTC (permalink / raw)
To: Bruce Stephens; +Cc: Michael J Gruber, git
In-Reply-To: <80r65gon3m.fsf@tiny.isode.net>
Bruce Stephens <bruce.stephens@isode.com> writes:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
> [...]
>
>> Bisecting gives:
>>
>>
>> 5521883490e85f4d973141972cf16f89a79f1979 is first bad commit
>> commit 5521883490e85f4d973141972cf16f89a79f1979
>> Author: Junio C Hamano <gitster@pobox.com>
>> Date: Sun Sep 7 19:49:25 2008 -0700
>>
>> checkout: do not lose staged removal
>
> I got the same, which is reassuring.
>
> Looks like a deliberate change with (what seems to me to be) an
> unfortunate interaction with "git clone -n"
Yeah, it was meant to allow:
git clone -n $there $here
cd $here
git checkout
and was not taking care of the case to switch branches when the initial
checkout is made.
Perhaps this would help.
builtin-checkout.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git c/builtin-checkout.c w/builtin-checkout.c
index 05eee4e..d2265df 100644
--- c/builtin-checkout.c
+++ w/builtin-checkout.c
@@ -269,8 +269,7 @@ static int merge_working_tree(struct checkout_opts *opts,
}
/* 2-way merge to the new branch */
- topts.initial_checkout = (!active_nr &&
- (old->commit == new->commit));
+ topts.initial_checkout = !active_nr;
topts.update = 1;
topts.merge = 1;
topts.gently = opts->merge;
^ permalink raw reply related
* Re: [PATCH v2 1/3] t7700: demonstrate mishandling of objects in packs with a .keep file
From: Jeff King @ 2008-11-12 19:17 UTC (permalink / raw)
To: Junio C Hamano
Cc: Brandon Casey, Shawn O. Pearce, Git Mailing List, Nicolas Pitre
In-Reply-To: <7vzlk4q38q.fsf@gitster.siamese.dyndns.org>
On Wed, Nov 12, 2008 at 09:10:45AM -0800, Junio C Hamano wrote:
> > Hmm. I'm not sure what happened, but the version in 'next' has "head -n
> > -1" in it.
>
> You mean this one?
>
> commit 31d92611e45d1286b805e362dbc451936af24121
Yes, exactly.
-Peff
^ permalink raw reply
* Re: Newbie questions regarding jgit
From: Shawn O. Pearce @ 2008-11-12 19:29 UTC (permalink / raw)
To: Farrukh Najmi; +Cc: git
In-Reply-To: <491B18C4.2070000@wellfleetsoftware.com>
Farrukh Najmi <farrukh@wellfleetsoftware.com> wrote:
>
> So far I have figured out how to get the treeWalk for the path filter as
> shown below.
> Now I am lost as to how to get the blob associated with the treeWalk.
> TIA for your help.
>
> /**
> * Gets the content of specified file in git Repo.
> *
> * @parameter relativePath the relative path in jitRepo for desired
> file to get
> * @parameter versionName the versionName for the desired file. It
> will be unmarshalled from String to ObjectId.
> * @return the content of the desired file version packaged as a
> DataHandler.
> */
> public DataHandler get(String relativePath, String versionName) throws
> RepositoryException {
> ObjectId retrieveStart = repository.resolve(versionName);
> RevWalk revWalk = new RevWalk(repository);
> RevCommit entry = revWalk.parseCommit(retrieveStart);
> RevTree revTree = entry.getTree();
>
> TreeWalk treeWalk = TreeWalk.forPath(repository,
> relativePath, revTree);
>
> //Not sure how to get the blob next
if (treeWalk.next()) {
// Path exists
if (treeWalk.getFileMode(0).getObjectType() == Constants.OBJ_BLOB) {
ObjectId blob = treeWalk.getObjectId(0);
} else {
// Not a blob, its something else (tree, gitlink)
}
} else {
// Path not found
}
--
Shawn.
^ 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