Hi,
back to the pipe-topic.
On Wednesday 01 August 2012 12:42:48 Jonathan Nieder wrote:
Hi again,
Florian Achleitner wrote:
When the first line arrives at the remote-helper, it starts importing one
line at a time, leaving the remaining lines in the pipe.
For importing it requires the
On Sun, Aug 12, 2012 at 11:33 AM, Junio C Hamano gits...@pobox.com wrote:
I personally do not think this makes much sense, as half the
progress message you see comes from the other end of the connection,
which does not know nor care what language you speak.
That's something we should fix too
The sha-1-offset table in v3 is sorted by object type first, then
sha-1 (as opposed to sorted by sha-1 only in v2). There are four
fan-out tables, one for each object type. So to look for the offset of
an object, we first locate the fan-out table based on object type,
then do binary search in that
gits...@pobox.com wrote on Sat, 11 Aug 2012 21:41 -0700:
Pete Wyckoff p...@padd.com writes:
matt...@korich.net wrote on Fri, 10 Aug 2012 12:14 -0700:
Using git p4 on git version 1.7.12.rc2 has path issues. Standard
clone/sync ops apparently place detected master and branches on
From: Vitaly _Vi Shukela vi0...@gmail.com
Make Ctrl+U for unstaging and Ctrl+J for reverting selection behave
more like Ctrl+T for adding.
They were working only when one area was focused (diff or commit message),
now they should work everywhere.
Signed-off-by: Vitaly _Vi Shukela
Hi again,
Florian Achleitner wrote:
back to the pipe-topic.
Ok, thanks.
[...]
The way it's supposed to work is that in a bidi-import, the remote
helper reads in the entire list of refs to be imported and only once
the newline indicating that that list is over arrives starts writing
its
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
The main reason to group objects by type is to make it possible to
create another sha1-something mapping for a particular object type,
without wasting space for storing sha-1 keys again. For example, we
can store commit caches, tree caches... at
Pete Wyckoff p...@padd.com writes:
The description for [PATCH 5/5] blames v1.7.9-rc0~4^2~1, which tells
me it is the latter. And if that were the case, and if this were in
the area of the system I oversee, I wouldn't push it to the upcoming
release at this late in the cycle, when I do not
Hi again,
Florian Achleitner wrote:
Another alternative would be to use the existing --cat-pipe-fd argument. But
that requires to open the fifo before execing fast-import and makes us
dependent on the posix model of forking and inheriting file descriptors
Let me elaborate on this, which I
On Sunday 12 August 2012 09:12:58 Jonathan Nieder wrote:
Hi again,
Florian Achleitner wrote:
back to the pipe-topic.
Ok, thanks.
[...]
The way it's supposed to work is that in a bidi-import, the remote
helper reads in the entire list of refs to be imported and only once
the
Florian Achleitner wrote:
This is how I see it, probably it's all wrong:
I thought the main problem is, that we don't want processes to have *more than
three pipes attached*, i.e. stdout, stdin, stderr, because existing APIs don't
allow it.
Oh, that makes sense. Thanks for explaining, and
On Mon, Aug 13, 2012 at 2:49 AM, Junio C Hamano gits...@pobox.com wrote:
For example, the reachability bitmap would want to say something
like Traversing from commit A, these objects in this pack are
reachable. The bitmap for one commit A would logically consist of
N bits for a packfile that
I would like to use git svn to clone an svn repo with a non-standard
branches layout roughly like this:
trunk/
tags/
branches/
b1
b2
...
bdir/
b3
b4
...
That is, every directory under branches is a branch except bdir, and
every directory under bdir is a branch.
One
Using git version 1.7.12.rc2.18.g61b472e
(1.7.9 has the same problem)
If I run (directly in the bare repository)
git filter-branch -d ../localrewrite --parent-filter cat
I get this error message on the last line, nothing unusual before:
error: Untracked working tree file 'AUTHORS' would be
14 matches
Mail list logo
