Document SubmittingPatches: inconsistency regarding to: and cc: for approved patches

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

[PATCH] docs: add filter-branch note about The BFG

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

Re: I have end-of-lifed cvsps

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

Re: I have end-of-lifed cvsps

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 >> >>

git fetch doesn't ignore funny refs

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

[PATCH 1/3] prune-packed: fix a possible buffer overflow

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

[PATCH 3/3] cmd_repack(): remove redundant local variable "nr_packs"

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

[PATCH 2/3] prune_object_dir(): verify that path fits in the temporary buffer

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

Re: [PATCH 3/3] cmd_repack(): remove redundant local variable "nr_packs"

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. > >

[PATCH 0/3] Fix two buffer overflows and remove a redundant var

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

Re: [PATCH 1/3] prune-packed: fix a possible buffer overflow

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 >

Re: I have end-of-lifed cvsps

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

Re: I have end-of-lifed cvsps

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

Fwd: [Git] instaweb fails with mongoose

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

[no subject]

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

Re: I have end-of-lifed cvsps

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

Re: [PATCH v4 2/3] diff: Let "git diff -O" read orderfile from any file, fail properly

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

Re: Document SubmittingPatches: inconsistency regarding to: and cc: for approved patches

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

Re: [PATCH] docs: add filter-branch note about The BFG

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

Re: [PATCH 1/3] prune-packed: fix a possible buffer overflow

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

Re: [PATCH 2/3] prune_object_dir(): verify that path fits in the temporary buffer

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

Re: I have end-of-lifed cvsps

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

Re: [PATCH] docs: add filter-branch note about The BFG

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 >

Re: [PATCH 2/3] prune_object_dir(): verify that path fits in the temporary buffer

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

Re: I have end-of-lifed cvsps

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

Re: [PATCH v4 2/3] diff: Let "git diff -O" read orderfile from any file, fail properly

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_

Setup Git Server Over HTTP: fatal info/refs

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

Re: I have end-of-lifed cvsps

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.

Re: I have end-of-lifed cvsps

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

Re: [PATCH v4 2/3] diff: Let "git diff -O" read orderfile from any file, fail properly

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 -

Re: [PATCH 3/4] remote-hg: fix 'shared path' path

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

Re: I have end-of-lifed cvsps

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

Re: [PATCH v4 2/3] diff: Let "git diff -O" read orderfile from any file, fail properly

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 &

Re: [PATCH 2/3] prune_object_dir(): verify that path fits in the temporary buffer

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

Re: [PATCH] test the commit.gpgsign config option

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

[ANNOUNCE] Git v1.8.5.2

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

What's cooking in git.git (Dec 2013, #04; Tue, 17)

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

Re: I have end-of-lifed cvsps

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

Re: I have end-of-lifed cvsps

"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

Re: I have end-of-lifed cvsps

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

Re: I have end-of-lifed cvsps

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.

Re: [PATCH] log: properly handle decorations with chained tags

"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

Re: [PATCH] docs: add filter-branch note about The BFG

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

Re: "git fsck" fails on malloc of 80 G

> 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

Re: [PATCH v4 2/3] diff: Let "git diff -O" read orderfile from any file, fail properly

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

Re: [PATCH v3] difftool: Change prompt to display the number of files in the diff queue

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

Re: [PATCH v4 2/3] diff: Let "git diff -O" read orderfile from any file, fail properly

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

Re: [PATCH] docs: add filter-branch note about The BFG

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

Re: [PATCH v3] difftool: Change prompt to display the number of files in the diff queue

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,