On Sat, May 17, 2014 at 08:41:22AM +0200, Christian Couder wrote:
This patch series comes from what Peff sent in the following thread:
http://thread.gmane.org/gmane.comp.version-control.git/243361/focus=243528
The first 4 patches (1/4, 2/4, 3/4 and 4/4) didn't change since v1.
I added 6
On Sat, May 17, 2014 at 12:25:48AM -0700, Jeremiah Mahler wrote:
We have routines for reading directly into a strbuf, which eliminates
the need for this 1024-byte limit. We even have a wrapper that can make
this much shorter:
struct strbuf buf = STRBUF_INIT;
On Sat, May 17, 2014 at 01:59:11AM -0700, Jeremiah Mahler wrote:
if (signature) {
if (signature_file)
die(you cannot specify both a signature and a signature-file);
/* otherwise, we already have the value */
} else if (signature_file) {
struct strbuf buf =
On Sat, May 17, 2014 at 09:02:22AM -0700, Jeremiah Mahler wrote:
Added feature that allows a signature file to be used with format-patch.
$ git format-patch --signature-file ~/.signature -1
Now signatures with newlines and other special characters can be
easily included.
On Sun, May 18, 2014 at 01:22:02PM -0700, Jeremiah Mahler wrote:
@@ -742,6 +743,8 @@ static int git_format_config(const char *var, const char
*value, void *cb)
}
if (!strcmp(var, format.signature))
return git_config_string(signature, var, value);
+ if
On Mon, May 19, 2014 at 11:42:07AM +0200, Michael Haggerty wrote:
On 05/18/2014 08:29 PM, Christian Couder wrote:
The usage string for this option is:
git replace [-f] --graft commit [parent...]
First we create a new commit that is the same as commit
except that its parents are
On Mon, May 19, 2014 at 03:05:42PM +0200, Alexandre Badez wrote:
The '.' directory is not the same as the root directory; you can see
that the /README.md and /./README.md are different.
Right. Inside git trees, . as an entry name does not have any special
meaning. However, because it does have
On Mon, May 19, 2014 at 08:17:07AM -0500, Robert Dailey wrote:
I have run the following command:
log --graph --abbrev-commit --decorate --date=relative
--format=format:'%C(bold blue)%h%C(reset)%x09%C(bold
green)(%ar)%C(reset)%C(bold yellow)%d%C(reset) %C(dim
white)%an%C(reset) -
On Mon, May 19, 2014 at 06:12:10PM +1000, Bryan Turner wrote:
For starters, to return an error message, your status must be 200 OK.
You can't return any other status code or Git will interpret your
error as some form of _HTTP_ error rather than a _git_ error.
As of git v1.8.3, git will show
On Mon, May 19, 2014 at 07:03:58PM +0400, Marat Radchenko wrote:
`git push` writes to stderr instead of stdout
That's by design.
Which one is correct is largely a matter of philosophy / mental model.
This case has been discussed before:
On Mon, May 19, 2014 at 09:12:47PM +0630, Arup Rakshit wrote:
Is there any difference between the below 2 commands ? I didn't see anything.
git rm --cached -- file1 .. fileN
This one removes the index entries for those files.
git checkout -- file1 .. fileN
This one checks out the
On Mon, May 19, 2014 at 09:27:47PM +0630, Arup Rakshit wrote:
Is there any difference between the below 2 commands ? I didn't see
anything.
git rm --cached -- file1 .. fileN
git checkout -- file1 .. fileN
Please Ignore the previous.
Too late. :)
I apologize to rewriting and
On Mon, May 19, 2014 at 10:25:10AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
It might make sense to just teach parse_commit_header to be a little
more thorough; it has to read past those lines anyway to find the author
and committer lines, so it would not be much more
On Mon, May 19, 2014 at 10:46:21PM -0700, Jeremiah Mahler wrote:
Avoiding that is easy with an indirection, no? Something like this
at the top:
static const char *the_default_signature = git_version_string;
static const char *signature = the_default_signature;
and comparing
.
We can push this check down into diff_setup_done, which is
probably a better place anyway. It is the diff code that
introduces this restriction, so other parts of the code
should not need to care themselves.
Reported-by: Michael S. Tsirkin m...@redhat.com
Signed-off-by: Jeff King p...@peff.net
sense.
But one could easily specify a longer, multi-line signature,
like:
git format-patch --signature='
this is my long signature
it has multiple lines
' ...
We should notice that it already has its own trailing
newline, and suppress one of ours.
Signed-off-by: Jeff King p...@peff.net
On Tue, May 20, 2014 at 10:53:11AM -0700, Junio C Hamano wrote:
I actually think these supress extra LFs trying to be overly smart
and inviting unnecessary surprises. Unlike log messages people type
(in which we do squash runs of blank lines and other prettifying),
mail-signature string is
As of commit 426e70d (remote-curl: show server content on http errors,
2013-04-05), we relay any text/plain errors shown by the remote http
server to the user. However, we were lazy back then and left this TODO
in place:
/*
* We only show text/plain parts, as other types are likely
Turning on this variable can be useful when debugging http
tests. It does break a few tests in t5541, but it is not
a variable that the user is likely to have enabled
accidentally.
Signed-off-by: Jeff King p...@peff.net
---
Not necessary for this series, but I found it helpful.
I took a look
This makes config's lowercase() function public.
Note that we could continue to offer a pure-string
lowercase, but there would be no callers (in most
pure-string cases, we actually duplicate and lowercase the
duplicate).
Signed-off-by: Jeff King p...@peff.net
---
This ones gets used later
We have two implementations of the same function; let's drop
that to one. We take the name from daemon.c, but the
implementation (which is just slightly more efficient) from
the config code.
Signed-off-by: Jeff King p...@peff.net
---
Unlike the last patch, this one does _not_ get used elsewhere
-by: Jeff King p...@peff.net
---
I think this is fine. If not, we can either:
1. Use strcasecmp and friends more consistently when
parsing/comparing (later bits of the series will need to be
adjusted).
2. Downcase here in a more context-aware way.
http.c| 4 +++-
remote-curl.c
Since commit 426e70d (remote-curl: show server content on
http errors, 2013-04-05), we relay any text/plain error
messages from the remote server to the user. However, we
never tested it.
Signed-off-by: Jeff King p...@peff.net
---
t/lib-httpd.sh | 1 +
t/lib-httpd/apache.conf
Using write_script will set our shebang line appropriately
with $SHELL_PATH. The script that is there now is quite
simple and likely to succeed even with a non-POSIX /bin/sh,
but it does not hurt to be defensive.
Signed-off-by: Jeff King p...@peff.net
---
t/lib-httpd.sh | 6
-by: Jeff King p...@peff.net
---
remote-curl.c | 26 ++
t/lib-httpd/error.sh | 8 +++-
t/t5550-http-fetch-dumb.sh | 5 +
3 files changed, 30 insertions(+), 9 deletions(-)
diff --git a/remote-curl.c b/remote-curl.c
index a5ab977..6d1b206 100644
This is a convenience wrapper around `reencode_string_len`
and `strbuf_attach`.
Signed-off-by: Jeff King p...@peff.net
---
Documentation/technical/api-strbuf.txt | 5 +
strbuf.c | 17 +
strbuf.h | 1 +
3 files
As of the last commit, we now recognize an error message
with a content-type text/plain; charset=utf-16 as text,
but we ignore the charset parameter entirely. Let's encode
it to log_output_encoding, which is presumably something the
user's terminal can handle.
Signed-off-by: Jeff King p
On Tue, May 20, 2014 at 11:46:51AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
If it were just --signature, I'd agree. After all, nobody is even
complaining. But this is also in preparation for --signature-file.
Should the user create a file without a trailing newline
On Wed, May 21, 2014 at 02:35:46PM +0400, Sergei Organov wrote:
Was writing conversion script from CVS to git for my repo and noticed
slight inconsistency in git-tag, git-branch, and git-update-ref behavior:
$ git --version
git version 1.9.3
$ git tag -d echo success
success
This makes
On Tue, May 20, 2014 at 09:11:24PM +0200, Karsten Blees wrote:
Add performance tracing to identify which git commands are called and how
long they execute. This is particularly useful to debug performance issues
of scripted commands.
Usage example: GIT_TRACE_PERFORMANCE=~/git-trace.log git
On Tue, May 20, 2014 at 09:11:19PM +0200, Karsten Blees wrote:
Add trace_performance and trace_performance_since macros that print file
name, line number, time and an optional printf-formatted text to the file
specified in environment variable GIT_TRACE_PERFORMANCE.
Unless enabled via
On Wed, May 21, 2014 at 09:55:43AM -0700, Jeremiah Mahler wrote:
I am fine with including your previous patch.
I think that would be my preference, but we'll see what Junio says.
Would like me to test it out and create another patch set?
Yeah, that would be the logical next step. I think the
On Wed, May 21, 2014 at 10:37:05AM -0700, Junio C Hamano wrote:
I wasn't planning on anything as drastic as stripspace. I really just
wanted to suppress the one newline, which is almost certainly the right
thing to include for --signature, but the wrong thing for
--signature-file (i.e.,
On Wed, May 21, 2014 at 11:26:18AM -0700, Junio C Hamano wrote:
Yeah, I agree with the last sentence. My mention of cleansing
took into account your do we want to omit the leading blank as
well? as well. In any case, wouldn't reusing stripspace() make the
fix-up shorter?
Not really. Doing
On Wed, May 21, 2014 at 08:34:47PM +0200, Karsten Blees wrote:
Macros are mainly used to supply __FILE__ and __LINE__, so that lazy
people don't need to think of a unique message for each use of
trace_performance_*. Without __FILE__, __LINE__ and message, the
output would be pretty useless
On Wed, May 21, 2014 at 02:58:42PM -0700, Junio C Hamano wrote:
! grep ^-- \$ output
...
We have been trying not to do the above in recent test updates. It
would be nice if this set-up did not have to be outside of the usual
test_expect_success structure.
Jeff
On Fri, Aug 08, 2014 at 03:18:11PM -0700, Junio C Hamano wrote:
* jk/pack-bitmap (2014-08-04) 1 commit
- pack-bitmap: do not use gcc packed attribute
Will merge to 'next'.
You may want to hold off on merging this; I hope Karsten will re-roll
his neater replacement patch next week, which
On Sun, Aug 10, 2014 at 05:14:33PM +0200, Stefan Beller wrote:
On 10.08.2014 15:57, Stefan Beller wrote:
Found by scan.coverity.com (Id: 1127809)
Signed-off-by: Stefan Beller stefanbel...@gmail.com
---
remote.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/remote.c
On Sun, Aug 10, 2014 at 06:13:27PM +0300, Alexander Shopov wrote:
Signed-off-by: Alexander Shopov a...@kambanaria.org
It would probably make sense to put the discussion from your cover
letter into the commit message.
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index
On Fri, Aug 08, 2014 at 02:58:26PM -0700, Jonathan Nieder wrote:
Maybe it's worth switching to plain
LIB_H += $(wildcard *.h)
? People using ancient compilers that never change headers wouldn't
be hurt, people using modern compilers that do change headers also
wouldn't be hurt,
), and
that it is insufficient (calling is_repository_shallow is
not enough, as the shallow grafts we register do not change
its return value). Instead, we can just turn off bitmaps
explicitly when we see these lines.
Signed-off-by: Jeff King p...@peff.net
---
Sorry not to catch this earlier. The bug is in v2.0
On Tue, Aug 12, 2014 at 10:13:03PM +0700, Duy Nguyen wrote:
On Tue, Aug 12, 2014 at 11:34 AM, Jeff King p...@peff.net wrote:
Arguably is_repository_shallow should return 1 if anybody has registered
a shallow graft, but that wouldn't be enough to fix this (we'd still
need to check it again
On Thu, Aug 14, 2014 at 06:51:04PM +0700, Nguyễn Thái Ngọc Duy wrote:
- static const char *argv_gc_auto[] = {
- gc, --auto, NULL,
- };
+ struct argv_array argv_gc_auto = ARGV_ARRAY_INIT;
packet_trace_identity(fetch);
@@ -1198,7 +1196,8 @@ int
On Thu, Aug 14, 2014 at 06:51:05PM +0700, Nguyễn Thái Ngọc Duy wrote:
Noticed-by: Matthew Flaschen mflasc...@wikimedia.org
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin/fetch.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/builtin/fetch.c b/builtin/fetch.c
at the
top of the file. That fixes this instance and future-proofs
against it happening again.
Reported-by: Jack Nagel jackna...@gmail.com
Signed-off-by: Jeff King p...@peff.net
---
On Sun, Aug 17, 2014 at 01:49:49AM -0500, Jack Nagel wrote:
$ make -C contrib/subtree
/Library/Developer/CommandLineTools
On Sun, Aug 17, 2014 at 12:55:23AM +0200, René Scharfe wrote:
Most struct child_process variables are cleared using memset right after
declaration. Provide a macro, CHILD_PROCESS_INIT, that can be used to
initialize them statically instead. That's shorter, doesn't require a
function call
On Sat, Aug 16, 2014 at 07:52:44PM -0500, Travis Carden wrote:
I would like to propose the addition of a `git remote prune --all`
command option or similar mechanism for pruning all remotes in a
repository. For lack of such a feature, I've been using the following
bash alias:
alias
On Sat, Aug 16, 2014 at 06:26:08PM +0200, Steffen Prohaska wrote:
Is the 15MB limit supposed to be imposed somewhere or is it just a guide
of how much memory we expect Git to use in this scenario?
The test should confirm that the the file that is added is not mmapped
to memory. The
On Sun, Aug 17, 2014 at 09:25:58AM +0200, René Scharfe wrote:
I think one reason we never had an INIT macro here is that you cannot
simply use the struct after zero-ing it anyway. That's just the first
step, and then you have to tweak a bunch of fields to get what you want.
So the memset is
On Wed, Aug 13, 2014 at 07:30:43PM +0200, Bernhard Reiter wrote:
Signed-off-by: Bernhard Reiter ock...@raz.or.at
---
imap-send.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
Thanks, this looks obviously correct and is a good direction.
-Peff
--
To unsubscribe from this list:
On Wed, Aug 13, 2014 at 07:31:24PM +0200, Bernhard Reiter wrote:
diff --git a/http.c b/http.c
index c8cd50d..afe4fc5 100644
--- a/http.c
+++ b/http.c
@@ -300,6 +300,9 @@ static CURL *get_curl_handle(void)
{
CURL *result = curl_easy_init();
+ if (!result)
+
On Mon, Aug 11, 2014 at 04:59:15PM +1200, Chris Packham wrote:
Is there any way where we could share the conflict resolution around
but still end up with a single merge commit. I'm thinking of something
like the following workflow
This came up once a while back. Here's the discussion:
On Tue, Aug 12, 2014 at 06:38:38PM +0200, René Scharfe wrote:
Am 11.08.2014 um 23:11 schrieb Stefan Beller:
This was found by coverity. (Id: 290001)
the variable 'output' is only assigned to a value inequal to NUL,
after all gotos to the corrupt label.
Therefore we can conclude the two
On Tue, Aug 12, 2014 at 06:59:17PM -0700, Jonathan Nieder wrote:
+ curl_socket_t sockfd = tunnel.out; // what about tunnel.in ?
Hmm. curl expects to get a socket it can send(), recv(), setsockopt(),
etc on instead of a pair of fds to read() and write().
I wonder if we could
On Wed, Aug 13, 2014 at 01:32:56AM +0630, Arup Rakshit wrote:
arup@linux-wzza:~/Ruby/yzz git push origin posward
Warning: Permanently added the RSA host key for IP address '192.30.252.131'
to
the list of known hosts.
ERROR: Permission to boris-s/yzz.git denied to aruprakshit.
fatal: Could
On Sun, Aug 17, 2014 at 09:46:42AM +0200, Johannes Sixt wrote:
This is a step in the right direction, IMO. This way to initialize the
struct feels mucth better because it does not depend on that the bit
pattern of the NULL pointer is all zeros.
I think platforms with NULL as something besides
On Sun, Aug 17, 2014 at 02:56:10PM +0200, Bernhard Reiter wrote:
I'm not sure if that would cause problems on Windows,
though.
Apparently socketpair is not available there. Googling socketpair
windows yields, among a lot of other useful resources, the following
relatively actively
On Mon, Aug 18, 2014 at 11:18:52AM -0700, Junio C Hamano wrote:
Are we sure that a^, which cannot be true for any string, will not
be caught by anybody's regcomp() as an error? I know regcomp()
accepts the expression and regexec() fails to match with GNU libc,
but that is not the whole of
run the regular test suite, which
should give a lot of profile data (and is what we used to do
prior to 5d7fd6d anyway).
Signed-off-by: Jeff King p...@peff.net
---
As a side note, while testing this I noticed that the make perf run
goes a lot faster if you set GIT_PERF_REPEAT_COUNT=1. This is bad
On Mon, Aug 18, 2014 at 11:03:51PM -0700, Junio C Hamano wrote:
We already have some code paths that use ((void *)1) as a special
pointer value, so in that sense I would say it is not the end of the
world if you added a new one.
No, but if you use it to replace the regexp, you end up having
On Sun, Aug 17, 2014 at 06:33:54PM +0700, Duy Nguyen wrote:
For files 2GB on a 32-bit system (e.g. msysgit), filtering with the
previous code always failed. Now it works. I created the patch to
change git from 'fundamentally doesn't handle this' to 'works as
expected'.
I deal with
On Tue, Aug 19, 2014 at 04:05:21PM +1000, Babak M wrote:
I saw that if a hook file is present in .git/hooks and it does not
have execution permissions it is silently ignored.
I thought it might be worthwhile issuing a warning such as Warning:
pre-commit hook exists but it cannot be executed
On Sun, Aug 17, 2014 at 09:30:47AM -0400, Jason Pyeron wrote:
I am working on an open source project right now where we are looking
to enforce a N of M audit approval process. It turns out that git
supports verifying multiple signatures because gpg supports signature
merging.
In the scheme
path
stored, we take a slight shortcut: if neither of the entries
is a sub-tree then the comparison is equivalent to a strcmp.
This lets us skip the extra strlen calls in the common case
without having to reimplement base_name_compare from
scratch.
Signed-off-by: Jeff King p...@peff.net
On Tue, Aug 19, 2014 at 10:14:30PM -0400, Jeff King wrote:
diff --git a/t/t4038-diff-combined.sh b/t/t4038-diff-combined.sh
index 1019d7b..71a664d 100755
--- a/t/t4038-diff-combined.sh
+++ b/t/t4038-diff-combined.sh
@@ -401,4 +401,38 @@ test_expect_success 'combine diff missing delete bug
On Wed, Aug 20, 2014 at 10:16:11AM +0200, Davide Fiorentino wrote:
I was in the need to rewrite author name and email and commit date for a
single commit and I guess I found a bug.
I run this git-filter script
$ git filter-branch --commit-filter ‘
if [ $GIT_COMMIT=9cfca27 ];
On Wed, Aug 20, 2014 at 08:55:52PM +1200, Chris Packham wrote:
I actually find the existing behaviour useful. If I want to disable a
hook to I can just chmod -x .git/hook/... and I then chmod +x it when
I want to re-enable it. I guess I could live with an extra warning as
long as the command
are
numbers for git.git:
$ time git fast-export --anonymize --all \
--tag-of-filtered-object=drop output
real0m2.883s
user0m2.828s
sys 0m0.052s
$ gzip output
$ ls -lh output.gz | awk '{print $5}'
2.9M
Signed-off-by: Jeff King p...@peff.net
---
I haven't used
in:
Signed-off-by: Jeff King p...@peff.net
* jn/header-dependencies (2014-08-10) 1 commit
- Update hard-coded header dependencies
Needs further discussions on the list.
We could take Jonathan's patch in the meantime, which is a strict
improvement. I'll try to push the other part
On Sun, Aug 10, 2014 at 03:48:24PM -0400, Jeff King wrote:
On Fri, Aug 08, 2014 at 02:58:26PM -0700, Jonathan Nieder wrote:
Maybe it's worth switching to plain
LIB_H += $(wildcard *.h)
? People using ancient compilers that never change headers wouldn't
be hurt, people using
. This is not
ideal because almost nobody wants to build po/git.pot (only
the translation maintainer does it, and even then only once
or twice per release). We can hack around this by invoking a
sub-make which evaluates the variable only when po/git.pot
is actually being built.
Signed-off-by: Jeff King p
). But that is reasonably unlikely to be
added, and even less likely to be noticed by this tool
(because it has to be run manually)., It is not worth
carrying around the cruft in the Makefile.
Signed-off-by: Jeff King p...@peff.net
---
I'm open to leaving this, as it's not hurting anything aside from
, 2012-04-02). The stdin
option (and in particular, its use of packet-lines for
stateless-rpc input) is modeled after that solution.
Signed-off-by: Jeff King p...@peff.net
---
I had to fiddle with the numbers in the http test. Linux gives up to 1/4
of the configured stack ulimit as space
On Thu, Aug 21, 2014 at 08:17:10AM -0400, Jeff King wrote:
Documentation/git-send-pack.txt | 13 -
builtin/send-pack.c | 27 +++
remote-curl.c | 8 +++-
t/t5541-http-push-smart.sh | 15 +++
4 files
On Thu, Aug 21, 2014 at 01:15:10PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
+/*
+ * We anonymize each component of a path individually,
+ * so that paths a/b and a/c will share a common root.
+ * The paths are cached via anonymize_mem so that repeated
+ * lookups
On Thu, Aug 21, 2014 at 02:57:22PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
+--anonymize::
+ Replace all paths, blob contents, commit and tag messages,
+ names, and email addresses in the output with anonymized data,
+ while still retaining the shape
On Thu, Aug 21, 2014 at 06:49:10PM -0400, Jeff King wrote:
The few things I don't anonymize are:
1. ref prefixes. We see the same distribution of refs/heads vs
refs/tags, etc.
2. refs/heads/master is left untouched, for convenience (and because
it's not really a secret
On Thu, Aug 21, 2014 at 08:30:24PM +0200, René Scharfe wrote:
Similar to 16445242 (fetch-pack: avoid quadratic list insertion in
mark_complete), sort only after all refs are collected instead of while
inserting. The result is the same, but it's more efficient that way.
The difference will
On Thu, Aug 21, 2014 at 08:30:29PM +0200, René Scharfe wrote:
Similar to 16445242 (fetch-pack: avoid quadratic list insertion in
mark_complete), sort only after all refs are collected instead of while
inserting. The result is the same, but it's more efficient that way.
The difference will
On Thu, Aug 21, 2014 at 07:48:18AM -0700, Jonathan Nieder wrote:
Subject: i18n: treat make pot as an explicitly-invoked target
po/git.pot is normally used as-is and not regenerated by people
building git, so it is okay if an explicit make po/git.pot always
automatically regenerates it.
On Fri, Aug 22, 2014 at 12:12:36AM -0400, Jeff King wrote:
po/git.pot is normally used as-is and not regenerated by people
building git, so it is okay if an explicit make po/git.pot always
automatically regenerates it. Depend on the magic FORCE target
instead of explicitly keeping track
, to force those files to be
built when regenerating git.pot.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
Signed-off-by: Jeff King p...@peff.net
---
Mostly as you sent it, but I mentioned the missing script dependencies
in the commit message, too.
Makefile | 2 +-
1 file changed, 1 insertion(+), 1
it was not otherwise useful here.
Signed-off-by: Jeff King p...@peff.net
---
I cannot see any reason for the :=, but maybe I am missing something.
Makefile | 140 ---
1 file changed, 8 insertions(+), 132 deletions(-)
diff --git a/Makefile b
). But that is reasonably unlikely to be
added, and even less likely to be noticed by this tool
(because it has to be run manually)., It is not worth
carrying around the cruft in the Makefile.
Signed-off-by: Jeff King p...@peff.net
---
Same as before.
Makefile | 59
value to 0, and do:
ret = poll(pfd, pollsize, keepalive ? 1000 * keepalive : -1);
which would let us avoid setting it to -1 in some other spots. I dunno
if that actually makes a real difference to maintainability, though.
Either way:
Acked-by: Jeff King p...@peff.net
-Peff
--
To unsubscribe
On Fri, Aug 22, 2014 at 08:56:12AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
Since we're now translating the keepalive value, and since there's no
way to set it to 0 (nor would that really have any meaning), I guess
we could switch the internal no keepalive value to 0
I noticed that git pack-refs --all will pack a top-level ref like
refs/foo, but will not actually prune $GIT_DIR/refs/foo. I do not
see the point in having a policy not to pack refs/foo if --all is
given. But even if we did have such a policy, this seems broken; we
should either pack and prune, or
refs/stash, but that is not quite true. It does pack the
ref, but due to a bug, fails to prune the ref. When we fix
that bug, we would want to be doing the right thing here.
Signed-off-by: Jeff King p...@peff.net
---
I know we are pretty sensitive to forks in the prompt code (after all
be omitted much earlier by pack_ref_is_possible,
which we do in this case if --all is not given).
We can fix this by switching to lock_any_ref_for_update.
This behaves exactly the same with the exception of this
top-level check.
Signed-off-by: Jeff King p...@peff.net
---
refs.c | 3 ++-
t
() again with a NULL
pack_data a noop (there is nothing to end).
We can further make things less confusing by dropping old_p
entirely, and moving new_p closer to its point of use.
Signed-off-by: Jeff King p...@peff.net
---
Noticed while running fast-import under valgrind to debug the next
commit
fast-import input
we'll overflow the buffer. We can fix it by using a strbuf.
Signed-off-by: Jeff King p...@peff.net
---
I'm not sure how easily exploitable this is. The buffer is on the stack,
and we definitely demolish the return address. But we never actually
return from the function, since
about it, let's make the fast-import
tests more robust by checking for fully qualified
refnames.
Signed-off-by: Jeff King p...@peff.net
---
As I mentioned, I'd be OK with dropping this one in favor of just
waiting for Ronnie's transaction patches to graduate.
fast-import.c | 4 ++--
t
On Fri, Aug 22, 2014 at 11:45:15AM -0700, Jonathan Nieder wrote:
Junio C Hamano wrote:
implication of which is that the 'at least one slash'
rule was to expect things are 'refs/anything' so there will be at
least one. Even back then, that anything alone had at least one
On Fri, Aug 22, 2014 at 07:39:59PM +0100, Philip Oakley wrote:
Just a bit of bikeshedding for future improvements..
The .gitignore is another potential user problem area that may benefit form
not being anonymised when problems strike.
Thanks, I had meant to mention some implications for
On Sat, Aug 23, 2014 at 09:29:36AM +0200, Michael Haggerty wrote:
[1/5]: git-prompt: do not look for refs/stash in $GIT_DIR
[2/5]: pack-refs: prune top-level refs like refs/foo
[3/5]: fast-import: clean up pack_data pointer in end_packfile
[4/5]: fast-import: fix buffer overflow
[+cc spearce, as I think this is a bug in code.google.com's sending
side, and he can probably get the attention of the right folks]
On Sat, Aug 23, 2014 at 12:12:08PM +0200, René Scharfe wrote:
Git 1.7.6 clones the repo without reporting an error or warning, but a
check shows that a tree
On Sat, Aug 23, 2014 at 06:56:40AM -0400, Jeff King wrote:
So I think your patch is doing the right thing.
By the way, if you want to add a test to your patch, there is
infrastructure in t5308 to create packs with duplicate objects. If I
understand the problem correctly, you could trigger
On Sat, Aug 23, 2014 at 07:04:59AM -0400, Jeff King wrote:
On Sat, Aug 23, 2014 at 06:56:40AM -0400, Jeff King wrote:
So I think your patch is doing the right thing.
By the way, if you want to add a test to your patch, there is
infrastructure in t5308 to create packs with duplicate
On Sun, Aug 24, 2014 at 06:07:44PM +0200, Steffen Prohaska wrote:
diff --git a/wrapper.c b/wrapper.c
index bc1bfb8..69d1c9b 100644
--- a/wrapper.c
+++ b/wrapper.c
@@ -11,14 +11,18 @@ static void (*try_to_free_routine)(size_t size) =
do_nothing;
static void memory_limit_check(size_t
On Sun, Aug 24, 2014 at 06:07:46PM +0200, Steffen Prohaska wrote:
The data is streamed to the filter process anyway. Better avoid mapping
the file if possible. This is especially useful if a clean filter
reduces the size, for example if it computes a sha1 for binary data,
like git media.
701 - 800 of 13736 matches
Mail list logo
