David Aguilar writes:
> Thanks for the patch, and sorry for the late response.
> I have just a couple of notes below...
>
> On Fri, Dec 06, 2013 at 10:38:46AM +1100, Zoltan Klinger wrote:
>> diff --git a/diff.c b/diff.c
>> index e34bf97..a7d5a47 100644
>> --- a/diff.c
>> +++ b/diff.c
>> @@ -2899,
Roberto Tyley writes:
> * The BFG takes advantage of multi-core machines, cleaning commit
> file-trees in parallel, which git-filter-branch currently does not do.
> * Any particular version of a file is cleaned exactly _once_. The BFG,
> unlike git-filter-branch, does not give you the opportunity
Samuel Bronson writes:
> On Tue, Dec 17, 2013 at 5:09 PM, Junio C Hamano wrote:
>> My point was that I did not see much value in reading the orderfile
>> data from anything but a file. At that point, you are not testing
>> the "diff -O" orderfile option, but if strbuf_readline() reads from
>> a
Thanks for the patch, and sorry for the late response.
I have just a couple of notes below...
On Fri, Dec 06, 2013 at 10:38:46AM +1100, Zoltan Klinger wrote:
> diff --git a/diff.c b/diff.c
> index e34bf97..a7d5a47 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -2899,11 +2899,16 @@ static void run_exter
On Tue, Dec 17, 2013 at 5:09 PM, Junio C Hamano wrote:
> My point was that I did not see much value in reading the orderfile
> data from anything but a file. At that point, you are not testing
> the "diff -O" orderfile option, but if strbuf_readline() reads from
> a non-regular file.
Oh, good po
> From: Jeff King
>
> On Mon, Dec 16, 2013 at 11:05:32AM -0500, Dale R. Worley wrote:
>
> > # git fsck
> > Checking object directories: 100% (256/256), done.
> > fatal: Out of memory, malloc failed (tried to allocate 80530636801 bytes)
> > #
>
> Can you give you give us a backtrace from the die
On 17 December 2013 18:13, Junio C Hamano wrote:
>
> Having said that, "You may want to use ..." without giving the
> reason why we recommend the other tool leaves the reader wondering
> what the pros and cons are, and why git-filter-branch exists if BFG
> is the first thing its document recommend
"brian m. carlson" writes:
> refname = prettify_refname(refname);
> add_name_decoration(type, refname, obj);
> while (obj->type == OBJ_TAG) {
> - obj = ((struct tag *)obj)->tagged;
> - if (!obj)
> - break;
> + struc
Andreas Schwab :
> "Eric S. Raymond" writes:
>
> > All versions of CVS have generated commitids since 2004.
>
> Though older versions are still in use, eg. sourceware.org still does
> not generate commitids.
That is awful. Alas, there is not much anyone can do about stupidity
that determined.
Jakub Narębski :
> > No, cvs-fast-export does not have --export-marks. It doesn't generate the
> > SHA1s that would require. Even if it did, it's not clear how that would
> > help.
>
> I was thinking about how the following part of git-fast-export
> `--import-marks=`
>
> Any commits that have
"Eric S. Raymond" writes:
> All versions of CVS have generated commitids since 2004.
Though older versions are still in use, eg. sourceware.org still does
not generate commitids.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8
On Tue, Dec 17, 2013 at 10:02 PM, Eric S. Raymond wrote:
> Jakub Narębski :
>>
>> Errr... doesn't cvs-fast-export support --export-marks= to save
>> progress and --import-marks= to continue incremental import?
>
> No, cvs-fast-export does not have --export-marks. It doesn't generate the
> SHA1s th
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
You can find the changes described here in the integration branches
of the repositories listed at
http://git-blame.blogspot.com/p/git-publi
The latest maintenance release Git v1.8.5.2 is now available at
the usual places.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
3a09d6d5d4e31c702f17e664a527b4c2f6e84faf git-1.8.5.2.tar.gz
eaf2e3cfd07c1b88eff688fc3ba79dd4f
Junio C Hamano writes:
> If any of the above fail, the next test will run with an unknown
> random value in commit.gpgsign depending on where the sequence
> failed. Use one test_when_finished with test_unconfig at the very
> beginning, perhaps.
In other words, I'll squash this in.
diff --git a
On Tue, Dec 17, 2013 at 10:51:30AM -0800, Junio C Hamano wrote:
> Michael Haggerty writes:
>
> > Dimension the buffer based on PATH_MAX rather than a magic number, and
> > verify that the path fits in it before continuing.
> >
> > Signed-off-by: Michael Haggerty
> > ---
> >
> > I don't think th
Antoine Pelisse writes:
> I'm not sure about the deadlock though. Both read and write will wait
> for each other to start operating on the fifo.
It is true only if the fifo already exists. That is, if you did
this:
a lot of &&
commands &&
before &&
mkfifo fifo &
Johan Herland :
> > Alan and I are going to take a good hard whack at modifying cvs-fast-export
> > to make this work. Because there really aren't any feasible alternatives.
> > The analysis code in cvsps was never good enough. cvs2git, being written
> > in Python, would hit the core limit faster t
Antoine Pelisse writes:
> On Sat, Dec 7, 2013 at 2:09 PM, Felipe Contreras
> wrote:
>> If the repository is moved, the absolute path of the shared repository
>> would fail.
>>
>> Make sure it's always up-to-date.
>>
>> Reported-by: Michael Davis
>> Signed-off-by: Felipe Contreras
>> ---
>> co
Antoine Pelisse writes:
>> How about not doing a fifo?
>
> That would certainly defeat the purpose of the test, which is to test
> against a fifo :-)
My point was that I did not see much value in reading the orderfile
data from anything but a file. At that point, you are not testing
the "diff -
On Tue, Dec 17, 2013 at 7:47 PM, Eric S. Raymond wrote:
> I'm working with Alan Barret now on trying to convert the NetBSD
> repositories. They break cvs-fast-export through sheer bulk of
> metadata, by running the machine out of core. This is exactly
> the kind of huge case that you're talking a
Jakub Narębski :
> Errr... doesn't cvs-fast-export support --export-marks= to save
> progress and --import-marks= to continue incremental import?
No, cvs-fast-export does not have --export-marks. It doesn't generate the
SHA1s that would require. Even if it did, it's not clear how that would help.
Hi, all,
Thank you for that wonderful document, it worked flawlessly for CentOS 6.4 with
one exception:
> [Tue Dec 17 12:07:42 2013] [error] [client 10.2.32.197] File does not exist:
> /var/www/html/gpu-code.git/info/refs
I did some searching and found this StackOverflow answer:
> fatal: http
On Tue, Dec 17, 2013 at 6:54 PM, Junio C Hamano wrote:
> Samuel Bronson writes:
>
>> On Mon, Dec 16, 2013 at 4:32 PM, Junio C Hamano wrote:
>>> Samuel Bronson writes:
>>>
for i in 1 2
do
test_expect_success "orderfile using option ($i)" '
git diff -Oorder_file_
On Tue, Dec 17, 2013 at 3:07 PM, Eric S. Raymond wrote:
> Jakub Narębski :
>> I wonder if we can add support for incremental import once, for all
>> VCS supporting fast-export, in one place, namely at the remote-helper.
>
> Something in the pipeline - either the helper or the exporter - needs to
Michael Haggerty writes:
> Dimension the buffer based on PATH_MAX rather than a magic number, and
> verify that the path fits in it before continuing.
>
> Signed-off-by: Michael Haggerty
> ---
>
> I don't think that this problem is remotely exploitable, because the
> size of the string doesn't d
Roberto Tyley writes:
> The BFG is a tool specifically designed for the task of removing
> unwanted data from Git repository history - a common use-case for which
> git-filter-branch has been the traditional workhorse.
>
> It's beneficial to let users know that filter-branch has an alternative
>
Johan Herland :
> However, I fear that you underestimate the number of users that want
> to use Git against CVS repos that are orders of magnitude larger (in
> both dimensions: #commits and #files) than your example repo.
You may be right. See below...
I'm working with Alan Barret now on trying t
On Tue, Dec 17, 2013 at 2:43 PM, Michael Haggerty wrote:
> Dimension the buffer based on PATH_MAX rather than a magic number, and
> verify that the path fits in it before continuing.
>
> Signed-off-by: Michael Haggerty
> ---
>
> I don't think that this problem is remotely exploitable, because the
Duy Nguyen writes:
> Why don't we take this opportunity to replace that array with a
> strbuf? The conversion looks simple with this function.
Indeed. Something like this, perhaps?
builtin/prune-packed.c | 38 +-
1 file changed, 21 insertions(+), 17 deletio
Hi,
Roberto Tyley wrote:
> The BFG is a tool specifically designed for the task of removing
> unwanted data from Git repository history - a common use-case for which
> git-filter-branch has been the traditional workhorse.
>
> It's beneficial to let users know that filter-branch has an alternative
Gunnar Strand writes:
> The patch submission document has an inconsistency regarding who should be
> "To" and "Cc" for approved patches:
>
> To maintainer, cc list:
>
> 212 After the list reached a consensus that it is a good idea to apply the
> 213 patch, re-send it with "To:" set to the maintai
Samuel Bronson writes:
> On Mon, Dec 16, 2013 at 4:32 PM, Junio C Hamano wrote:
>> Samuel Bronson writes:
>>
>>> for i in 1 2
>>> do
>>> test_expect_success "orderfile using option ($i)" '
>>> git diff -Oorder_file_$i --name-only HEAD^..HEAD >actual &&
>>> test_cmp expect_$i
On Tue, Dec 17, 2013 at 3:58 PM, Eric S. Raymond wrote:
> Johan Herland :
>> HOWEVER, this only solves the "cheap" half of the problem. The reason
>> people want incremental CVS import, is to avoid having to repeatedly
>> convert the ENTIRE CVS history. This means that the CVS exporter must
>> lea
Do You Need A Loan? Email Us Now At jerrysmit...@rediffmail.com With Amount
Needed As Loan And Phone Number.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Using git 1.8.5 and Mongoose 3.7 (also tried 5.0), I cannot start the
instaweb server.
$ git instaweb --httpd=mongoose
Loading config file /scratch/workspace/git/myproject/.git/gitweb/mongoose.conf
Failed to set option [root]: No such option
Waiting for 'mongoose' to start
Johan Herland :
> HOWEVER, this only solves the "cheap" half of the problem. The reason
> people want incremental CVS import, is to avoid having to repeatedly
> convert the ENTIRE CVS history. This means that the CVS exporter must
> learn to start from a given point in the CVS history (identified b
Jakub Narębski :
> I wonder if we can add support for incremental import once, for all
> VCS supporting fast-export, in one place, namely at the remote-helper.
Something in the pipeline - either the helper or the exporter - needs to
have an equivalent of vc-fast-export's and cvsps's -i option, whi
On Tue, Dec 17, 2013 at 8:43 PM, Michael Haggerty wrote:
> The pathname character array might hold:
>
> strlen(pathname) -- the pathname argument
> '/' -- a slash, if not already present in pathname
> %02x/-- the first two characters of the SHA-1 plus slash
>
These patches fix three things I found when I was puttering around.
The first two patches fix buffer overflows. (They don't seem to be
exploitable.)
The third removes a redundant local variable.
The patches apply to master.
Michael Haggerty (3):
prune-packed: fix a possible buffer overflow
On 17.12.2013 14:43, Michael Haggerty wrote:
> Its value is the same as the number of entries in the "names"
> string_list, so just use "names.nr" in its place.
>
> Signed-off-by: Michael Haggerty
Acked-by: Stefan Beller
> ---
> This is just a trivial simplification. Take it or leave it.
>
>
Dimension the buffer based on PATH_MAX rather than a magic number, and
verify that the path fits in it before continuing.
Signed-off-by: Michael Haggerty
---
I don't think that this problem is remotely exploitable, because the
size of the string doesn't depend on inputs that can be influenced by
The pathname character array might hold:
strlen(pathname) -- the pathname argument
'/' -- a slash, if not already present in pathname
%02x/-- the first two characters of the SHA-1 plus slash
38 characters-- the last 38 characters of the SHA-1
NUL
Its value is the same as the number of entries in the "names"
string_list, so just use "names.nr" in its place.
Signed-off-by: Michael Haggerty
---
This is just a trivial simplification. Take it or leave it.
builtin/repack.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --g
Hello,
I'm trying to maintain a mirror of a repo that is published with gerrit.
The repo contains
a "funny ref" with name 'refs/tags/xyz/...' .
When I clone the repo the ref is correctly ignored:
> git clone --mirror ssh://server:29418/repo
Cloning into bare repository 'repo.git'...
error: * Ig
On Tue, Dec 17, 2013 at 11:57 AM, Jakub Narębski wrote:
> Martin Langhoff wrote:
>
>> On Wed, Dec 11, 2013 at 11:26 PM, Eric S. Raymond wrote:
>>>
>>> You'll have to remind me what you mean by "incremental" here. Possibly
>>> it's something cvs-fast-export could support.
>>
>>
>> User can
>>
>>
Martin Langhoff wrote:
On Wed, Dec 11, 2013 at 11:26 PM, Eric S. Raymond wrote:
You'll have to remind me what you mean by "incremental" here. Possibly
it's something cvs-fast-export could support.
User can
- run a cvs to git import at time T, resulting in repo G
- make commits to cvs re
The BFG is a tool specifically designed for the task of removing
unwanted data from Git repository history - a common use-case for which
git-filter-branch has been the traditional workhorse.
It's beneficial to let users know that filter-branch has an alternative
here:
* speed : The BFG is 10-50x
Hi,
The patch submission document has an inconsistency regarding who should be
"To" and "Cc" for approved patches:
To maintainer, cc list:
212 After the list reached a consensus that it is a good idea to apply the
213 patch, re-send it with "To:" set to the maintainer [*1*] and "cc:" the
214 lis
49 matches
Mail list logo
