A disclaimer:: I could have mucked with anything, I will not place the blame on git as if I had strictly adhered to the tutorial instructions. Anything I did was through the UI, there was no mucking with files. Thanks in advance and good luck: I have one repos located on /var/git/scraper.git, it houses a small-inhouse project which I'm trying to use to sell git with. Unfortunately, I've had a very difficult time doing everything with git. Namely, pulling and pushing. It appears as if I git-clone th...

A few linux kernel source and git questions: What's the best procedure to handle a tree-wide source tranformation? For instance: git branch foo2bar egrep -r -w --include=*.[ch] -l "foo" * | \ xargs perl -pi -e 's/\bfoo\b/bar/msg' git commit -a -m "use bar not foo" Is there a way to separate the resultant single patch into multiple patches by subdirectory? Perhaps some git-rev-parse option? git-format-patch -p --stat -o outputdir Is there a way to automatically include the appro...

Nor would it likely survive a git bisect, but it's a start. My goal is to eventually commit by maintainer. Thanks, Joe -

hi guys, earlier today i imported one of my larger trees (~70k files) into git and was quite disappointed by the performance. i made some tests on latest master branch (1.5.3.rc4.29.g74276) and it seems like git hits a wall somewhere above ~50k files. i'm seeing 'commit' timings of 30s and up as well as 'status' timings in the 10s ballpark. here's a test-case (should be safe to copy/paste on linux, bash): # # first create a tree of roughly 100k files # mkdir bummer cd bummer for (...

Good catch. Definitely not acceptable performance. We seem to spend a lot of our time in memcpy: samples % image name app name symbol name 200527 25.4551 libc-2.6.so libc-2.6.so _wordcopy_bwd_aligned 104505 13.2660 libc-2.6.so libc-2.6.so _wordcopy_fwd_aligned 99185 12.5907 libz.so.1.2.3 libz.so.1.2.3 (no symbols) 83452 10.5935 libc-2.5.so libc-2.5.s...

Ouch. It's the diffing between HEAD and the index, and it's all from "add_index_entry()", which sorts the index array using an insertion sort. So when the index array gets large, that sort spends all its time in huge memmove() calls. The silly thing, of course, is that we don't even "need" to do that: both the index and the trees are really sorted already, so we could just interleave them. But since we read them separately, the thing just sucks. We've fixed other similar cases of this ...

I hopefully have some time this evening to look into this, if not earlier. -

On Thu, 09 Aug 2007 13:42:50 -0700 Junio, This makes things _much_ better, however the final commit in the test script still shows a lot of user time: ## time git init real 0m0.005s user 0m0.001s sys 0m0.004s ## time git add . real 0m3.501s user 0m1.268s sys 0m2.159s ## time git commit -q -m 'buurrrrn' -a real 0m2.299s user 0m1.065s sys 0m1.317s ## time git status real 0m1.107s user 0m0.548s sys 0m0.557s ## time git status real ...

The path seems to be: cmd_read_tree -> unpack_trees -> unpack_trees_rec -> [ recursive .. unpack_trees_rec ] -> oneway_merge -> keep_entry -> add_index_entry() and here again we end up having the same insertion sort issue. Linus -

Yeah, that's probably the right thing to do; I wrote it with the idea that we'd be doing many-parent merges with it, but merge-recursive turned out to be a better idea, so I designed it to be comprehensible for a complicated case we never actually do. -Daniel *This .sig left intentionally blank* -

Ugh. I had some time, so I tried to find out *why* that thing is so slow. The fact is, "git read-tree -m HEAD" should be really really fast, because it should never actually insert multiple entries into the same index entry: it should just _replace_ the entry. But why is it slow? It doesn't actually replace the entry with "add_cache_entry()" at all. What it does is to *remove* the entry entirely at unpack-trees.c, line 154, unpack_trees_rec(), which does a "remove_cache_entry_at(...

Well, the patch you sent out was not only hacky, it was kind of pointless. Without the "-m" handling, it means that most users of git-read-tree won't ever see the improvement. The merge with the old index is absolutely critical for things like switching branches, for example. And I think you probably screwed up performance with your change to git-commit to simply not use it, because now the resulting index will be totally stale, and while the *commit* may be fast as a result, the subseque...

