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 requir
On Sun, Aug 12, 2012 at 11:33 AM, Junio C Hamano 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 (either make it
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 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
> >> independe
From: Vitaly _Vi Shukela
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
---
git-gui/git-gui.sh |4
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
>
Nguyễn Thái Ngọc Duy 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 the end of t
Pete Wyckoff 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 know wha
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
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
Junio C Hamano writes:
> Nguyễn Thái Ngọc Duy 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
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, an
On Mon, Aug 13, 2012 at 2:49 AM, Junio C Hamano 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 stores N obj
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 t
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 overw
From: Martin von Zweigbergk
When 'git log' is passed the --no-walk option, no revision walk takes
place, naturally. Perhaps somewhat surprisingly, however, the provided
revisions still get sorted by commit date. So e.g 'git log --no-walk
HEAD HEAD~1' and 'git log --no-walk HEAD~1 HEAD' give the s
From: Martin von Zweigbergk
'git cherry-pick' internally sets the --reverse option while walking
revisions, so that 'git cherry-pick branch@{u}..branch' will apply the
revisions starting at the oldest one. If no uninteresing revisions are
given, --no-walk is implied. Still, the documentation for
From: Martin von Zweigbergk
'git cherry-pick A B' implicitly sends --no-walk=sorted to the
revision walker, which means that the older of A and B will be applied
first, which is most likely surprising to most. Fix this by instead
sending --no-walk=unsorted to the revision walker.
Signed-off-by:
From: Martin von Zweigbergk
When 'git cherry-pick' and 'git revert' are used with ranges such as
'git cherry-pick A..B', the order of the commits to pick are
determined by the default date-based sorting. If a commit has a commit
date before the commit date of its parent, it will therfore be appli
From: Martin von Zweigbergk
This series adds supports for 'git log --no-walk=unsorted', which
should be useful for the re-roll of my mz/rebase-range series. It also
addresses the bug in cherry-pick/revert, which makes it sort revisions
by date.
On Fri, Aug 10, 2012 at 11:28 PM, Junio C Hamano w
On Sun, Aug 12, 2012 at 11:23:16PM -0400, Christopher Marshall wrote:
> 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 di
21 matches
Mail list logo
