Re: git-p4: exception when cloning a perforce repository

2014-01-20 Thread Damien Gérard
On 18 Jan 2014, at 19:22, Pete Wyckoff wrote: > dam...@iwi.me wrote on Thu, 16 Jan 2014 17:02 +0100: >> >> On 16 Jan 2014, at 15:45, Pete Wyckoff wrote: >> >>> Oh cool, that helps a lot. P4 is just broken here, so we can get >>> away with being a bit sloppy in git. I'll try just pretending

Re: git-p4: exception when cloning a perforce repository

2014-01-20 Thread Damien Gérard
On 18 Jan 2014, at 19:22, Pete Wyckoff wrote: > dam...@iwi.me wrote on Thu, 16 Jan 2014 17:02 +0100: >> >> On 16 Jan 2014, at 15:45, Pete Wyckoff wrote: >> >>> Oh cool, that helps a lot. P4 is just broken here, so we can get >>> away with being a bit sloppy in git. I'll try just pretending

GIT_WORK_TREE and GIT_DIR with git clone

2014-01-20 Thread Cosmin Apreutesei
Hi, I would like to have git clone respect GIT_DIR (and --git-dir) so I can clone multiple repos into the same working directory (I know there was another request for this[1]). The pattern here is big projects that are modularized into multiple git repositories, but supposed to be overlaid over a

Bug archive

2014-01-20 Thread Abhishek Patil
Hey Guys, I am Abhishek, I am new here. For now I just have one question is there any centralize DB place where I can see Bugs reported on / about Git ? something like bugzilla of trac for Git-Scm ? -- Thanks Abhishek http://thezeroth.net -- To unsubscribe from this list: send the line "unsub

[PATCH 2/4] diff test: Add tests for combine-diff with orderfile

2014-01-20 Thread Kirill Smelkov
In the next patch combine-diff will have special code-path for taking orderfile into account. Prepare for making changes by introducing coverage tests for that case. Signed-off-by: Kirill Smelkov --- t/t4056-diff-order.sh | 21 + 1 file changed, 21 insertions(+) diff --git a

[PATCH 3/4] combine-diff: Optimize combine_diff_path sets intersection

2014-01-20 Thread Kirill Smelkov
Currently, when generating combined diff, for a commit, we intersect diff paths from diff(parent_0,commit) to diff(parent_i,commit) comparing all paths pairs, i.e. doing it the quadratic way. That is correct, but could be optimized: Paths come from trees in sorted (= tree) order, and so does diff_

[PATCH 1/4] diffcore-order: Export generic ordering interface

2014-01-20 Thread Kirill Smelkov
At present, diffcore_order() interface is to accept only queue of `struct diff_filepair`. In the next patches, we'll need to order `struct combine_diff_path` by path, so let's first rework diffcore-order to also provide generic low-level interface for ordering arbitrary objects, provided they have

[PATCH 0/4] `log -c` speedup

2014-01-20 Thread Kirill Smelkov
Hello up there, I'm using `git log --raw` to reconstruct file dates (readonly filesystem for git archives) and, as it turned out, for --raw to emit diffs for merges we need to explicitly activate combine-diff via -c. The combined-diff turned out to be slow, I'm trying to optimize it. Please appl

[PATCH 4/4] combine-diff: combine_diff_path.len is not needed anymore

2014-01-20 Thread Kirill Smelkov
Brefore previous patch, ->len was used to speedup name compares and also to mark removed paths via len=0. Now we do significantly less strcmp and also just remove paths from list and free right after we know a path will not be needed, so ->len is not needed anymore. Signed-off-by: Kirill Smelkov

No local cloning for insteadOf URLs

2014-01-20 Thread Hannes Mezger
Hi there, on Linux I'm using the config option url.[].insteadOf feature to clone certain (very big) submodules from a local mirror instead of from remote. The configuration is something like [url "/home/sampleuser/mirrors/bigrepo.git"] insteadOf = git@remotehost:bigrepo.git Cloning this repo

