* 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
* 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: 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 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: [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
* [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
* [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
* 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 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
* [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 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 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
* 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
* 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: 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: 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: [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: 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 v2] contrib/hooks/post-receive-email: send individual mails to recipients
From: Michael Adam @ 2008-11-12 17:42 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Michael Adam, git, Andy Parkins, Junio C Hamano
In-Reply-To: <491B0D9B.7080306@viscovery.net>
[-- Attachment #1: Type: text/plain, Size: 1469 bytes --]
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:
>
> - The load multiplies for the sender (typically a repository server).
This is right.
> - And wouldn't each recipient get a new Message-Id? This would break
> threading if further communication takes place among the recipients.
My idea was that different recipients have different threading anyways.
OK, threading for multiple recipients can be conserved with group replies.
I thought that usually you specify a single mailing list as recipient.
My use case is that I have additional recipients that do not necessarily
want to be seen as recipients on the mailing list that is specified as
the primary recipient.
> But I may be wrong on both accounts.
Your concerns are surely valid.
Maybe it would be useful to make this optional?
Thanks for your comments!
Cheers - Michael
--
Michael Adam <ma@sernet.de> <obnox@samba.org>
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.SerNet.DE, mailto: Info @ SerNet.DE
[-- Attachment #2: Type: application/pgp-signature, Size: 206 bytes --]
^ permalink raw reply
* Re: Change in "git checkout" behaviour between 1.6.0.2 and 1.6.0.3
From: Bruce Stephens @ 2008-11-12 17:40 UTC (permalink / raw)
To: git
In-Reply-To: <80wsf9ovsp.fsf@tiny.isode.net>
Bruce Stephens <bruce.stephens@isode.com> writes:
> The following works fine with 1.6.0.2 and before, but not 1.6.0.3 or
> later:
>
> git clone -n git git-test
> cd git-test
> git checkout -b work v1.6.0.2
>
> When it breaks, the error is:
>
> error: Entry '.gitignore' would be overwritten by merge. Cannot merge.
>
> I'm guessing it's a bug rather than a deliberate change?
According to "git bisect", the commit that caused this is the
following one. Perhaps "git clone -n" doesn't start out with the
index empty in the relevant sense?
commit 5521883490e85f4d973141972cf16f89a79f1979
Author: Junio C Hamano <gitster@pobox.com>
Date: Sun Sep 7 19:49:25 2008 -0700
checkout: do not lose staged removal
The logic to checkout a different commit implements the safety to never
lose user's local changes. For example, switching from a commit to
another commit, when you have changed a path that is different between
them, need to merge your changes to the version from the switched-to
commit, which you may not necessarily be able to resolve easily. By
default, "git checkout" refused to switch branches, to give you a chance
to stash your local changes (or use "-m" to merge, accepting the risks of
getting conflicts).
This safety, however, had one deliberate hole since early June 2005. When
your local change was to remove a path (and optionally to stage that
removal), the command checked out the path from the switched-to commit
nevertheless.
This was to allow an initial checkout to happen smoothly (e.g. an initial
checkout is done by starting with an empty index and switching from the
commit at the HEAD to the same commit). We can tighten the rule slightly
to allow this special case to pass, without losing sight of removal
explicitly done by the user, by noticing if the index is truly empty when
the operation begins.
For historical background, see:
http://thread.gmane.org/gmane.comp.version-control.git/4641/focus=4646
This case is marked as *0* in the message, which both Linus and I said "it
feels somewhat wrong but otherwise we cannot start from an empty index".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
^ permalink raw reply
* Re: hosting git on a nfs
From: David Brown @ 2008-11-12 17:36 UTC (permalink / raw)
To: Thomas Koch; +Cc: git, dabe
In-Reply-To: <200811121029.34841.thomas@koch.ro>
On Wed, Nov 12, 2008 at 10:29:34AM +0100, Thomas Koch wrote:
>finally I managed to convince a critical mass of developers (our chief
>dev :-) in our company so that we are starting to migrate to GIT.
>
>The final question is, whether GIT will life peacefully on our cluster
>fileservers. The GIT repository dir (/var/cache/git) should be mounted
>via NFS via PAN on top of DRBD (so I was told).
>
>Are there any known problems with this setup? We're asking, because
>there are problems with SVN on such a setup[1].
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.
None of these problems ever caused repository corruption, only errors
during fetch/clone that were resolved by repeating the operation.
Using ssh: or git: does seem to be a bit faster than NFS. The
configuration we did find completely unworkable was using git with the
work tree on NFS.
David
^ permalink raw reply
* Re: Change in "git checkout" behaviour between 1.6.0.2 and 1.6.0.3
From: Michael J Gruber @ 2008-11-12 17:32 UTC (permalink / raw)
To: Bruce Stephens; +Cc: git, Junio C Hamano
In-Reply-To: <80wsf9ovsp.fsf@tiny.isode.net>
Bruce Stephens venit, vidit, dixit 12.11.2008 15:36:
> The following works fine with 1.6.0.2 and before, but not 1.6.0.3 or
> later:
>
> git clone -n git git-test
> cd git-test
> git checkout -b work v1.6.0.2
>
> When it breaks, the error is:
>
> error: Entry '.gitignore' would be overwritten by merge. Cannot merge.
>
> I'm guessing it's a bug rather than a deliberate change?
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
CCing Junio...
Michael
^ permalink raw reply
* Re: [PATCH v2 1/3] t7700: demonstrate mishandling of objects in packs with a .keep file
From: Brandon Casey @ 2008-11-12 17:30 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Shawn O. Pearce, Git Mailing List, Nicolas Pitre
In-Reply-To: <20081112080909.GA29176@coredump.intra.peff.net>
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. I wasn't sure this was going to go in as is, based on the
[Dropped] message in the "What's Cooking" email and Junio's last email about
reconciling --unpacked and --incremental. I have been working through
the --unpacked code path, but I'm not to the point where I can suggest
a change there.
But, I think it's worse than just the wrong t7700.
These two:
packed_git: convert pack_local flag into generic bit mask
packed_git: add new PACK_KEEP flag and haspackkeep() access macro
should have been replaced by:
packed_git: convert pack_local flag into a bitfield and add pack_keep
which uses a struct bitfield rather than a bitmask.
And then this
pack-objects: honor '.keep' files
was replaced by this
pack-objects: new option --honor-pack-keep
repack: don't repack local objects in packs with .keep file
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.
So,
31d92611e45d1286b805e362dbc451936af24121
7c335327be664751fa4c04e81b2fe3bfedceaada
77b5a5478a77cc04b674891b542db1ba1a1bf4f7
13e7f5d2f1da42619bd545590d0044b30d00ce4b
should be reverted, and replaced by the series to follow.
-brandon
^ 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 17:10 UTC (permalink / raw)
To: Jeff King; +Cc: Brandon Casey, Shawn O. Pearce, Git Mailing List, Nicolas Pitre
In-Reply-To: <20081112080909.GA29176@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> 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.
You mean this one?
commit 31d92611e45d1286b805e362dbc451936af24121
Author: Brandon Casey <drafnel@gmail.com>
AuthorDate: Sat Nov 1 22:35:19 2008 -0500
Commit: Junio C Hamano <gitster@pobox.com>
CommitDate: Sun Nov 2 15:58:09 2008 -0800
t7700: demonstrate mishandling of objects in packs with a .keep file
^ permalink raw reply
* [PATCH v2 0/4] git-remote rename: support branches->config migration
From: Miklos Vajna @ 2008-11-12 17:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Brandon Casey, git
In-Reply-To: <7viqqtshdd.fsf@gitster.siamese.dyndns.org>
On Tue, Nov 11, 2008 at 08:22:38PM -0800, Junio C Hamano <gitster@pobox.com> wrote:
> The function migrate_file() introduced by [2/4] is called for any
> remote definition that did not come from config (by definition, it
> either came from remotes/foo or branches/foo). The function adds the
> entries for the given remote definition to the config file, and then
> removes remotes/foo file if the remote definition came from it. So it
> is a logically consistent change if you only called this function only
> for remote definitions that came from remotes/foo.
>
> But the function is called for a remote definition that originally
> came from branches/foo as well. It happily adds the definition to the
> config, even though it *fails to remove* branches/foo file.
>
> Do you still think 2/4 is a logically contained good change?
OK, here is an updated series, which is supposed to fix this issue. 1/4
and 4/4 is unchanged.
Miklos Vajna (4):
remote: add a new 'origin' variable to the struct
git-remote rename: support remotes->config migration
git-remote rename: support branches->config migration
git-remote: document the migration feature of the rename subcommand
Documentation/git-remote.txt | 4 ++++
builtin-remote.c | 37 +++++++++++++++++++++++++++++++++++++
remote.c | 3 +++
remote.h | 7 +++++++
t/t5505-remote.sh | 33 +++++++++++++++++++++++++++++++++
5 files changed, 84 insertions(+), 0 deletions(-)
^ 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