On 18 Jan 2014, at 19:22, Pete Wyckoff p...@padd.com wrote:
dam...@iwi.me wrote on Thu, 16 Jan 2014 17:02 +0100:
On 16 Jan 2014, at 15:45, Pete Wyckoff p...@padd.com 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
On 18 Jan 2014, at 19:22, Pete Wyckoff p...@padd.com wrote:
dam...@iwi.me wrote on Thu, 16 Jan 2014 17:02 +0100:
On 16 Jan 2014, at 15:45, Pete Wyckoff p...@padd.com 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
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
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
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 k...@mns.spb.ru
---
t/t4056-diff-order.sh | 21 +
1 file changed, 21
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
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
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
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
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
(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 for
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 the
Hi,
On Mon, Jan 20, 2014 at 5:11 PM, Abhishek Patil abhis...@thezeroth.net 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
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
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 abhis...@thezeroth.net
wrote:
Hey Guys,
I am Abhishek, I am new here.
For now I just have one question is there any centralize DB
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 \
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
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
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,
Duy Nguyen pclo...@gmail.com 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.random`). Then it
sends wait path. The watcher MUST
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 someone can
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
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
Jeff King p...@peff.net 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
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 fails.
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
On Tue, Jan 21, 2014 at 12:25 AM, Johannes Schindelin
johannes.schinde...@gmx.de 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
On Tue, Jan 21, 2014 at 4:32 AM, Jeff King p...@peff.net 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:
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) {
+ for
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
a
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
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,
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 gits...@pobox.com 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
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 reachable
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_UNDERSTANDS_R
+if
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))
Let me repeat
On Fri, Jan 17, 2014 at 03:42:32PM -0800, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com 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
37 matches
Mail list logo