Re: [msysGit] Consecutive git gc fails on Windows network share

2014-01-20 Thread Torsten Bögershausen
(No top-posting, please see my comments below) On 2014-01-20 15.02, Jochen wrote: >On 01/16/2014 10:55 AM, Jochen Haag wrote: > Hello, > > we want to report the following issue, because it seems to be not an > intended behaviour. Maybe someone can have a look at it at some point. > It is not urgent

git-remote-hg

2014-01-20 Thread Christophe
Hi, I am using git-remote-hg to access to projects on bitbucket. I can clone the master branch fine and push to it. I also see hg branches as remotes/origin/branches/«branch». However, if I create a local branch "branches/x" and want to push it to remotes/origin/branches/x, it gets pushed to th

Re: Bug archive

2014-01-20 Thread Christian Couder
Hi, On Mon, Jan 20, 2014 at 5:11 PM, Abhishek Patil wrote: > Hey Guys, > I am Abhishek, I am new here. > For now I just have one question is there any centralize DB place where > I can see Bugs reported on / about Git ? something like bugzilla of trac for > Git-Scm ? Please have a look at this

problematic git log submodule-dir/

2014-01-20 Thread Paweł Sikora
Hi all. i've noticed that 'git log submodule-dir' and 'git log submodule-dir/' return different results (module's head changes vs. nothing). is it a bug? looks like a trailing slash is a problem for git-log. tested on git-1.8.5.3-2.fc20.x86_64. BR, Paweł. -- gpg key fingerprint = 60B4 9886 AD5

Re: Bug archive

2014-01-20 Thread Abhishek Patil
Thanks Christian, Best, Abhishek On Mon, Jan 20, 2014 at 06:35:43PM +0100, Christian Couder wrote: > Hi, > > On Mon, Jan 20, 2014 at 5:11 PM, Abhishek Patil > wrote: > > Hey Guys, > > I am Abhishek, I am new here. > > For now I just have one question is there any centralize DB place where > > I

[PATCH/RFC] Makefile: Fix compilation of windows resource file

2014-01-20 Thread Ramsay Jones
If the git version number consists of less than three period separated numbers, then the windows resource file compilation issues a syntax error: $ touch git.rc $ make V=1 git.res GIT_VERSION = 1.9.rc0 windres -O coff \ -DMAJOR=1 -DMINOR=9 -DPATCH=rc0 \ -DGIT_VERSI

[PATCH 0/2] performance regression in mark_edges_uninteresting

2014-01-20 Thread Jeff King
This series fixes a rev-list performance regression in fbd4a70 (list-objects: mark more commits as edges in mark_edges_uninteresting, 2013-08-16). That commit is a little tricky because it actually _knows_ it's trading off CPU for a better packfile, but I think we're performing the tradeoff in too

[PATCH 1/2] t/perf: time rev-list with UNINTERESTING commits

2014-01-20 Thread Jeff King
We time a straight "rev-list --all" and its "--object" counterpart, both going all the way to the root. However, we do not time a partial history walk. This patch adds an extreme case: a walk over a very small slice of history, but with a very large set of UNINTERESTING tips. This is similar to the

[PATCH 2/2] list-objects: only look at cmdline trees with edge_hint

2014-01-20 Thread Jeff King
When rev-list is given a command-line like: git rev-list --objects $commit --not --all the most accurate answer is the difference between the set of objects reachable from $commit and the set reachable from all of the existing refs. However, we have not historically provided that answer, becaus

Re: [PATCH/WIP v2 00/14] inotify support

2014-01-20 Thread Thomas Rast
Duy Nguyen writes: >> I think a clever way to handle this would be to add a new command: >> >> Wait:: >> This command serves synchronization. Git creates a file of its >> choice in $GIT_DIR/watch (say, `.git/watch/wait.`). Then it >> sends "wait ". The watcher MUST block until it

