* Re: subversion-perl missing
From: Andreas Schwab @ 2011-09-26 21:11 UTC (permalink / raw)
To: Georg-Johann Lay; +Cc: Michael J Gruber, git
In-Reply-To: <4E80811B.4030309@gjlay.de>
Georg-Johann Lay <avr@gjlay.de> writes:
> svn identifies itself as
>
> > svn --version
>
> svn, version 1.6.2 (r37639)
> compiled Jun 19 2009, 12:21:15
openSUSE 11.1 contained subversion 1.5.2 (and 1.5.7 as an update), so
this is definitely not vanilla.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: git apply/am whitespace errors
From: Junio C Hamano @ 2011-09-26 20:39 UTC (permalink / raw)
To: git; +Cc: neubyr
In-Reply-To: <7vzkhr142r.fsf@alter.siamese.dyndns.org>
Subject: apply --whitespace=error: correctly report new blank lines at end
Earlier 77b15bb (apply --whitespace=warn/error: diagnose blank at EOF,
2009-09-03) cheated by reporting the line number of the hunk that contains
the offending line that adds new blank lines at the end of the file. All
other types of whitespace errors are reported with the line number in the
patch file that has the actual offending text.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* This is an interim workaround. fragment->linenr was added for the
specific purpose of reporting this type of error in the quoted patch,
and the field is not used for any other purpose, so it may be a better
fix to either rename it to hunk_linenr and use it directly without
introducing a new local variable in apply_one_fragment(), or pass
"linenr" as a parameter to parse_fragment() and pass it down the
callchain all the way through, or something like that.
builtin/apply.c | 11 +++++++++--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/builtin/apply.c b/builtin/apply.c
index f2edc52..092429a 100644
--- a/builtin/apply.c
+++ b/builtin/apply.c
@@ -2447,6 +2447,8 @@ static int apply_one_fragment(struct image *img, struct fragment *frag,
char *old, *oldlines;
struct strbuf newlines;
int new_blank_lines_at_end = 0;
+ int found_new_blank_lines_at_end = 0;
+ int hunk_linenr = frag->linenr;
unsigned long leading, trailing;
int pos, applied_pos;
struct image preimage;
@@ -2540,14 +2542,18 @@ static int apply_one_fragment(struct image *img, struct fragment *frag,
error("invalid start of line: '%c'", first);
return -1;
}
- if (added_blank_line)
+ if (added_blank_line) {
+ if (!new_blank_lines_at_end)
+ found_new_blank_lines_at_end = hunk_linenr;
new_blank_lines_at_end++;
+ }
else if (is_blank_context)
;
else
new_blank_lines_at_end = 0;
patch += len;
size -= len;
+ hunk_linenr++;
}
if (inaccurate_eof &&
old > oldlines && old[-1] == '\n' &&
@@ -2629,7 +2635,8 @@ static int apply_one_fragment(struct image *img, struct fragment *frag,
preimage.nr + applied_pos >= img->nr &&
(ws_rule & WS_BLANK_AT_EOF) &&
ws_error_action != nowarn_ws_error) {
- record_ws_error(WS_BLANK_AT_EOF, "+", 1, frag->linenr);
+ record_ws_error(WS_BLANK_AT_EOF, "+", 1,
+ found_new_blank_lines_at_end);
if (ws_error_action == correct_ws_error) {
while (new_blank_lines_at_end--)
remove_last_line(&postimage);
--
1.7.7.rc3
^ permalink raw reply related
* Re: Git is not scalable with too many refs/*
From: Julian Phillips @ 2011-09-26 20:28 UTC (permalink / raw)
To: Martin Fick; +Cc: git
In-Reply-To: <201109261401.38624.mfick@codeaurora.org>
On Mon, 26 Sep 2011 14:01:38 -0600, Martin Fick wrote:
-- snip --
> So, maybe you are correct, maybe my repo is the corner case?
> Is a repo which needs to be gced considered a corner case?
> Should git be able to detect that the repo is so in
> desperate need of gcing? Is it normal for git to need to gc
> right after a clone and then fetching ~100K refs?
Were you 100k refs packed before the gc? If not, perhaps your refs are
causing a lot of trouble for the merge sort? They will be written out
sorted to the packed-refs file, so the merge sort won't have to do any
real work when loading them after that...
> I am not sure what is right here, if this patch makes a repo
> which needs gcing degrade 5 to 10 times worse than the
> benefit of this patch, it still seems questionable to me.
Well - it does this _for your repo_, that doesn't automatically mean
that it does generally, or frequently. For instance, none of my normal
repos that have a lot of refs are Gerrit ones, and I wouldn't be
surprised if they benefitted from the merge sort (assuming that I am
right that the merge sort is taking a long time on your gerrit refs).
Besides, you would be better off running gc, and thus getting the
benefit too.
>> Random thought. What happens to the with compression
>> case if you leave the commit in, but add a sleep(15) to
>> the end of sort_refs_list?
>
> Why, what are you thinking? Hmm, I am trying this on the
> non gced repo and it doesn't seem to be completing (no cpu
> usage)! It appears that perhaps it is being called many
> times (the sleeping would explain no cpu usage)?!? This
> could be a real problem, this should only get called once
> right?
I was just wondering if the time taken to get the refs was changing the
interaction with something else. Not very likely, but ...
I added a print statement, and it was called four times when I had
unpacked refs, and once with packed. So, maybe you are hitting some
nasty case with unpacked refs. If you use a print statement instead of
a sleep, how many times does sort_refs_lists get called in your unpacked
case? It may well also be worth calculating the time taken to do the
sort.
--
Julian
^ permalink raw reply
* Re: Git is not scalable with too many refs/*
From: Junio C Hamano @ 2011-09-26 20:07 UTC (permalink / raw)
To: Martin Fick; +Cc: Julian Phillips, git
In-Reply-To: <201109261401.38624.mfick@codeaurora.org>
Martin Fick <mfick@codeaurora.org> writes:
> After a gc, the repo does perform the similar to the
> uncompressed one (which was achieved via gc). After gc, it
> takes ~.05s do to a 'git branch' with 1.7.6 and
> git.1.7.7.rc0.72.g4b5ea. It also takes a bit more than 15s
> with the patch reverted. So it appears that compression is
> not likely the culprit, but rather the need to be gced.
Isn't packing refs part of "gc" these days?
^ permalink raw reply
* Re: config-file includes
From: Jeff King @ 2011-09-26 20:05 UTC (permalink / raw)
To: David Aguilar
Cc: Nguyen Thai Ngoc Duy, git, Michael Haggerty, Jay Soffian,
Junio C Hamano, Jakub Narebski
In-Reply-To: <20110926192126.GA55743@gmail.com>
On Mon, Sep 26, 2011 at 09:21:27PM +0200, David Aguilar wrote:
> > > [include-ifdef "has-pager-scripts"]
> > > path = ~/.gitconfig-pager
> > >
> > > where "has-pager-scripts" would be a magic flag compiled into git
> > > versions that understand that config.
> >
> > But how far would you go with conditional expressions?
>
> This syntax is simple yet would solve one problem I run into
> often. It could be used for the case where some settings
> (e.g. diff.tool, merge.tool) are different on OS X and Linux.
>
> [include-ifdef "darwin"]
> path = ~/.gitconfig-darwin
Thanks for another concrete example.
I'm not sure how that would be implemented, though. I don't think git
knows that it is compiled for darwin. Would it just be running "uname
-s" behind the scenes? Should it happen at runtime, or as part of the
compile process?
We could allow arbitrary shell code like:
[include-if "test `uname -s` -eq Darwin"]
Very flexible, though it makes me think we are getting a little
overboard. And it's an extra shell invocation whenever we read the
config, which is ugly.
-Peff
^ permalink raw reply
* Re: Git is not scalable with too many refs/*
From: Martin Fick @ 2011-09-26 20:01 UTC (permalink / raw)
To: Julian Phillips; +Cc: git
In-Reply-To: <88a00eadcbb4a7946dbe8d70dd0e933d@quantumfyre.co.uk>
On Monday, September 26, 2011 12:37:10 pm Julian Phillips
wrote:
> On Mon, 26 Sep 2011 12:07:52 -0600, Martin Fick wrote:
> -- snip --
>
> > Ahh, I think I have some more clues. So while this
> > change does not speed things up for me normally, I
> > found a case where it does! I set my .git/config to
> > have
> >
> > [core]
> >
> > compression = 0
> >
> > and ran git-gc on my repo. Now, with a modern git with
> > this optimization in it (1.7.6, 1.7.7.rc0...), 'git
> > branch' is almost instantaneous (.05s)! But, if I
> > revert c774aa it takes > ~15s.
>
> I don't understand this. I don't see why
> core.compression should have anything to do with refs
> ...
>
> > So, it appears that this optimization is foiled by
> > compression? In the case when this optimization helps,
> > it save about 15s, when it hurts (with compression),
> > it seems to cost > 3mins. I am not sure this
> > optimization is worth it? Would there be someway for
> > it to adjust to the repo conditions?
>
> Well, in the case I tried it was 1.2s vs 40s. It would
> seem that you have managed to find some corner case. It
> doesn't seem right to punish everyone who has large
> numbers of refs by making their commands take orders of
> magnitude longer to save one person 3m. Much better to
> find, understand and fix the actual cause.
I am not sure mine is the corner case, it is a real repo
(albeit a Gerrit repo with strange refs/changes), while it
sounds like yours is a test repo. It seems likely that
whatever you did to create the test repo makes it perform
well? I am also guessing that it is not the refs which are
the problem but the objects since the refs don't get
compressed do they? Does your repo have real data in it
(not just 100K refs)?
My repo compressed is about ~2G and uncompressed is ~1.1G
Yes, the compressed one is larger than the uncompressed one.
Since the compressed repo above was larger, I thought that I
should at lest gc it. After git gc, it is ~1.1G, so it
looks like the size difference was really because of not
having gced it at first after fetching the 100K refs.
After a gc, the repo does perform the similar to the
uncompressed one (which was achieved via gc). After gc, it
takes ~.05s do to a 'git branch' with 1.7.6 and
git.1.7.7.rc0.72.g4b5ea. It also takes a bit more than 15s
with the patch reverted. So it appears that compression is
not likely the culprit, but rather the need to be gced.
So, maybe you are correct, maybe my repo is the corner case?
Is a repo which needs to be gced considered a corner case?
Should git be able to detect that the repo is so in
desperate need of gcing? Is it normal for git to need to gc
right after a clone and then fetching ~100K refs?
I am not sure what is right here, if this patch makes a repo
which needs gcing degrade 5 to 10 times worse than the
benefit of this patch, it still seems questionable to me.
> I really can't see what effect core.compression can have
> on loading the ref_list. Certainly the sort doesn't
> load anything from the object database. It would be
> really good to profile and find out what is taking all
> the time - I am assuming that the CPU is at 100% for the
> 3+ minutes?
Yes, 100% CPU (I mostly run the tests at least twice and
have 8G of RAM, so I think the entire repo gets cached).
> Random thought. What happens to the with compression
> case if you leave the commit in, but add a sleep(15) to
> the end of sort_refs_list?
Why, what are you thinking? Hmm, I am trying this on the
non gced repo and it doesn't seem to be completing (no cpu
usage)! It appears that perhaps it is being called many
times (the sleeping would explain no cpu usage)?!? This
could be a real problem, this should only get called once
right?
-Martin
--
Employee of Qualcomm Innovation Center, Inc. which is a
member of Code Aurora Forum
^ permalink raw reply
* Re: [PATCH] gitweb: Add js=1 before an URI fragment to fix line number links
From: Peter Stuge @ 2011-09-26 19:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v62kf2jf4.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> > Signed-off-by: Peter Stuge <peter@stuge.se>
>
> Care to elaborate a bit more please?
Okey. I thought subject together with change would be clear enough. :)
> Explanation of what you are fixing is totally lacking.
The subject sums it up, if briefly.
> What happens with the current code, why it is wrong, and how the
> updated pattern improves the result in what way?
Current code generates links to line numbers like ../file.c#l1234;js=1
It is wrong because a URI fragment always goes at the end.
The updated pattern improves this by treating # like end of string,
to detect js=1 also before # and not only at end of string.
The updated code improves this by injecting [?;]js=1 before # if
one exists, or at end of string (like before) otherwise.
> > -var jsExceptionsRe = /[;?]js=[01]$/;
> > +var jsExceptionsRe = /[;?]js=[01](#.*)?$/;
..
> > - if (!jsExceptionsRe.test(link)) { // =~ /[;?]js=[01]$/;
> > - link.href +=
> > - (link.href.indexOf('?') === -1 ? '?' : ';') + 'js=1';
> > + if (!jsExceptionsRe.test(link)) { // =~ /[;?]js=[01](#.*)?$/;
> > + link.href = link.href.replace(/(#|$)/,
> > + (link.href.indexOf('?') === -1 ? '?' : ';') + 'js=1$1');
To test how this works you can try it on
http://git.libusb.org/?p=libusb.git;a=blob;f=COPYING
where the change is in production. Compare the line number links with
those generated by another gitweb with javascript-actions enabled.
//Peter
^ permalink raw reply
* Re: git apply/am whitespace errors
From: Junio C Hamano @ 2011-09-26 19:44 UTC (permalink / raw)
To: neubyr; +Cc: git
In-Reply-To: <CALFxCvxxbsgZnhqK9nN7h=1ASJzfDJ7aVF+rM-8RUyKhpv8FzQ@mail.gmail.com>
neubyr <neubyr@gmail.com> writes:
> I am getting following error while applying a patch using git-apply.
>
> {{{
> /tmp/patches/ticket11/0002-Commit-for-ticket-11.patch:51: new blank line at EOF.
> }}}
>
> What does number '51' after colon ':' indicate?
Looks like "apply --whitespace=error" is not reporting the optimal line
number for the blank at EOF case.
It ideally should point at the line number of the offending patch in the
input patch file (i.e. "cat -n .git/apply-rebase/patch" would show the "+"
line that adds a blank line on 51th line), but it seems that it instead
points at the beginning of the hunk that introduces the issue.
E.g. if we add an empty line at the end of COPYING (which is 360 lines
long), we would get a patch file that looks like this:
1 diff --git a/COPYING b/COPYING$
2 index 536e555..ccf4c7f 100644$
3 --- a/COPYING$
4 +++ b/COPYING$
5 @@ -358,3 +358,4 @@ proprietary programs. If your program is a subroutine library, you may$
6 consider it more useful to permit linking proprietary applications with the$
7 library. If this is what you want to do, use the GNU Lesser General$
8 Public License instead of this License.$
9 +$
and "git apply --whitespace=error P.diff" would report the hunk that
begins at line 5 is wrong:
P.diff:5: new blank line at EOF.
+
fatal: 1 line adds whitespace errors.
when the true offending line is at line #9.
^ permalink raw reply
* Thoughts on gitk's memory footprint over linux-2.6.git
From: Martin Langhoff @ 2011-09-26 19:38 UTC (permalink / raw)
To: Git Mailing List
In an odd turn of affairs, I am managing a bit of kernel development,
and even writing the odd patch myself. As usual, gitk is excellent to
visualize what's new in the tree when developers in the team commit
and push new stuff.
However, I find it extremely annoying over the kernel tree, due to its
memory footprint. It is not the only thing I am running, (Chrome
Browser, Gnome3, Firefox, many gnome Terminal windows, emacs), and
given that I am looking at "just a couple of commits" I don't feel
opening a few gitk instances should be problematic... except that it
is.
Each gitk instance wants to gobble up >1GB of memory! It really wants
to show me the "Linux-2.6.12-rc2(...)Initial git repository build."
commit.
Aren't kernel hackers hurting with this? This box blazes through a
kernel compile, but only has 2GB RAM. Regardless of amount of RAM,
firing up gitk gobbles up >1G and untold CPU cycles.
My tk isn't really up to par, but... here's a stupid idea.
- In start_rev_list, run git log into a tempfile, and concurrently
open the same file for reading, as fd
- Read in a bound number of commits, say 10000 ("just" 200MB)
- If we haven't made it to the end of the file, remember the offset
and keep reading the file, counting matches of /^commit/ to get a
commit count and size the scroll back
- re-activate the reading as required...
There are of course tricky aspects of concurrent programming at hand.
I am not sure what concurrency model gitk has now, but it does a great
job of not blocking and not getting confused.
Tricky Tk programming, or go buy some RAM? Yeah, I know.
Now why didn't I pack that Tk book when I moved here?
m
--
martin.langhoff@gmail.com
martin@laptop.org -- Software Architect - OLPC
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: [PATCH] gitweb: Add js=1 before an URI fragment to fix line number links
From: Junio C Hamano @ 2011-09-26 19:27 UTC (permalink / raw)
To: Peter Stuge; +Cc: git
In-Reply-To: <1317060642-25488-1-git-send-email-peter@stuge.se>
Peter Stuge <peter@stuge.se> writes:
> Signed-off-by: Peter Stuge <peter@stuge.se>
> ---
Care to elaborate a bit more please? Explanation of what you are fixing
is totally lacking. What happens with the current code, why it is wrong,
and how the updated pattern improves the result in what way?
> gitweb/static/js/javascript-detection.js | 8 ++++----
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/gitweb/static/js/javascript-detection.js b/gitweb/static/js/javascript-detection.js
> index 93dd2bd..003acd1 100644
> --- a/gitweb/static/js/javascript-detection.js
> +++ b/gitweb/static/js/javascript-detection.js
> @@ -16,7 +16,7 @@
> * and other reasons to not add 'js=1' param at the end of link
> * @constant
> */
> -var jsExceptionsRe = /[;?]js=[01]$/;
> +var jsExceptionsRe = /[;?]js=[01](#.*)?$/;
>
> /**
> * Add '?js=1' or ';js=1' to the end of every link in the document
> @@ -33,9 +33,9 @@ function fixLinks() {
> var allLinks = document.getElementsByTagName("a") || document.links;
> for (var i = 0, len = allLinks.length; i < len; i++) {
> var link = allLinks[i];
> - if (!jsExceptionsRe.test(link)) { // =~ /[;?]js=[01]$/;
> - link.href +=
> - (link.href.indexOf('?') === -1 ? '?' : ';') + 'js=1';
> + if (!jsExceptionsRe.test(link)) { // =~ /[;?]js=[01](#.*)?$/;
> + link.href = link.href.replace(/(#|$)/,
> + (link.href.indexOf('?') === -1 ? '?' : ';') + 'js=1$1');
> }
> }
> }
^ permalink raw reply
* Re: Can a git changeset be created with no parent
From: Junio C Hamano @ 2011-09-26 19:25 UTC (permalink / raw)
To: Carlos Martín Nieto; +Cc: vra5107, git
In-Reply-To: <1316961212.4388.5.camel@centaur.lab.cmartin.tk>
Carlos Martín Nieto <cmn@elego.de> writes:
> On Sun, 2011-09-25 at 07:15 -0700, vra5107 wrote:
>> Hi
>>
>> I am currently in the process of converting a large hg repository.
>> One of the changesets has no parents assigned. So to mirror that is it
>> possible to create a git changeset that doesnot have a parent ?
>
> They're called commits in git, and yes it's possible. They are called
> orphan commits and it's what you get when you do the first commit in the
Just to set the terminology straight, s/orphan/root/;
> repository.
>
> You can do this with 'git checkout --orphan somebranch'. Notice that the
The orphan here refers to the fact that the next commit will not be a
child of the current commit. The resulting one is a "root" commit.
^ permalink raw reply
* Re: config-file includes
From: David Aguilar @ 2011-09-26 19:21 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Jeff King, git, Michael Haggerty, Jay Soffian, Junio C Hamano,
Jakub Narebski
In-Reply-To: <CACsJy8BAVRAct=sxTpZ+b-ft1OjbY9oZG6uEXrcsTXw3CXnwSg@mail.gmail.com>
On Mon, Sep 26, 2011 at 08:45:58PM +1000, Nguyen Thai Ngoc Duy wrote:
> On Sat, Sep 24, 2011 at 5:58 AM, Jeff King <peff@peff.net> wrote:
>
> Another thing is, what if I want to exclude certain part of the included config?
>
> [1] http://thread.gmane.org/gmane.comp.version-control.git/163285/focus=163288
>
> > [1] I want conditional inclusion because sometimes the rules for config
> > entries changes from version to version. For example, I have
> > pager.diff set to a script in my ~/.gitconfig. But older versions of
> > git don't understand non-boolean values and barf. I'd really like to
> > do something like:
> >
> > [include-ifdef "has-pager-scripts"]
> > path = ~/.gitconfig-pager
> >
> > where "has-pager-scripts" would be a magic flag compiled into git
> > versions that understand that config.
>
> But how far would you go with conditional expressions?
> --
> Duy
This syntax is simple yet would solve one problem I run into
often. It could be used for the case where some settings
(e.g. diff.tool, merge.tool) are different on OS X and Linux.
[include-ifdef "darwin"]
path = ~/.gitconfig-darwin
--
David
^ permalink raw reply
* git apply/am whitespace errors
From: neubyr @ 2011-09-26 19:03 UTC (permalink / raw)
To: git
I am getting following error while applying a patch using git-apply.
{{{
/tmp/patches/ticket11/0002-Commit-for-ticket-11.patch:51: new blank line at EOF.
}}}
What does number '51' after colon ':' indicate? There aren't 51 lines
in that patch file. Also, I had used check and stat options before
applying match and it didn't indicate any warnings/errors.
I tried git am interactive and it gave following error:
{{{
Applying: Commit for [ticket:11]. Created a directory to download lens
files and added .include_in_git empty hidden file.
/tmp/galaxy/.git/rebase-apply/patch:10: new blank line at EOF.
+
warning: 1 line adds whitespace errors.
Commit Body is:
}}}
I am trying to add a directory with a hidden empty file. Any
elaboration on above warning/error messages will be really helpful.
--
thanks,
neuby.r
^ permalink raw reply
* Re: Git is not scalable with too many refs/*
From: Christian Couder @ 2011-09-26 18:56 UTC (permalink / raw)
To: Martin Fick; +Cc: Christian Couder, git
In-Reply-To: <201109261147.56607.mfick@codeaurora.org>
On Monday 26 September 2011 19:47:56 Martin Fick wrote:
> On Monday, September 26, 2011 06:41:04 am Christian Couder
> wrote:
> >
> > Are all these refs packed?
>
> I think so, is there a way to find out for sure?
After "git pack-refs --all" I get:
$ find .git/refs/ -type f
.git/refs/remotes/origin/HEAD
.git/refs/stash
So I suppose that if such a find gives you only a few files all (or most of)
your refs are packed.
Best regards,
Christian.
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2011, #06; Wed, 21)
From: Junio C Hamano @ 2011-09-26 18:52 UTC (permalink / raw)
To: git; +Cc: Scott Chacon
In-Reply-To: <CAP2yMaL=Ox7mFQSA8yyOB9CoBaa_pQQ3bE4B9FugOnfJCT6XeA@mail.gmail.com>
Scott Chacon <schacon@gmail.com> writes:
> On Fri, Sep 23, 2011 at 12:29 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> It just occurred to me that https://github.com/git/git repository might be
>> the one you are talking about, but that repository is not even mine. The
>> page at https://github.com/git says git@logicalawesome.com is its contact
>> person.
>>
>> I _suspect_ it is set up to mirror from my k.org repository and obviously
>> nothing is updated from that route for the past few weeks. It is correct
>> to say "html branch in that repository is no longer updated", but I cannot
>> do anything about that repository ;-).
>
> git/git is a mirror I set up from k.org years ago for git-scm.com. I
> believe you've been a collaborator on it for a while now, so you can
> push to it if you'd like. The mirroring system is down since k.org
> died and I've since moved it off the host I had been using to Heroku,
> so I can't do the mirroring that way anymore. If you want to push to
> it I'll leave it there, otherwise I'll reroot your repo to be the head
> of the GitHub network instead.
Ok, to clarify this discussion for people who have been pulling from me
and have been wondering where to reset their "origin" to...
* I'll start to also push into https://github.com/git/git/ directly,
treating it like git://repo.or.cz/alt-git.git/ and other secondary
distribution points, that have the integration branches, todo, html and
man.
* Eventually git://git.kernel.org/pub/scm/git/git.git/ will again start
receiving my direct pushes just like it used to. The secondary
distribution points will also get my pushes directly (I've made sure
with Scott that mirroring into https://github.com/git/git/ from my
k.org repository will stay turned off).
* https://github.com/gitster/git.git/ will stay a mirror of my private
development repository with the topic branches (but without non-source
branches like html and mah).
I haven't figured out how the preformatted documentation branches will be
managed in the longer term, as it seems likely that I no longer would have
the post-update hook access to update them upon pushing into my k.org
repository. I might end up dropping these branches altogether if it gets
too cumbersome for me to maintain, but I do not know yet.
^ permalink raw reply
* [BUG?] git fetch -p -t prunes all non-tag refs
From: Ben Boeckel @ 2011-09-26 18:47 UTC (permalink / raw)
To: git
Hi,
When the --prune and --tags options are given to git fetch together, all
non-tag refs are pruned because only tags are looked at and when pruning
it appears as if the branches have disappeared and are therefore deleted
locally. Maybe this is an unintentional wanted behavior, but it should
at least be documented that the combination causes this to happen.
git-1.7.6.2-1.fc15.x86_64
Appears to still be there in master (85e9c7e) from looking at the logs.
--Ben
^ permalink raw reply
* Re: Git is not scalable with too many refs/*
From: Julian Phillips @ 2011-09-26 18:37 UTC (permalink / raw)
To: Martin Fick; +Cc: git
In-Reply-To: <201109261207.52736.mfick@codeaurora.org>
On Mon, 26 Sep 2011 12:07:52 -0600, Martin Fick wrote:
-- snip --
> Ahh, I think I have some more clues. So while this change
> does not speed things up for me normally, I found a case
> where it does! I set my .git/config to have
>
> [core]
> compression = 0
>
> and ran git-gc on my repo. Now, with a modern git with this
> optimization in it (1.7.6, 1.7.7.rc0...), 'git branch' is
> almost instantaneous (.05s)! But, if I revert c774aa it
> takes > ~15s.
I don't understand this. I don't see why core.compression should have
anything to do with refs ...
> So, it appears that this optimization is foiled by
> compression? In the case when this optimization helps, it
> save about 15s, when it hurts (with compression), it seems
> to cost > 3mins. I am not sure this optimization is worth
> it? Would there be someway for it to adjust to the repo
> conditions?
Well, in the case I tried it was 1.2s vs 40s. It would seem that you
have managed to find some corner case. It doesn't seem right to punish
everyone who has large numbers of refs by making their commands take
orders of magnitude longer to save one person 3m. Much better to find,
understand and fix the actual cause.
I really can't see what effect core.compression can have on loading the
ref_list. Certainly the sort doesn't load anything from the object
database. It would be really good to profile and find out what is
taking all the time - I am assuming that the CPU is at 100% for the 3+
minutes?
Random thought. What happens to the with compression case if you leave
the commit in, but add a sleep(15) to the end of sort_refs_list?
--
Julian
^ permalink raw reply
* [PATCH] gitweb: Add js=1 before an URI fragment to fix line number links
From: Peter Stuge @ 2011-09-26 18:10 UTC (permalink / raw)
To: git
Signed-off-by: Peter Stuge <peter@stuge.se>
---
gitweb/static/js/javascript-detection.js | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/gitweb/static/js/javascript-detection.js b/gitweb/static/js/javascript-detection.js
index 93dd2bd..003acd1 100644
--- a/gitweb/static/js/javascript-detection.js
+++ b/gitweb/static/js/javascript-detection.js
@@ -16,7 +16,7 @@
* and other reasons to not add 'js=1' param at the end of link
* @constant
*/
-var jsExceptionsRe = /[;?]js=[01]$/;
+var jsExceptionsRe = /[;?]js=[01](#.*)?$/;
/**
* Add '?js=1' or ';js=1' to the end of every link in the document
@@ -33,9 +33,9 @@ function fixLinks() {
var allLinks = document.getElementsByTagName("a") || document.links;
for (var i = 0, len = allLinks.length; i < len; i++) {
var link = allLinks[i];
- if (!jsExceptionsRe.test(link)) { // =~ /[;?]js=[01]$/;
- link.href +=
- (link.href.indexOf('?') === -1 ? '?' : ';') + 'js=1';
+ if (!jsExceptionsRe.test(link)) { // =~ /[;?]js=[01](#.*)?$/;
+ link.href = link.href.replace(/(#|$)/,
+ (link.href.indexOf('?') === -1 ? '?' : ';') + 'js=1$1');
}
}
}
--
1.7.4.1.343.ga91df.dirty
^ permalink raw reply related
* Re: Git is not scalable with too many refs/*
From: Martin Fick @ 2011-09-26 18:07 UTC (permalink / raw)
To: git; +Cc: Julian Phillips
In-Reply-To: <201109260915.29285.mfick@codeaurora.org>
On Monday, September 26, 2011 09:15:29 am Martin Fick wrote:
> OK, I have found what I believe is another performance
> regression for large ref counts (~100K).
>
> When I run git br on my repo which only has one branch,
> but has ~100K refs under ref/changes (a gerrit repo), it
> takes normally 3-6mins depending on whether my caches
> are fresh or not. After bisecting some older changes, I
> noticed that this ref seems to be where things start to
> get slow: c774aab98ce6c5ef7aaacbef38da0a501eb671d4
>
>
> commit c774aab98ce6c5ef7aaacbef38da0a501eb671d4
> Author: Julian Phillips <julian@quantumfyre.co.uk>
> Date: Tue Apr 17 02:42:50 2007 +0100
>
> refs.c: add a function to sort a ref list, rather
> then sorting on add
>
> Rather than sorting the refs list while building it,
> sort in one
> go after it is built using a merge sort. This has a
> large
> performance boost with large numbers of refs.
>
> It shouldn't happen that we read duplicate entries
> into the same
> list, but just in case sort_ref_list drops them if
> the SHA1s are
> the same, or dies, as we have no way of knowing which
> one is the
> correct one.
>
> Signed-off-by: Julian Phillips
> <julian@quantumfyre.co.uk>
> Acked-by: Linus Torvalds
> <torvalds@linux-foundation.org> Signed-off-by: Junio C
> Hamano <junkio@cox.net>
>
>
>
> which is a bit strange since that commit's purpose was to
> actually speed things up in the case of many refs. Just
> to verify, I reverted the commit on 1.7.7.rc0.73 and
> sure enough, things speed up down to the 14-20s range
> depending on caching.
>
> If this change does not actually speed things up, should
> it be reverted? Or was there a bug in the change that
> makes it not do what it was supposed to do?
Ahh, I think I have some more clues. So while this change
does not speed things up for me normally, I found a case
where it does! I set my .git/config to have
[core]
compression = 0
and ran git-gc on my repo. Now, with a modern git with this
optimization in it (1.7.6, 1.7.7.rc0...), 'git branch' is
almost instantaneous (.05s)! But, if I revert c774aa it
takes > ~15s.
So, it appears that this optimization is foiled by
compression? In the case when this optimization helps, it
save about 15s, when it hurts (with compression), it seems
to cost > 3mins. I am not sure this optimization is worth
it? Would there be someway for it to adjust to the repo
conditions?
Thanks,
-Martin
--
Employee of Qualcomm Innovation Center, Inc. which is a
member of Code Aurora Forum
^ permalink raw reply
* Re: [PATCH] git-remote rename should match whole string when renaming remote ref directory
From: Junio C Hamano @ 2011-09-26 18:04 UTC (permalink / raw)
To: Benny Halevy; +Cc: Martin von Zweigbergk, git, Benny Halevy
In-Reply-To: <1317045186-25206-1-git-send-email-benny@tonian.com>
Benny Halevy <benny@tonian.com> writes:
> From: Benny Halevy <bhalevy@tonian.com>
>
> Otherwise, with two remotes: test, test-2
> git remote rename test test-
> ends up with:
> .git/refs/remotes/test-
> .git/refs/remotes/test--2
> ...
> diff --git a/builtin/remote.c b/builtin/remote.c
> index f2a9c26..5443e71 100644
> --- a/builtin/remote.c
> +++ b/builtin/remote.c
> @@ -571,7 +571,7 @@ static int read_remote_branches(const char *refname,
> const char *symref;
>
> strbuf_addf(&buf, "refs/remotes/%s", rename->old);
> - if (!prefixcmp(refname, buf.buf)) {
> + if (!strcmp(refname, buf.buf)) {
At this point of the code, refname has "refs/remotes/test/foo" and it is
queued to later rename it to "refs/remotes/test-/foo" (the next invocation
of this function will see "refs/remotes/test/bar" in refname). And the
strbuf buf.buf has "refs/remotes/test"; your !strcmp(refname, buf.buf)
would never trigger, I suspect.
Isn't 60e5eee (remote: "rename o foo" should not rename ref "origin/bar",
2011-09-01) the correct fix for this issue? It makes buf.buf properly
terminated with a slash, to contain "refs/remotes/test/" so that prefixcmp
properly matches it with "refs/remotes/test/foo" but not with refs under
other hierarchies like "refs/remotes/test-2/anything".
Thanks.
^ permalink raw reply
* Re: More Beginning Git Questions
From: Jakub Narebski @ 2011-09-26 18:03 UTC (permalink / raw)
To: tactical; +Cc: git
In-Reply-To: <1aec7c1qq0n56.sxybjnsj6ngr$.dlg@40tude.net>
tactical <a5158017@nepwk.com> writes:
> Konstantin Khomoutov wrote:
>
>>>>> From what I read, detached heads are subject to garbage collection.
>>>>
>>>> No, HEAD is protected against garbage collecting. To be sure you
>>>> should name a branch when switching branches, though reflog would
>>>> protect you for 30 days (by default) even if you don't do that.
>>>
>>> So Git doesn't really support anonymous branching as part of a normal
>>> workflow.
>>
>> I perceive a certain logical fallacy here: you cannot switch between
>> anything anonymous because to switch, you should somehow identify
>> something to switch to--a name in whatever sense we put into this word.
>
> In Mercurial, you can just update to a particular changeset (and you
> identify that changeset by repository-local revision number or globally
> unique ID) and then commit again. The point is that there's no need to
> give a label to a head in Mercurial (although you can if you want to, using
> Mercurial bookmarks, which are basically the same as what Git uses).
>
> Here's an example of anonymous branching:
>
> c:\test>hg init
>
> c:\test>echo test>foo
>
> c:\test>hg commit --addremove -m initial
> adding foo
>
> c:\test>echo first>>foo
>
> c:\test>hg commit -m first
>
> c:\test>hg log
> changeset: 1:3e895ec28d6c
> tag: tip
> user: tactical
> date: Mon Sep 26 01:39:46 2011 +0100
> summary: first
>
> changeset: 0:b51644bb3450
> user: tactical
> date: Mon Sep 26 01:39:40 2011 +0100
> summary: initial
>
> c:\test>hg update 0
> 1 files updated, 0 files merged, 0 files removed, 0 files unresolved
>
> c:\test>echo second>>foo
>
> c:\test>hg commit -m second
> created new head
>
> c:\test>hg glog
> @ changeset: 2:35c82a7e7de1
> | tag: tip
> | parent: 0:b51644bb3450
> | user: tactical
> | date: Mon Sep 26 01:40:10 2011 +0100
> | summary: second
> |
> | o changeset: 1:3e895ec28d6c
> |/ user: tactical
> | date: Mon Sep 26 01:39:46 2011 +0100
> | summary: first
> |
> o changeset: 0:b51644bb3450
> user: tactical
> date: Mon Sep 26 01:39:40 2011 +0100
> summary: initial
>
> I now have two anonymous branches, and these will never be garbage
> collected. I can easily update to either branch with "hg update 1" or "hg
> update 2" (or "hg update 0" again, if i want to create yet another
> anonymous branch).
In my opinion the need to examine either log ('hg glog') or heads
('hg heads'?) to see how to switch to anonymous branch is a PITA
that far outweights the need to name branches (to give a temporary,
local-only branch name) in Git.
Nb. by using "detached HEAD" for anonymous branch I meant the
following:
$ git checkout --detach
$ ...
$ <work on detached head>
worth saving?
Y. $ git branch -b t foo/temp
$ git checkout <other branch>
N. $ git checkout <other branch>
> > The branch names is just a way to not mess with
> > SHA-1 names of commits (and to have references to those commits to keep
> > them out of consideration for garbage collection).
> > Hence the idea to demand support for anonymous branches in Git's model
> > is just unfounded.
>
> I think it's simply a weakness of Git. There are zero problems with
> anonymous branching in Mercurial, and it's a very powerful and simple
> system.
IMVVVHO it is just remains of bad initial design decision of Mercurial
about representing branches ;-PPPPPPP
Only now Mercurial has something (transferable bookmarks) which
approaches flexibility and usability of Git branches. It took them
how long... and even then there is a [supposedly] user-friendly but
flexibility-reducing notion that branch (bookmark) names are global.
Not that Git didn't and doesn't have its share of bad design decisions
(like autimatically committing a merge).
--
Jakub Narębski
^ permalink raw reply
* Re: [PATCH 2/2] templates/hooks--*: don't refer to contrib hooks
From: Junio C Hamano @ 2011-09-26 17:52 UTC (permalink / raw)
To: Gerrit Pape; +Cc: git
In-Reply-To: <20110926125932.27854.qmail@804c778e7e6607.315fe32.mid.smarden.org>
Gerrit Pape <pape@smarden.org> writes:
> Simplify the sample post-receive hook to not refer to some location of a
> contrib hook that might be installed in different locations on different
> systems. Instead simply provide a sample file that does nothing just as
> the post-commit sample hook.
>
> Signed-off-by: Gerrit Pape <pape@smarden.org>
> ---
> templates/hooks--post-receive.sample | 12 ++----------
> 1 files changed, 2 insertions(+), 10 deletions(-)
>
> diff --git a/templates/hooks--post-receive.sample b/templates/hooks--post-receive.sample
> index 7a83e17..5b1771f 100755
> --- a/templates/hooks--post-receive.sample
> +++ b/templates/hooks--post-receive.sample
> @@ -2,14 +2,6 @@
> #
> # An example hook script for the "post-receive" event.
> #
> +# To enable this hook, rename this file to "post-receive".
>
> +: Nothing
I removed the "-" lines above. Looking at the result, I really have to
wonder if it makes much sense to keep the file here. It is not even an
example anymore, and the user does not gain anything by enabling it,
following the suggestion.
Let's instead remove the file altogether, Ok?
^ permalink raw reply
* Re: [ANNOUNCE] Git 1.7.7.rc3
From: Junio C Hamano @ 2011-09-26 17:49 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: git
In-Reply-To: <CACBZZX77ZhdS1cyiYpjJcuvSnJsv15FUumPWeZOcwh_b41c2FQ@mail.gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> On Sat, Sep 24, 2011 at 01:41, Junio C Hamano <gitster@pobox.com> wrote:
>
>> Also the following public repositories all have a copy of the v1.7.7-rc3
>> tag and the master branch that the tag points at:
>
> The 1.7.7-rc* series still doesn't compile on older Red Hat machines
> because 4c1be38b4a236403a329187acb70591a7fd92150 hasn't been included
> in it.
>
> Could you please include that in the final 1.7.7? It would be a PITA
> to have to work around that.
I somehow got an impression from an other earlier thread that this only
affect ancient and abandoned releases of some distros.
Will merge. Thanks for prodding.
^ permalink raw reply
* Re: [ANNOUNCE] Git 1.7.7.rc3
From: Jakub Narebski @ 2011-09-26 17:48 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: Junio C Hamano, git, Linux Kernel
In-Reply-To: <CACBZZX77ZhdS1cyiYpjJcuvSnJsv15FUumPWeZOcwh_b41c2FQ@mail.gmail.com>
Ævar Arnfjörð Bjarmason wrote:
> On Sat, Sep 24, 2011 at 01:41, Junio C Hamano <gitster@pobox.com> wrote:
>
> > Also the following public repositories all have a copy of the v1.7.7-rc3
> > tag and the master branch that the tag points at:
>
> The 1.7.7-rc* series still doesn't compile on older Red Hat machines
> because 4c1be38b4a236403a329187acb70591a7fd92150 hasn't been included
> in it.
>
> Could you please include that in the final 1.7.7? It would be a PITA
> to have to work around that.
It looks like I was too optimistic in
"Re: What's cooking in git.git (Sep 2011, #06; Wed, 21)"
http://thread.gmane.org/gmane.comp.version-control.git/181885/focus=181935
JN> Yes, that is what I mean... but that it is only because I use old
JN> version of asciidoc (7.1.2).
JN>
JN> "make doc" (which is part of "make rpm") fails on my box with
JN>
JN> ASCIIDOC gitnamespaces.html
JN> ERROR: gitnamespaces.txt: line 9: second section must be named SYNOPSIS
JN> make[1]: *** [gitnamespaces.html] Error 1
JN>
JN> > If the reason the documentation fix for "master" is needed is because a
JN> > new feature scheduled for the upcoming release has broken documentation,
JN> > then wouldn't we need the fix before the release, whether you are working
JN> > on your patch or not? How can it be not urgent if that is the case?
JN> >
JN> > On my boxes with recent Debian, Ubuntu, and F14, I am not suffering from
JN> > the lack of the workaround, but if distros need the workaround, then the
JN> > time to apply it is now, not post release.
JN>
JN> I don't think _modern_ distributions need this workaround... asciidoc 8.4.5
JN> which fixed the issue with "Synopsis" section was released 2009-05-24:
JN>
JN> http://www.methods.co.nz/asciidoc/CHANGELOG.html
JN>
JN> Version 8.4.5 (2009-05-24)
JN> --------------------------
JN> Additions and changes
JN> ~~~~~~~~~~~~~~~~~~~~~
JN>
JN> * Added manpage "Name" and "Synopsis" section title customization to
JN> languages configuration files.
JN> * "Synopsis" manpage section no longer mandatory.
JN> [...]
--
Jakub Narębski
^ permalink raw reply
* Re: Git is not scalable with too many refs/*
From: Martin Fick @ 2011-09-26 17:47 UTC (permalink / raw)
To: Christian Couder; +Cc: git, Christian Couder
In-Reply-To: <CAP8UFD3TWQHU0wLPuxMDnc3bRSz90Yd+yDMBe03kofeo-nr7yA@mail.gmail.com>
On Monday, September 26, 2011 06:41:04 am Christian Couder
wrote:
> On Sun, Sep 25, 2011 at 10:43 PM, Martin Fick
<mfick@codeaurora.org> wrote:
> > A coworker of mine pointed out to me that a simple
> >
> > git checkout
> >
> > can also take rather long periods of time > 3 mins when
> > run on a repo with ~100K refs.
>
> Are all these refs packed?
I think so, is there a way to find out for sure?
-Martin
^ 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