Just in case anybody is wondering, this also passed all the existing tests. Maybe it is going in the right direction of slowly moving away from unpack_trees() where we can. I dunno. I also do not know if it "fixes" the performance issue on that testcase. -

One thing to keep in mind is that in your earlier test of "git write-tree" (or "git commit") followed by "git add a/file" followed by "git write-tree" is extremely fast because the last operation optimizes otherwise O(n) behaviour of write-tree Right now we do not cull the subdirectory that we _know_ are unchanged in "git diff-index --cached" using cache-tree, but diffing the index against the tree could be instantaneous. -

Actually the test case is wrong, it should end in: git-rebase b # while being on `master' branch git-svn dcommit # this works as expected Thanks to siprbaum for spotting this on IRC. Sorry for the noise. -- Benoit Sigoure aka Tsuna EPITA Research and Development Laboratory

Email::Valid does respect this considering such a mailbox specification invalid. b06c6bc831cbb9e9eb82fd3ffd5a2b674cd940d0 addressed the issue, but only if Email::Valid is available. Signed-off-by: Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de> --- git-send-email.perl | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/git-send-email.perl b/git-send-email.perl index 39e433b..a02ab96 100755 --- a/git-send-email.perl +++ b/git-send-email.perl @@ -408,8 +408,...

If called with one argument, check also for no_trivial_merge_strategies whether all the merge can already be reached by HEAD. Otherwise git-merge creates an unnecessary commit, e.g.: $ (git init && touch foo && git add foo && git commit -m foo) >/dev/null $ git merge -s ours master Merge made by ours. $ git log --pretty=oneline d941346f022b7cb70c51d8122de4ae82657ae943 Merge branch 'master' 68a1d32229917d5d1f4c8f64096d1abde84e9f6b foo $ Signed-off-by: Gerrit P...

Maybe it was the "I'm using a custom merge strategy that might refuse the merge, but fast-forwards don't even invoke my merge strategy" request? -Peff -

Yes. Neither is [[:space:]]. The above actually is pretty much equivalent to $(RM) "$series+" sed "/^$p/s/\$/ #$x/" "$series" >"$series+" $(MV) "$series+" "$series" Which is probably not what was intended (the whole [[:space:]] construct is irrelevant). More likely it was intended to do something like $(RM) "$series+" sed "/^$p[ ]/s/\$/ #$x/" "$series" >"$series+" $(MV) "$series+" "$series" or if $p can contain slashes but not commata, ...

There shouldn't be multiline options passed to this function, so it Heh, as you may have noticed, I'm no shell programmer :-) Thanks for Yeah. That one made itself clear. The sed -i needs to go too, as Thomas observed. The regexp itself also needs cleansing. Lots of work to do... Eric -

You're definitely right. I've been asked to change this a couple of times and keep forgetting. Thanks for the reminder. Eric -

Hi, What is supposed to be the usage() of git-fetch-branch ? git-filter-branch itself says: git-filter-branch [-d TEMPDIR] [FILTERS] DESTBRANCH [REV-RANGE] while the documentation doesn't explicitely talk about DESTBRANCH, expect in the form of an hypothetical /newbranch/, that you obviously don't give to the command line. And whereas git-filter-branch itself says there is such an argument, it actually doesn't take it, and doesn't seem to be hardwired to create a new branch instead of overw...

In the description in the manpage: Lets you rewrite git revision history by creating a new branch from your current branch, applying custom filters on each revision. (...) The command takes the new branch name as a mandatory argument and the filters as optional arguments And in example: Now, you will get the rewritten history saved in the branch newbranch (your current branch is left untouched). That would need the commit id for the original commit being treated at the ...

To have, for example, a branch tracking an upstream (svn or whatever) repository and have a branch based on it, only differing in the fact that some directories get removed. To be more specific, I'm tracking webkit's svn repository, and want to have a branch which would be a base for making source tarballs for debian, excluding a lot of cruft (such as LayoutTests which are *huge*, or the website that also lives in the same svn trunk). As files are added frequently in these directories, rebase o...

Does 'git gui' work for you in msysgit? I get Invalid command name "git-version" while executing "git-version >= 1.5.3" (in namespace eval "::blame" script line 36) [...] with msysgit (v1.5.3-rc2-690-g8ca1f6a). Steffen -