Re: [msysGit] Consecutive git gc fails on Windows network share

2014-01-20 Thread Stefan Beller
On 20.01.2014 18:16, Torsten Bögershausen wrote: > (No top-posting, please see my comments below) > On 2014-01-20 15.02, Jochen wrote: >> On 01/16/2014 10:55 AM, Jochen Haag wrote: >> Hello, >> >> we want to report the following issue, because it seems to be not an >> intended behaviour. Maybe some

Re: [PATCH 1/2] t/perf: time rev-list with UNINTERESTING commits

2014-01-20 Thread Jeff King
On Mon, Jan 20, 2014 at 04:31:01PM -0500, Jeff King wrote: > diff --git a/t/perf/p0001-rev-list.sh b/t/perf/p0001-rev-list.sh > index 4f71a63..b7258a7 100755 > --- a/t/perf/p0001-rev-list.sh > +++ b/t/perf/p0001-rev-list.sh > @@ -14,4 +14,21 @@ test_perf 'rev-list --all --objects' ' > git re

Re: [PATCH 0/2] performance regression in mark_edges_uninteresting

2014-01-20 Thread Jeff King
On Mon, Jan 20, 2014 at 04:28:45PM -0500, Jeff King wrote: > [1/2]: t/perf: time rev-list with UNINTERESTING commits > [2/2]: list-objects: only look at cmdline trees with edge_hint > > Here's t/perf/p0001 output that shows the problem: > > 0001.5: rev-list --objects $commit --not --all >

Re: [PATCH 1/2] t/perf: time rev-list with UNINTERESTING commits

2014-01-20 Thread Thomas Rast
Jeff King writes: > On Mon, Jan 20, 2014 at 04:31:01PM -0500, Jeff King wrote: > >> diff --git a/t/perf/p0001-rev-list.sh b/t/perf/p0001-rev-list.sh >> index 4f71a63..b7258a7 100755 >> --- a/t/perf/p0001-rev-list.sh >> +++ b/t/perf/p0001-rev-list.sh >> @@ -14,4 +14,21 @@ test_perf 'rev-list --all

Re: [PATCH 1/2] t/perf: time rev-list with UNINTERESTING commits

2014-01-20 Thread Jeff King
On Mon, Jan 20, 2014 at 11:32:12PM +0100, Thomas Rast wrote: > > This is bad to be touching the repo and assuming it is non-bare. For > > some reason I assumed that the perf suite made a copy of the repo, but > > it doesn't. If you point to a bare repo via GIT_PERF_REPO, this part of > > the test

Re: [msysGit] Consecutive git gc fails on Windows network share

2014-01-20 Thread Johannes Schindelin
Hi Torsten, On Mon, 20 Jan 2014, Torsten Bögershausen wrote: > (No top-posting, please see my comments below) already very good! For extra brownie points, just edit the quoted part to reflect the abridged version needed to understand the context. > On 2014-01-20 15.02, Jochen wrote: > >On 01/16

Re: [msysGit] Consecutive git gc fails on Windows network share

2014-01-20 Thread Erik Faye-Lund
On Tue, Jan 21, 2014 at 12:25 AM, Johannes Schindelin wrote: > > On Mon, 20 Jan 2014, Torsten Bögershausen wrote: > >> b) add "+++" at the places where you added the stat() and chmod(), >> c) and to send the question "is this a good implementation ?" to upstream >> git. >> >> I think your impleme

Re: [PATCH 2/2] list-objects: only look at cmdline trees with edge_hint

2014-01-20 Thread Duy Nguyen
On Tue, Jan 21, 2014 at 4:32 AM, Jeff King wrote: > This patch therefore ties the extra tree examination to the > revs->edge_hint flag; it is the presence of that flag that > makes the tradeoff worthwhile. > > Here is output from the p0001-rev-list showing the > improvement in performance: > > Tes

