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
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))
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
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
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
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
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
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
>
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) {
> > +
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
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
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
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
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
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
>
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
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
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
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
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
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
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
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
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
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
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
(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
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
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
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
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
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
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_
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
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
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
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
37 matches
Mail list logo
