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 list [*2*]
On Tue, Dec 17, 2013 at 11:57 AM, Jakub Narębski jna...@gmail.com wrote:
Martin Langhoff wrote:
On Wed, Dec 11, 2013 at 11:26 PM, Eric S. Raymonde...@thyrsus.com wrote:
You'll have to remind me what you mean by incremental here. Possibly
it's something cvs-fast-export could support.
User
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 mhag...@alum.mit.edu
---
This is just a trivial simplification. Take it or leave it.
builtin/repack.c | 6 ++
1 file changed, 2 insertions(+), 4
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 mhag...@alum.mit.edu
---
I don't think that this problem is remotely exploitable, because the
size of the string doesn't depend on inputs that
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 mhag...@alum.mit.edu
Acked-by: Stefan Beller stefanbel...@googlemail.com
---
This is just a trivial
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 Tue, Dec 17, 2013 at 8:43 PM, Michael Haggerty mhag...@alum.mit.edu 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
Johan Herland jo...@herland.net:
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
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
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
On Tue, Dec 17, 2013 at 3:58 PM, Eric S. Raymond e...@thyrsus.com wrote:
Johan Herland jo...@herland.net:
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
Duy Nguyen pclo...@gmail.com 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
On Tue, Dec 17, 2013 at 2:43 PM, Michael Haggerty mhag...@alum.mit.edu 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 mhag...@alum.mit.edu
---
I don't think that this problem is
Johan Herland jo...@herland.net:
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
On Tue, Dec 17, 2013 at 3:07 PM, Eric S. Raymond e...@thyrsus.com wrote:
Jakub Narębski jna...@gmail.com:
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
On Tue, Dec 17, 2013 at 6:54 PM, Junio C Hamano gits...@pobox.com wrote:
Samuel Bronson naes...@gmail.com writes:
On Mon, Dec 16, 2013 at 4:32 PM, Junio C Hamano gits...@pobox.com wrote:
Samuel Bronson naes...@gmail.com writes:
for i in 1 2
do
test_expect_success orderfile using
On Tue, Dec 17, 2013 at 10:02 PM, Eric S. Raymond e...@thyrsus.com wrote:
Jakub Narębski jna...@gmail.com:
Errr... doesn't cvs-fast-export support --export-marks=file to save
progress and --import-marks=file to continue incremental import?
No, cvs-fast-export does not have --export-marks. It
Eric S. Raymond e...@thyrsus.com 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
Jakub Narębski jna...@gmail.com:
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=file`
Any commits
Andreas Schwab sch...@linux-m68k.org:
Eric S. Raymond e...@thyrsus.com 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
brian m. carlson sand...@crustytoothpaste.net writes:
refname = prettify_refname(refname);
add_name_decoration(type, refname, obj);
while (obj-type == OBJ_TAG) {
- obj = ((struct tag *)obj)-tagged;
- if (!obj)
- break;
+
On Tue, Dec 17, 2013 at 5:09 PM, Junio C Hamano gits...@pobox.com 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.
Samuel Bronson naes...@gmail.com writes:
On Tue, Dec 17, 2013 at 5:09 PM, Junio C Hamano gits...@pobox.com 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
Roberto Tyley roberto.ty...@gmail.com 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
David Aguilar dav...@gmail.com 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
@@
26 matches
Mail list logo