Re: [PATCH 2/2] list-objects: only look at cmdline trees with edge_hint

2014-01-20 Thread Jeff King
On Tue, Jan 21, 2014 at 06:57:08AM +0700, Duy Nguyen wrote: > You must have so much fun (or headache, depending on your view) with > the variety of repos on github :) It's fun on days like these when the solution is fairly straightforward. :) > > + if (revs->edge_hint) { > > +

[PATCH v2 0/2] performance regression in mark_edges_uninteresting

2014-01-20 Thread Jeff King
On Mon, Jan 20, 2014 at 04:28:45PM -0500, Jeff King wrote: > This series fixes a rev-list performance regression in fbd4a70 (list-objects: > mark more commits as edges in mark_edges_uninteresting, 2013-08-16). That > commit is a little tricky because it actually _knows_ it's trading off CPU for >

[PATCH v2 1/2] t/perf: time rev-list with UNINTERESTING commits

2014-01-20 Thread Jeff King
We time a straight "rev-list --all" and its "--object" counterpart, both going all the way to the root. However, we do not time a partial history walk. This patch adds an extreme case: a walk over a very small slice of history, but with a very large set of UNINTERESTING tips. This is similar to the

[PATCH v2 2/2] list-objects: only look at cmdline trees with edge_hint

2014-01-20 Thread Jeff King
When rev-list is given a command-line like: git rev-list --objects $commit --not --all the most accurate answer is the difference between the set of objects reachable from $commit and the set reachable from all of the existing refs. However, we have not historically provided that answer, becaus

Re: Diagnosing stray/stale .keep files -- explore what is in a pack?

2014-01-20 Thread Jeff King
On Wed, Jan 15, 2014 at 06:50:33PM -0500, Martin Langhoff wrote: > On Wed, Jan 15, 2014 at 12:49 PM, Junio C Hamano wrote: > > As long as we can reliably determine that it is safe to do so > > without risking races, automatically cleaning .lock files is a good > > thing to do. > > If the .lock f

Re: [PATCH v2 0/2] Propagating flags carefully from the command line

2014-01-20 Thread Jeff King
On Wed, Jan 15, 2014 at 03:59:42PM -0800, Junio C Hamano wrote: > So this is my second try. The second one now gets rid of the call > to mark_blob_uninteresting() as Peff suggested, because the first > patch makes the function very well aware that it only should mark > the objects that are reacha

Re: [PATCH 2/3] setup_pager: set MORE=R

2014-01-20 Thread Jeff King
On Thu, Jan 16, 2014 at 11:26:50PM -0800, Kyle J. McKay wrote: > >--- a/pager.c > >+++ b/pager.c > >@@ -87,6 +87,10 @@ void setup_pager(void) > > argv_array_push(&env, "LESS=FRSX"); > > if (!getenv("LV")) > > argv_array_push(&env, "LV=-c"); > >+#ifdef PAGER_MORE_UNDERST

Re: [PATCH 2/3] setup_pager: set MORE=R

2014-01-20 Thread Jeff King
On Fri, Jan 17, 2014 at 11:17:01AM -0800, Junio C Hamano wrote: > > +#ifdef PAGER_MORE_UNDERSTANDS_R > > + if (!getenv("MORE")) > > + argv_array_push(&env, "MORE=R"); > > +#endif > > pager_process.env = argv_array_detach(&env, NULL); > > > > if (start_command(&pager_process))

Re: [PATCH 2/3] setup_pager: set MORE=R

2014-01-20 Thread Jeff King
On Fri, Jan 17, 2014 at 03:42:32PM -0800, Junio C Hamano wrote: > Junio C Hamano writes: > > > Perhaps we can start it like this. Then pager.c can iterate over > > the PAGER_ENV string, parse out LESS=, LV=, etc., and do its thing. > > > > We would also need to muck with git-sh-setup.sh but tha