* [StGit PATCH 4/5] Add the -p option to fold
From: Catalin Marinas @ 2009-09-16 21:41 UTC (permalink / raw)
To: Karl Hasselström, git
In-Reply-To: <20090916214049.6622.44662.stgit@toshiba-laptop>
This option was added to import, so it makes sense for fold to have it
as well.
Signed-off-by: Catalin Marinas <catalin.marinas@gmail.com>
---
stgit/commands/fold.py | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/stgit/commands/fold.py b/stgit/commands/fold.py
index 28e824c..ce0459e 100644
--- a/stgit/commands/fold.py
+++ b/stgit/commands/fold.py
@@ -39,6 +39,8 @@ options = [
short = 'Perform a three-way merge with the current patch'),
opt('-b', '--base', args = [argparse.commit],
short = 'Use BASE instead of HEAD when applying the patch'),
+ opt('-p', '--strip', type = 'int', metavar = 'N',
+ short = 'Remove N leading slashes from diff paths (default 1)'),
opt('--reject', action = 'store_true',
short = 'Leave the rejected hunks in corresponding *.rej files')]
@@ -75,11 +77,13 @@ def func(parser, options, args):
crt_patch = crt_series.get_patch(current)
bottom = crt_patch.get_bottom()
git.apply_patch(filename = filename, base = bottom,
- reject = options.reject)
+ strip = options.strip, reject = options.reject)
elif options.base:
git.apply_patch(filename = filename, reject = options.reject,
+ strip = options.strip,
base = git_id(crt_series, options.base))
else:
- git.apply_patch(filename = filename, reject = options.reject)
+ git.apply_patch(filename = filename, strip = options.strip,
+ reject = options.reject)
out.done()
^ permalink raw reply related
* [StGit PATCH 3/5] Do not create an empty patch if import failed without --reject
From: Catalin Marinas @ 2009-09-16 21:41 UTC (permalink / raw)
To: Karl Hasselström, git
In-Reply-To: <20090916214049.6622.44662.stgit@toshiba-laptop>
If the import failed, do not leave an empty patch on the stack. If this
is required, the --reject option should be passed. The patch also fixes
a lowercase typo in the --reject option description.
Signed-off-by: Catalin Marinas <catalin.marinas@gmail.com>
---
stgit/commands/imprt.py | 11 ++++++++---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/stgit/commands/imprt.py b/stgit/commands/imprt.py
index aa75065..de77635 100644
--- a/stgit/commands/imprt.py
+++ b/stgit/commands/imprt.py
@@ -68,7 +68,7 @@ options = [
opt('-b', '--base', args = [argparse.commit],
short = 'Use BASE instead of HEAD for file importing'),
opt('--reject', action = 'store_true',
- short = 'leave the rejected hunks in corresponding *.rej files'),
+ short = 'Leave the rejected hunks in corresponding *.rej files'),
opt('-e', '--edit', action = 'store_true',
short = 'Invoke an editor for the patch description'),
opt('-d', '--showdiff', action = 'store_true',
@@ -154,8 +154,13 @@ def __create_patch(filename, message, author_name, author_email,
base = git_id(crt_series, options.base)
else:
base = None
- git.apply_patch(diff = diff, base = base, reject = options.reject,
- strip = options.strip)
+ try:
+ git.apply_patch(diff = diff, base = base, reject = options.reject,
+ strip = options.strip)
+ except git.GitException:
+ if not options.reject:
+ crt_series.delete_patch(patch)
+ raise
crt_series.refresh_patch(edit = options.edit,
show_patch = options.showdiff,
author_date = author_date,
^ permalink raw reply related
* [StGit PATCH 1/5] Remove the 'fail_dump' argument to git.apply_patch()
From: Catalin Marinas @ 2009-09-16 21:40 UTC (permalink / raw)
To: Karl Hasselström, git
In-Reply-To: <20090916214049.6622.44662.stgit@toshiba-laptop>
Since we have a 'reject' argument, there is no need for the failed diff
to be dumped.
Signed-off-by: Catalin Marinas <catalin.marinas@gmail.com>
---
stgit/git.py | 11 ++---------
1 files changed, 2 insertions(+), 9 deletions(-)
diff --git a/stgit/git.py b/stgit/git.py
index 012e282..97b1e96 100644
--- a/stgit/git.py
+++ b/stgit/git.py
@@ -818,7 +818,7 @@ def repack():
GRun('repack', '-a', '-d', '-f').run()
def apply_patch(filename = None, diff = None, base = None,
- fail_dump = True, reject = False, strip = None):
+ reject = False, strip = None):
"""Apply a patch onto the current or given index. There must not
be any local changes in the tree, otherwise the command fails
"""
@@ -847,14 +847,7 @@ def apply_patch(filename = None, diff = None, base = None,
except GitRunException:
if base:
switch(orig_head)
- if fail_dump:
- # write the failed diff to a file
- f = file('.stgit-failed.patch', 'w+')
- f.write(diff)
- f.close()
- out.warn('Diff written to the .stgit-failed.patch file')
-
- raise
+ raise GitException('Diff does not apply cleanly')
if base:
top = commit(message = 'temporary commit used for applying a patch',
^ permalink raw reply related
* [StGit PATCH 5/5] Autosign imported patches
From: Catalin Marinas @ 2009-09-16 21:41 UTC (permalink / raw)
To: Karl Hasselström, git
In-Reply-To: <20090916214049.6622.44662.stgit@toshiba-laptop>
If stgit.autosign configuration is set, allow the automatic signing of
the imported patches, similar to the 'new' command.
Signed-off-by: Catalin Marinas <catalin.marinas@gmail.com>
---
stgit/commands/imprt.py | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/stgit/commands/imprt.py b/stgit/commands/imprt.py
index de77635..0f78490 100644
--- a/stgit/commands/imprt.py
+++ b/stgit/commands/imprt.py
@@ -141,6 +141,10 @@ def __create_patch(filename, message, author_name, author_email,
if options.authdate:
author_date = options.authdate
+ sign_str = options.sign_str
+ if not options.sign_str:
+ sign_str = config.get('stgit.autosign')
+
crt_series.new_patch(patch, message = message, can_edit = False,
author_name = author_name,
author_email = author_email,
@@ -164,8 +168,7 @@ def __create_patch(filename, message, author_name, author_email,
crt_series.refresh_patch(edit = options.edit,
show_patch = options.showdiff,
author_date = author_date,
- sign_str = options.sign_str,
- backup = False)
+ sign_str = sign_str, backup = False)
out.done()
def __mkpatchname(name, suffix):
^ permalink raw reply related
* [StGit PATCH 0/5] More UI clean-up
From: Catalin Marinas @ 2009-09-16 21:40 UTC (permalink / raw)
To: Karl Hasselström, git
The series adds makes the fold and import options consistent regarding
the -p and --reject options. The autosigning of new patches was extended
to the import command as well.
---
Catalin Marinas (5):
Remove the 'fail_dump' argument to git.apply_patch()
Add the --reject option to fold
Do not create an empty patch if import failed without --reject
Add the -p option to fold
Autosign imported patches
stgit/commands/fold.py | 15 +++++++++++----
stgit/commands/imprt.py | 18 +++++++++++++-----
stgit/git.py | 11 ++---------
3 files changed, 26 insertions(+), 18 deletions(-)
--
Catalin
^ permalink raw reply
* [StGit PATCH 2/5] Add the --reject option to fold
From: Catalin Marinas @ 2009-09-16 21:41 UTC (permalink / raw)
To: Karl Hasselström, git
In-Reply-To: <20090916214049.6622.44662.stgit@toshiba-laptop>
Signed-off-by: Catalin Marinas <catalin.marinas@gmail.com>
---
stgit/commands/fold.py | 11 +++++++----
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/stgit/commands/fold.py b/stgit/commands/fold.py
index 66a2dd9..28e824c 100644
--- a/stgit/commands/fold.py
+++ b/stgit/commands/fold.py
@@ -38,7 +38,9 @@ options = [
opt('-t', '--threeway', action = 'store_true',
short = 'Perform a three-way merge with the current patch'),
opt('-b', '--base', args = [argparse.commit],
- short = 'Use BASE instead of HEAD applying the patch')]
+ short = 'Use BASE instead of HEAD when applying the patch'),
+ opt('--reject', action = 'store_true',
+ short = 'Leave the rejected hunks in corresponding *.rej files')]
directory = DirectoryHasRepository(log = True)
@@ -72,11 +74,12 @@ def func(parser, options, args):
if options.threeway:
crt_patch = crt_series.get_patch(current)
bottom = crt_patch.get_bottom()
- git.apply_patch(filename = filename, base = bottom)
+ git.apply_patch(filename = filename, base = bottom,
+ reject = options.reject)
elif options.base:
- git.apply_patch(filename = filename,
+ git.apply_patch(filename = filename, reject = options.reject,
base = git_id(crt_series, options.base))
else:
- git.apply_patch(filename = filename)
+ git.apply_patch(filename = filename, reject = options.reject)
out.done()
^ permalink raw reply related
* Re: [RFC/PATCH 0/2] Speed up fetch with large number of tags
From: Julian Phillips @ 2009-09-16 22:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbplb2pi7.fsf@alter.siamese.dyndns.org>
On Wed, 16 Sep 2009, Junio C Hamano wrote:
> Julian Phillips <julian@quantumfyre.co.uk> writes:
>
>> I have a repository at $dayjob where fetch was taking ~30s to tell me
>> that there were no updates.
>>
>> It turns out that I appear to have added a nasty linear search of all
>> remote refs for every commit (i.e. tag^{}) tag ref way back in the
>> original C implementation of fetch. This doesn't scale well to large
>> numbers of refs, so this replaces it with a hash table based lookup
>> instead, which brings the time down to a few seconds even for very large
>> ref counts.
>>
>> I haven't tested it with non-native transports, but there is no reason
>> to believe that the code should be transport specific.
>
> Very interesting.
>
> A few questions (not criticisms).
>
> * 1m50s to 4.5s is quite impressive, even if it is only in a repository
> with unusual refs-vs-commits ratio, but I personally think 10 refs per
> every commit is already on the borderline of being insane, and the
> normal ratio would be more like 1 refs per every 10-20 commits.
I noticed the problem with a real repository at $dayjob, and did enough
anaylsis to identiy the problem. I deliberately created a repository that
should emphasise the problem so that it was easy to get a handle on.
Having applied the ref-dict patches fetch on my $dayjob repo has gone from
~30s to ~4.5s, which may not be as impressive - but is much easier to live
with.
> What are possible downsides with the new code in repositories with more
> reasonable refs-vs-commits ratio? A hash table (with a sensible hash
> function) would almost always outperform linear search in an randomly
> ordered collection, so my gut tells me that there won't be performance
> downsides, but are there other potential issues we should worry about?
I guess that main thing would be the extra memory usage.
> * In an insanely large refs-vs-commits case, perhaps not 50000:1 but more
> like 100:1, but with a history with far more than one commit, what is
> the memory consumption? Judging from a cursory view, I think the way
> ref-dict re-uses struct ref might be quite suboptimal, as you are using
> only next (for hash-bucket link), old_sha1[] and its name field, and
> also your ref_dict_add() calls alloc_ref() which calls one calloc() per
> requested ref, instead of attempting any bulk allocation.
Yeah, I just reused struct for speed and convience of developing, to
veryify that ref-dict would give me the speed I wanted. A final patch
would want a more optimised version. Except that I've thrown the whole
hash table thing away anyway.
> * The outer loop is walking the list of refs from a transport, and the
> inner loop is walking a copy of the same list of refs from the same
> transport, looking for each refs/tags/X^{} what record, if any, existed
> for refs/tags/X.
>
> Would it make sense to further specialize your optimization? For
> example, something like...
I actually arrived at somthing similar to this myself, after realising
that I could use string_list as a basis.
> * It is tempting to use a hash table when you have to deal with an
> unordered collection, but in this case, wouldn't the refs obtained from
> the transport (it's essentially a ls-remote output, isn't it?) be
> sorted? Can't you take advantage of that fact to optimize the loop,
> without adding a specialized hash table implementation?
I wasn't sure if we could rely on the refs list being sorted. But I've
got a new version that uses an extra string_list instead that is actually
slightly faster. I'll post that shortly.
> We find refs/tags/v0.99 immediately followed by refs/tags/v0.99^{} in
> the ls-remote output. And the inefficient loop is about finding
> refs/tags/v0.99 when we see refs/tags/v0.99^{}, so if we remember the
> tag ref we saw in the previous round, we can check with that first to
> make sure our "sorted" assumption holds true, and optimize the loop out
> that way, no?
--
Julian
---
Bilbo's First Law:
You cannot count friends that are all packed up in barrels.
^ permalink raw reply
* Re: [RFC/PATCH 0/2] Speed up fetch with large number of tags
From: Shawn O. Pearce @ 2009-09-16 22:42 UTC (permalink / raw)
To: Julian Phillips; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LNX.2.00.0909162141140.13697@reaper.quantumfyre.co.uk>
Julian Phillips <julian@quantumfyre.co.uk> wrote:
> On Wed, 16 Sep 2009, Junio C Hamano wrote:
>> * It is tempting to use a hash table when you have to deal with an
>> unordered collection, but in this case, wouldn't the refs obtained from
>> the transport (it's essentially a ls-remote output, isn't it?) be
>> sorted? Can't you take advantage of that fact to optimize the loop,
>> without adding a specialized hash table implementation?
>
> I wasn't sure if we could rely on the refs list being sorted. But I've
> got a new version that uses an extra string_list instead that is actually
> slightly faster. I'll post that shortly.
JGit depends on the fact that the refs list is sorted by the remote
peer, and that foo^{} immediately follows foo. I don't think this
has ever been documented, but all sane implementations[1] follow
this convention and it may be something we could simply codify as
part of the protocol standard.
[1] Sane implementations are defined to be what I consider to be
the two stable implementations in deployed use, git.git and JGit.
--
Shawn.
^ permalink raw reply
* Re: [RFC/PATCH 0/2] Speed up fetch with large number of tags
From: Shawn O. Pearce @ 2009-09-16 22:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Julian Phillips, git
In-Reply-To: <7vbplb2pi7.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> A few questions (not criticisms).
>
> * 1m50s to 4.5s is quite impressive, even if it is only in a repository
> with unusual refs-vs-commits ratio, but I personally think 10 refs per
> every commit is already on the borderline of being insane, and the
> normal ratio would be more like 1 refs per every 10-20 commits.
Under Gerrit Code Review it is normaly to have 2-5 refs per commit,
every iteration of a patch is held as a commit and anchored by a
unique ref.
So we're borderline insane. :-)
--
Shawn.
^ permalink raw reply
* Re: [RFC/PATCH 0/2] Speed up fetch with large number of tags
From: Junio C Hamano @ 2009-09-16 22:52 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Julian Phillips, git
In-Reply-To: <20090916224253.GB14660@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> JGit depends on the fact that the refs list is sorted by the remote
> peer, and that foo^{} immediately follows foo. I don't think this
> has ever been documented, but all sane implementations[1] follow
> this convention and it may be something we could simply codify as
> part of the protocol standard.
>
> [1] Sane implementations are defined to be what I consider to be
> the two stable implementations in deployed use, git.git and JGit.
There is no strong reason for ordering of refs between themselves
(i.e. refs/heads/master comes before refs/heads/next) other than the fact
that we sort and then walk due to packed-refs reasons.
But emitting tag X and then its peeled representation X^{} immediately
after it is quite fundamental in the way how anybody sane would implement
ls-remote. There is no reason to violate the established order other than
"I could do so", and in order not to show X and X^{} next to each other,
you would need _more_ processing.
So I would say it is very safe to assume this.
Also, you might not have noticed, but my illustration patch was merely
using it as a hint to optimize, and if the last ref we saw was not X when
it is turn to handle X^{}, it simply falled back to the original logic,
iow, the patch never compromised the correctness.
^ permalink raw reply
* [RFC/PATCH v2] fetch: Speed up fetch by rewriting find_non_local_tags
From: Julian Phillips @ 2009-09-16 22:53 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <alpine.LNX.2.00.0909162141140.13697@reaper.quantumfyre.co.uk>
When trying to get a list of remote tags to see if we need to fetch
any we were doing a linear search for the matching tag ref for the
tag^{} commit entries. This proves to be incredibly slow for large
numbers of tags. Rewrite the function so that we can do lookup in
string_lists instead.
For a repository with 50000 tags (and just a single commit on a single
branch), a fetch that does nothing goes from ~ 1m50s to ~4.2s.
Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
---
Not only does this not require a custom hash table, it is also slightly
faster than the last version (~4.2s vs ~4.5s).
If nothing else, having rewritten it completely, at least I now
understand what the old find_non_local_tags function was actually doing
... ;)
builtin-fetch.c | 85 ++++++++++++++++++++++++++++++++++++++-----------------
1 files changed, 59 insertions(+), 26 deletions(-)
diff --git a/builtin-fetch.c b/builtin-fetch.c
index cb48c57..c9a2563 100644
--- a/builtin-fetch.c
+++ b/builtin-fetch.c
@@ -504,57 +504,90 @@ static int will_fetch(struct ref **head, const unsigned char *sha1)
return 0;
}
+struct tag_data {
+ struct ref **head;
+ struct ref ***tail;
+ struct string_list *refs;
+};
+
+static int add_to_tail(struct string_list_item *item, void *cb_data)
+{
+ struct tag_data *data = (struct tag_data *)cb_data;
+ unsigned char *commit = (unsigned char *)item->util;
+ struct ref *rm = NULL;
+ struct string_list_item *sli;
+
+ /* Tag objects will have the commit sha1 associated with the peeled
+ * ref, if there is not a peeled ref then the ref is probably a
+ * lightweight tag and so refers to a commit directly */
+ sli = string_list_lookup(item->string, data->refs);
+ if (sli)
+ commit = sli->util;
+
+ /* skip over tags that we don't have the commits for. */
+ if (!has_sha1_file(commit) && !will_fetch(data->head, commit))
+ return 0;
+
+ rm = alloc_ref(item->string);
+ rm->peer_ref = alloc_ref(item->string);
+ hashcpy(rm->old_sha1, item->util);
+
+ **data->tail = rm;
+ *data->tail = &rm->next;
+
+ return 0;
+}
+
static void find_non_local_tags(struct transport *transport,
struct ref **head,
struct ref ***tail)
{
struct string_list existing_refs = { NULL, 0, 0, 0 };
- struct string_list new_refs = { NULL, 0, 0, 1 };
+ struct string_list peeled_refs = { NULL, 0, 0, 1 };
+ struct string_list remote_refs = { NULL, 0, 0, 1 };
+ struct tag_data data = {head, tail, &peeled_refs};
+ struct string_list *refs;
char *ref_name;
int ref_name_len;
- const unsigned char *ref_sha1;
- const struct ref *tag_ref;
- struct ref *rm = NULL;
const struct ref *ref;
+ struct string_list_item *item;
for_each_ref(add_existing, &existing_refs);
for (ref = transport_get_remote_refs(transport); ref; ref = ref->next) {
if (prefixcmp(ref->name, "refs/tags"))
continue;
+ /* skip duplicates */
+ if (string_list_lookup(ref->name, &remote_refs))
+ continue;
+
+ refs = &remote_refs;
ref_name = xstrdup(ref->name);
ref_name_len = strlen(ref_name);
- ref_sha1 = ref->old_sha1;
+ /* we want to store peeled refs by the base ref name in the
+ * peeled_refs string list */
if (!strcmp(ref_name + ref_name_len - 3, "^{}")) {
ref_name[ref_name_len - 3] = 0;
- tag_ref = transport_get_remote_refs(transport);
- while (tag_ref) {
- if (!strcmp(tag_ref->name, ref_name)) {
- ref_sha1 = tag_ref->old_sha1;
- break;
- }
- tag_ref = tag_ref->next;
- }
+ refs = &peeled_refs;
}
- if (!string_list_has_string(&existing_refs, ref_name) &&
- !string_list_has_string(&new_refs, ref_name) &&
- (has_sha1_file(ref->old_sha1) ||
- will_fetch(head, ref->old_sha1))) {
- string_list_insert(ref_name, &new_refs);
-
- rm = alloc_ref(ref_name);
- rm->peer_ref = alloc_ref(ref_name);
- hashcpy(rm->old_sha1, ref_sha1);
-
- **tail = rm;
- *tail = &rm->next;
+ /* ignore refs that we already have */
+ if (!string_list_has_string(&existing_refs, ref_name)) {
+ item = string_list_insert(ref_name, refs);
+ item->util = (void *)ref->old_sha1;
}
+
free(ref_name);
}
+
+ /* For all the tags in the remote_refs string list, call add_to_tail to
+ * add them to the list of refs to be fetched */
+ for_each_string_list(add_to_tail, &remote_refs, &data);
+
string_list_clear(&existing_refs, 0);
- string_list_clear(&new_refs, 0);
+ string_list_clear(&peeled_refs, 0);
+ string_list_clear(&remote_refs, 0);
}
static void check_not_current_branch(struct ref *ref_map)
--
1.6.4.2
^ permalink raw reply related
* Re: [RFC/PATCH 0/2] Speed up fetch with large number of tags
From: Shawn O. Pearce @ 2009-09-16 23:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Julian Phillips, git
In-Reply-To: <7vtyz2wlhm.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
> > JGit depends on the fact that the refs list is sorted by the remote
> > peer, and that foo^{} immediately follows foo. I don't think this
> > has ever been documented, but all sane implementations[1] follow
> > this convention and it may be something we could simply codify as
> > part of the protocol standard.
> >
> > [1] Sane implementations are defined to be what I consider to be
> > the two stable implementations in deployed use, git.git and JGit.
>
> There is no strong reason for ordering of refs between themselves
> (i.e. refs/heads/master comes before refs/heads/next) other than the fact
> that we sort and then walk due to packed-refs reasons.
Sorry, I misspoke a bit above.
JGit does not care about the ordering between two refs, e.g. in your
master/next example above JGit would accept them in either order
just fine. Internally we enforce this by hashing the advertised
refs and walking the hash, callers presenting the data for a user
must copy to a list and sort by their desired sorting criteria
(usually name).
What I meant to say was this:
> But emitting tag X and then its peeled representation X^{} immediately
> after it is quite fundamental in the way how anybody sane would implement
> ls-remote. There is no reason to violate the established order other than
> "I could do so", and in order not to show X and X^{} next to each other,
> you would need _more_ processing.
and right, explicitly placing X^{} away from X means that the sender
has to do more work to buffer one of the two values and then show
them later. This is pointless other than to piss off any more
reasonable implementor.
I think we should formalize this rule of X^{} immediately follows
X if peeling is possible, and if not, then X^{} must not appear.
We already have a similar rule with packed-refs, although there it
is absolutely required by the format.
> Also, you might not have noticed, but my illustration patch was merely
> using it as a hint to optimize, and if the last ref we saw was not X when
> it is turn to handle X^{}, it simply falled back to the original logic,
> iow, the patch never compromised the correctness.
Oh, I missed that. JGit I think flat out panics and disconnects
if the remote does this to us. What is the incentive in supporting
a broken server with a slower client?
--
Shawn.
^ permalink raw reply
* [ANNOUNCE] Git User's Survey 2009 has been closed
From: Jakub Narebski @ 2009-09-16 23:13 UTC (permalink / raw)
To: git; +Cc: linux-kernel
Hi all,
Git User's Survey 2009 ended at the end of Wednesday, 16 October 2008,
around 23:45 CEST (GMT+0200).
Beginnings of survey summary should be available soon at
http://git.or.cz/gitwiki/GitSurvey2009
Currently you can get there raw data (individual responses) in CSV and
XLS formats (compressed). One can find there also link to online
analysis (on Survs.com) and beginnings of partial survey summaries
(send to git mailing list in the duration of the survey).
Thanks to all who participated in this survey!
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [RFC/PATCH v2] fetch: Speed up fetch by rewriting find_non_local_tags
From: Junio C Hamano @ 2009-09-16 23:15 UTC (permalink / raw)
To: Julian Phillips; +Cc: git, Junio C Hamano
In-Reply-To: <20090916225350.45746.85139.julian@quantumfyre.co.uk>
Julian Phillips <julian@quantumfyre.co.uk> writes:
> When trying to get a list of remote tags to see if we need to fetch
> any we were doing a linear search for the matching tag ref for the
> tag^{} commit entries. This proves to be incredibly slow for large
> numbers of tags. Rewrite the function so that we can do lookup in
> string_lists instead.
>
> For a repository with 50000 tags (and just a single commit on a single
> branch), a fetch that does nothing goes from ~ 1m50s to ~4.2s.
>
> Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
> ---
>
> Not only does this not require a custom hash table, it is also slightly
> faster than the last version (~4.2s vs ~4.5s).
I am just curious. How would a "just one item lookbehind" code perform
compared to this one?
^ permalink raw reply
* Re: [RFC/PATCH 0/2] Speed up fetch with large number of tags
From: Junio C Hamano @ 2009-09-16 23:19 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, Julian Phillips, git
In-Reply-To: <20090916230350.GC14660@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
>> Also, you might not have noticed, but my illustration patch was merely
>> using it as a hint to optimize, and if the last ref we saw was not X when
>> it is turn to handle X^{}, it simply falled back to the original logic,
>> iow, the patch never compromised the correctness.
>
> Oh, I missed that. JGit I think flat out panics and disconnects
> if the remote does this to us. What is the incentive in supporting
> a broken server with a slower client?
There is none.
I think the original logic, being written in shell, run grep in the
output, and the C code we are seeing is a literal translation of that.
In other words, I think it is simply a historical accident.
^ permalink raw reply
* Git Hooks
From: daicoden @ 2009-09-16 23:24 UTC (permalink / raw)
To: git
Hi,
I have a git repo host at /home/git/blog.git. I have a copy checked out at
/var/www/blog. I have a script as follows:
cd /var/www/blog
thin -s 2 -C config.yml -R config.ru stop
git pull origin master
thin -s 2 -C config.yml -R config.ru start
>From a local machine I can commit to the repo, push, and then run this
script and the server will update just fine. I wanted to make this
automatic so I wrote the following post-receive hook.
if git log -n1 | grep -q "#publish" || git log -n1 | grep -q "#Publish"
then
~/bin/update-blog
fi
If #publish is in the commit message then it runs the first script. I found
through trial and error that when you use the command git from within a git
hook it needs to be executed in a .git directory, so I changed the first
script to.
cd /var/www/blog
thin -s 2 -C config.yml -R config.ru stop
cd .git
git pull origin master
cd ..
thin -s 2 -C config.yml -R config.ru start
Everything executes, I see the messages of the server stopping, the new info
being pulled, then the server starts again, but the server does not reflect
any changes. If I then manually stop the server, use git reset --hard, and
then start the server again it works fine.
My only thought is that the cause of this has something to do with git
operating differently when you call it from within a hook. Unfortunately, I
don't have any thoughts on how to fix it.
--
View this message in context: http://www.nabble.com/Git-Hooks-tp25482688p25482688.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* [ANNOUNCE] GIT 1.6.4.4
From: Junio C Hamano @ 2009-09-16 23:26 UTC (permalink / raw)
To: git
The latest maintenance release GIT 1.6.4.4 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.6.4.4.tar.{gz,bz2} (source tarball)
git-htmldocs-1.6.4.4.tar.{gz,bz2} (preformatted docs)
git-manpages-1.6.4.4.tar.{gz,bz2} (preformatted docs)
The RPM binary packages for a few architectures are found in:
RPMS/$arch/git-*-1.6.4.4-1.fc9.$arch.rpm (RPM)
This is primarily to fix a http regression introduced by 1.6.4.3
GIT v1.6.4.4 Release Notes
==========================
Fixes since v1.6.4.4
--------------------
* The workaround for Github server that sometimes gave 500 (Internal server
error) response to HEAD requests in 1.6.4.3 introduced a regression that
caused re-fetching projects over http to segfault in certain cases due
to uninitialized pointer being freed.
* "git pull" on an unborn branch used to consider anything in the work
tree and the index discardable.
* "git diff -b/w" did not work well on the incomplete line at the end of
the file, due to an incorrect hashing of lines in the low-level xdiff
routines.
* "git checkout-index --prefix=$somewhere" used to work when $somewhere is
a symbolic link to a directory elsewhere, but v1.6.4.2 broke it.
* "git unpack-objects --strict", invoked when receive.fsckobjects
configuration is set in the receiving repository of "git push", did not
properly check the objects, especially the submodule links, it received.
Other minor documentation updates are included.
^ permalink raw reply
* Re: Git Hooks
From: Junio C Hamano @ 2009-09-16 23:31 UTC (permalink / raw)
To: daicoden; +Cc: git
In-Reply-To: <25482688.post@talk.nabble.com>
daicoden <daicoden@copypastel.com> writes:
> cd /var/www/blog
> thin -s 2 -C config.yml -R config.ru stop
> cd .git
> git pull origin master
> cd ..
> thin -s 2 -C config.yml -R config.ru start
Unless you have a strange configuration in which you have work tree files
inside a .git directory of another repository, running "git pull" after
going into .git directory does not make any sense.
Perhaps add this
unset GIT_DIR
at the very beginning of your original script would make it work better?
^ permalink raw reply
* Re: [RFC/PATCH v2] fetch: Speed up fetch by rewriting find_non_local_tags
From: Julian Phillips @ 2009-09-16 23:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7veiq6wkfu.fsf@alter.siamese.dyndns.org>
On Wed, 16 Sep 2009, Junio C Hamano wrote:
> Julian Phillips <julian@quantumfyre.co.uk> writes:
>
>> When trying to get a list of remote tags to see if we need to fetch
>> any we were doing a linear search for the matching tag ref for the
>> tag^{} commit entries. This proves to be incredibly slow for large
>> numbers of tags. Rewrite the function so that we can do lookup in
>> string_lists instead.
>>
>> For a repository with 50000 tags (and just a single commit on a single
>> branch), a fetch that does nothing goes from ~ 1m50s to ~4.2s.
>>
>> Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
>> ---
>>
>> Not only does this not require a custom hash table, it is also slightly
>> faster than the last version (~4.2s vs ~4.5s).
>
> I am just curious. How would a "just one item lookbehind" code perform
> compared to this one?
The code you wrote ealier is almost the same as the string_list version,
~4.3s, so very marginally slower but a lot less code change. Personally
I'd be happy with any of the three, so long as I don't have to wait 30s to
find out that nothing's happened at $dayjob anymore ;)
--
Julian
---
QOTD:
If it's too loud, you're too old.
^ permalink raw reply
* [PATCH] Remove unused sha1 parameter from pprint_tag function.
From: Thiago Farina @ 2009-09-17 0:12 UTC (permalink / raw)
To: git; +Cc: Thiago Farina
Signed-off-by: Thiago Farina <tfransosi@gmail.com>
---
builtin-cat-file.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin-cat-file.c b/builtin-cat-file.c
index 5906842..626c6a7 100644
--- a/builtin-cat-file.c
+++ b/builtin-cat-file.c
@@ -13,7 +13,7 @@
#define BATCH 1
#define BATCH_CHECK 2
-static void pprint_tag(const unsigned char *sha1, const char *buf, unsigned long size)
+static void pprint_tag(const char *buf, unsigned long size)
{
/* the parser in tag.c is useless here. */
const char *endp = buf + size;
@@ -126,7 +126,7 @@ static int cat_one_file(int opt, const char *exp_type, const char *obj_name)
if (!buf)
die("Cannot read object %s", obj_name);
if (type == OBJ_TAG) {
- pprint_tag(sha1, buf, size);
+ pprint_tag(buf, size);
return 0;
}
--
1.6.5.rc0.dirty
^ permalink raw reply related
* Re: obnoxious CLI complaints
From: Brendan Miller @ 2009-09-17 0:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: John Tapsell, Dmitry Potapov, Jakub Narebski, git
In-Reply-To: <7v3a6r5znq.fsf@alter.siamese.dyndns.org>
On Sun, Sep 13, 2009 at 11:47 AM, Junio C Hamano <gitster@pobox.com> wrote:
> John Tapsell <johnflux@gmail.com> writes:
>
>> Ah, the manpage examples specifically give the --format=tar though.
>
> So what?
That looks like a manpage bug. In the version I have 1.6.4 the format
for archive is given like this:
git archive --format=<fmt> [--list] [--prefix=<prefix>/] [<extra>]
[--output=<file>] [--worktree-attributes]
[--remote=<repo> [--exec=<git-upload-archive>]] <tree-i
sh>
[path...]
So --format isn't marked as optional. Later in the manpage it mentions
tar as the default, but that contradicts this, and the examples use
--format=tar, so it's easy to miss.
>
>> Why not have --format=tgz then or something? Or better yet, give
>> the filename on the command line and detect the format from the file
>> extension.
>
> That is an interesting enhancement and sounds like a useful feature.
>
I do like that idea.
git archive --output=myarchive.tar.gz HEAD is a bit more
straightforward, and still lets people pipe in the old way if they
want to.
I think someone mentioned we're already linking the requisite library?
Otherwise, you can always open up a pipe programmatically within git.
Don't you guys do something like that for ssh? I seem to recall it
complaining that ssh couldn't be found on windows, but maybe it was
just the library.
Prefix could be myarchive. I guess some people have more specific
requirements, but I usually just want it to be *sometime* so it
doesn't spew out tons of files into the directory I decompress it
into.
Brendan
^ permalink raw reply
* Re: obnoxious CLI complaints
From: Junio C Hamano @ 2009-09-17 1:27 UTC (permalink / raw)
To: Brendan Miller; +Cc: John Tapsell, Dmitry Potapov, Jakub Narebski, git
In-Reply-To: <ef38762f0909161748u32ad56bcya3314fe28fd06ffe@mail.gmail.com>
Brendan Miller <catphive@catphive.net> writes:
> On Sun, Sep 13, 2009 at 11:47 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> John Tapsell <johnflux@gmail.com> writes:
>>
>>> Ah, the manpage examples specifically give the --format=tar though.
>>
>> So what?
>
> That looks like a manpage bug. In the version I have 1.6.4 the format
> for archive is given like this:
>
> git archive --format=<fmt> [--list] [--prefix=<prefix>/] [<extra>]
> [--output=<file>] [--worktree-attributes]
> [--remote=<repo> [--exec=<git-upload-archive>]] <tree-i
> sh>
> [path...]
>
> So --format isn't marked as optional.
Ahh, that would indeed be a documentation bug.
82d97da (Documentation: git-archive: mark --format as optional in summary,
2009-08-27) fixed it already, so upcoming 1.6.5 should have that fix.
Thanks.
^ permalink raw reply
* Re: [RFC/PATCH v2] fetch: Speed up fetch by rewriting find_non_local_tags
From: Julian Phillips @ 2009-09-17 1:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <alpine.LNX.2.00.0909170039410.14993@reaper.quantumfyre.co.uk>
On Thu, 17 Sep 2009, Julian Phillips wrote:
> On Wed, 16 Sep 2009, Junio C Hamano wrote:
>
>> I am just curious. How would a "just one item lookbehind" code perform
>> compared to this one?
>
> The code you wrote ealier is almost the same as the string_list version,
> ~ 4.3s, so very marginally slower but a lot less code change. Personally
> I'd be happy with any of the three, so long as I don't have to wait 30s to
> find out that nothing's happened at $dayjob anymore ;)
FWIW: I've Just modified my v2 patch to make use of the requirement that
the peeled ref immediately follow the base ref, and it's now ~4.1s and
should use less memory than the original too. I won't bother posting it
unless someone thinks it worth it though.
--
Julian
---
Taxes, n.:
Of life's two certainties, the only one for which you can get
an extension.
^ permalink raw reply
* Re: [PATCH] archive: Refuse to write the archive to a terminal.
From: Josh Triplett @ 2009-09-17 1:49 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, gitster
In-Reply-To: <4AB0C7DE.7030109@viscovery.net>
On Wed, Sep 16, 2009 at 01:11:26PM +0200, Johannes Sixt wrote:
> Josh Triplett schrieb:
> > I considered adding a -f/--force option, like gzip has, but writing an
> > archive to a tty seems like a sufficiently insane use case that I'll let
> > whoever actually needs that write the patch for it. ;)
>
> How about '--output -' instead?
Yeah, that seems significantly better than --force. Though I don't
particularly care for the '-' convention to mean 'stdout'; in principle
that ought to create a file named '-' in the current directory.
/dev/stdout makes more sense, and doesn't require any work on git's
part beyond this patch.
- Josh Triplett
^ permalink raw reply
* [PATCH v2] Update the usage bundle string.
From: Thiago Farina @ 2009-09-17 2:13 UTC (permalink / raw)
To: git; +Cc: Thiago Farina
Currently the usage bundle string is not well formatted.
Now it is formatted and the user can read the string much more easily.
Signed-off-by: Thiago Farina <tfransosi@gmail.com>
---
builtin-bundle.c | 12 ++++++++----
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/builtin-bundle.c b/builtin-bundle.c
index 9b58152..bade253 100644
--- a/builtin-bundle.c
+++ b/builtin-bundle.c
@@ -9,7 +9,11 @@
* bundle supporting "fetch", "pull", and "ls-remote".
*/
-static const char *bundle_usage="git bundle (create <bundle> <git rev-list args> | verify <bundle> | list-heads <bundle> [refname]... | unbundle <bundle> [refname]... )";
+static const char builtin_bundle_usage[] = "\
+ git bundle create <file> <git-rev-list args>\n\
+ git bundle verify <file>\n\
+ git bundle list-heads <file> [refname...]\n\
+ git bundle unbundle <file> [refname...]";
int cmd_bundle(int argc, const char **argv, const char *prefix)
{
@@ -19,8 +23,8 @@ int cmd_bundle(int argc, const char **argv, const char *prefix)
int bundle_fd = -1;
char buffer[PATH_MAX];
- if (argc < 3)
- usage(bundle_usage);
+ if (argc < 3)
+ usage(builtin_bundle_usage);
cmd = argv[1];
bundle_file = argv[2];
@@ -59,5 +63,5 @@ int cmd_bundle(int argc, const char **argv, const char *prefix)
return !!unbundle(&header, bundle_fd) ||
list_bundle_refs(&header, argc, argv);
} else
- usage(bundle_usage);
+ usage(builtin_bundle_usage);
}
--
1.6.5.rc0.dirty
^ permalink raw reply related
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