than simply returning random
bytes).
Signed-off-by: Jeff King p...@peff.net
---
cache.h | 1 +
sha1_file.c | 53 +
2 files changed, 54 insertions(+)
diff --git a/cache.h b/cache.h
index ce377e1..67356db 100644
--- a/cache.h
+++ b/cache.h
This series lets you query the delta base for a particular object (or
set of objects), like:
$ git rev-list --objects --all |
git cat-file --batch-check='%(objectname) %(deltabase) %(rest)'
The only other way I know of to get this information is using
verify-pack (or index-pack), which is
format,
which makes it fast and simple to get the bases for a subset
of the objects.
Signed-off-by: Jeff King p...@peff.net
---
Documentation/git-cat-file.txt | 12 +---
builtin/cat-file.c | 6 ++
t/t1006-cat-file.sh| 34 ++
3 files
When I want to debug a failing test, I often end up doing:
cd t
./t4107-tab -v -i
cd tratab
The test names are long, so tab-completing on the trash directory is
very helpful. Lately I've noticed that there are a bunch of crufty trash
directories in my t/ directory, which makes my
a harness.
Signed-off-by: Jeff King p...@peff.net
---
I do not have any plans to write such tests, and I'd be OK if we wanted
to stop this just at fixing up the comments. But it took me a while to
figure out what is going on, and I believe unsetting HARNESS_ACTIVE in
the sub-tests is the choice
suite is truly broken, since
it is not a test-within-a-test, as the later tests are.
Signed-off-by: Jeff King p...@peff.net
---
I am not _that_ bothered by the known breakage, but AFAICT there is
zero benefit to keeping this redundant test. But maybe I am missing
something.
t/t-basic.sh | 3
On Fri, Dec 27, 2013 at 08:47:54PM +0600, Sergey Sharybin wrote:
The web server software has nothing to do with HTTP[S] used by Git being
smart, I think, it just has to be set up properly.
Misunderstood git doc then which says it has to be Apache, currently
- other CGI servers don't work,
On Thu, Dec 26, 2013 at 11:27:10AM -0800, Junio C Hamano wrote:
I still need consensus on the name here guys, parse_prefix.
remove_prefix or strip_prefix? If no other opinions i'll go with
strip_prefix (Jeff's comment before parse_prefix() also uses strip)
Yup, that comment is where I
On Sat, Dec 28, 2013 at 02:13:13PM -0800, Jonathan Nieder wrote:
So the idea if I am reading correctly is Instead of relying on the
implicit output directory chosen with chdir, which doesn't even work
any more, set TEST_OUTPUT_DIRECTORY to decide where output for the
sub-tests used by t's
On Sat, Dec 28, 2013 at 12:51:04PM -0800, Jonathan Nieder wrote:
Jeff King wrote:
I am not _that_ bothered by the known breakage, but AFAICT there is
zero benefit to keeping this redundant test.
Devil's advocate: it ensures that anyone wrapping git's tests (like
the old smoketest
On Sat, Dec 28, 2013 at 03:56:55PM +0100, Alex Riesen wrote:
it is also a way to create a fork bomb out of the innocent tool on platforms
where pressing Ctrl-C does not terminate subprocesses of the foreground
process (like, of course, Windows).
To reproduce, run
git -c
On Mon, Dec 30, 2013 at 11:10:31AM -0800, Junio C Hamano wrote:
So I think the sanest thing is probably:
1. Teach fetch to expand recursively in a single process, and then
tell sub-processes (via a new command-line option) not to expand
any further.
2. Teach fetch to
On Mon, Dec 30, 2013 at 10:51:25AM -0800, Jonathan Nieder wrote:
I think it can be better, since the commit message left me scratching
my head while the patch itself seems pretty simple. How about
something like the following?
I am fine with that format, though...
Analysis and fix:
smarter git_terminal_prompt
wrapper), and sometimes it returns an allocated string from
do_askpass.
Signed-off-by: Jeff King p...@peff.net
---
prompt.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/prompt.c b/prompt.c
index d851807..d7bb17c 100644
--- a/prompt.c
+++ b
On Wed, Jan 01, 2014 at 10:03:30PM -0500, Jeff King wrote:
On Thu, Jan 02, 2014 at 09:06:33AM +0800, Tay Ray Chuan wrote:
We were leaking memory in there, as after obtaining a string from
git_getpass, we returned a copy of it, yet no one else held the original
string, apart from
On Thu, Jan 02, 2014 at 11:41:05AM -0800, Junio C Hamano wrote:
- builtin/merge.c is the same, but it is conceptually even worse.
It has the end-user supplied string and wants to see if it is a
valid strategy. If the user wants to use a custom strategy, a
single stat() to make sure
On Sun, Dec 22, 2013 at 09:55:23PM +, Ben Maurer wrote:
One issue with this approach is that it seems git-pack-index doesn't
perform as well with thin packs. git-index-pack uses a multi-threaded
approach to resolving the deltas. However, the multithreading only
works on deltas that are
On Sun, Dec 22, 2013 at 11:47:34AM -0800, Ben Maurer wrote:
Jeff King's bitmap branch appears to give a very substantial speedup.
After applying this branch, the counting objects phase is basically
free. However, I found that the compression phase still takes a
non-trivial amount of time.
On Mon, Jan 06, 2014 at 08:16:31AM -0800, Junio C Hamano wrote:
I was going to ask you to send your repository, but I can easily
reproduce here. I guess people don't run into it because it's uncommon
to fetch the whole refs/ namespace from a non-bare repo (and bare repos
do not tend to
On Mon, Jan 06, 2014 at 08:37:49AM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
We could probably teach index-pack an --assume-refs-are-thin
option to optimize for this case, and have fetch-pack/receive-pack pass
it whenever they know that delta-base-offset was negotiated
On Mon, Jan 06, 2014 at 12:06:51PM -0800, Junio C Hamano wrote:
Unless you set @{u} to this new configuration, in which case the
choice becomes dynamic depending on the current branch, but
- if that is the only sane choice based on the current branch, why
not use that as the default
On Mon, Jan 06, 2014 at 09:57:23AM -0500, Jeff King wrote:
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index c733379..0cff874 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -1402,6 +1402,19 @@ static void check_object(struct object_entry *entry
On Mon, Jan 06, 2014 at 03:29:57PM -0500, John Szakmeister wrote:
Yeah, I had similar thoughts. I personally use branch.*.merge as
forkedFrom, and it seems like we are going that way anyway with things
like git rebase and git merge defaulting to upstream. But then there
is git push -u and
On Mon, Jan 06, 2014 at 12:38:30PM -0800, Junio C Hamano wrote:
I wonder if it is too late to try to clarify this dual usage. It kind of
seems like the push config is this is the place I publish to. Which,
in many workflows, just so happens to be the exact same as the place you
forked
On Mon, Jan 06, 2014 at 09:15:04PM +, Ben Maurer wrote:
Let me know how this patch does for you. My testing has been fairly
limited so far.
This patch looks like a much cleaner version :-). Works well for me,
but my test setup may not be great since I didn't get any errors from
On Mon, Jan 06, 2014 at 12:17:21PM -0800, Junio C Hamano wrote:
I am fine with rejecting it with a warning, but we should not then
complain that the other side did not send us the object, since we should
not be asking for it at all. I also do not see us complaining about the
funny ref
On Mon, Jan 06, 2014 at 07:35:04PM -0800, Brodie Rao wrote:
On Mon, Jan 6, 2014 at 7:32 PM, Brodie Rao bro...@sf.io wrote:
This change ensures get_sha1_basic() doesn't try to resolve full hashes
as refs when ambiguous ref warnings are disabled.
This provides a substantial performance
On Mon, Jan 06, 2014 at 10:14:30PM +, Ben Maurer wrote:
It looks like for my repo the size win wasn't as big (~10%). Is it
possible that with the kernel test you got extremely lucky and there
was some huge binary blob that thin packing turned into a tiny delta?
I don't think so. When I
On Thu, Jan 02, 2014 at 11:08:51AM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
... But the test suite, of course, always uses askpass because it
cannot rely on accessing a terminal (we'd have to do some magic with
lib-terminal, I think).
So it doesn't detect
On Tue, Jan 07, 2014 at 09:51:07AM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
Alternatively, I guess cat-file
--batch could just turn off warn_ambiguous_refs itself.
Sounds like a sensible way to go, perhaps on top of this change?
The downside is that we would
On Tue, Jan 07, 2014 at 11:38:15AM -0800, Junio C Hamano wrote:
Alternatively, I guess cat-file
--batch could just turn off warn_ambiguous_refs itself.
Sounds like a sensible way to go, perhaps on top of this change?
The downside is that we would not warn about ambiguous refs
On Tue, Jan 07, 2014 at 11:44:00AM -0800, Junio C Hamano wrote:
test-terminal only handles stdout and stderr streams as fake terminals.
We could pretty easily add stdin for input, as it uses fork() to work
asynchronously. But the credential code does not actually read from
stdin. It
isn't specified.
To tackle this problem, introduce branch.*.forkedFrom which can specify
the parent branch of a topic branch. Future patches will build
functionality around this new configuration variable.
Cc: Jeff King p...@peff.net
Cc: Junio C Hamano gis...@pobox.com
Signed-off
On Tue, Jan 07, 2014 at 03:40:56AM +0530, Ramkumar Ramachandra wrote:
Jeff King wrote:
Yeah, I had similar thoughts. I personally use branch.*.merge as
forkedFrom, and it seems like we are going that way anyway with things
like git rebase and git merge defaulting to upstream.
My issue
On Tue, Jan 07, 2014 at 04:17:00AM +0530, Ramkumar Ramachandra wrote:
Junio C Hamano wrote:.
As I said in the different subthread, I am not convinced that you
would need the complexity of branch.*.forkedFrom. If you set your
upstream to the true upstream (not your publishing point), and
On Wed, Jan 08, 2014 at 02:32:10AM +0530, Ramkumar Ramachandra wrote:
we should leave @{upstream} as (1), and add a new option to represent
(2). Not the other way around.
I have a local branch 'forkedfrom' that has two sources: 'master'
and 'ram/forkedfrom'. 'ram/forkedfrom' isn't a dumb
On Tue, Jan 07, 2014 at 01:07:08PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
Yes, pushbranch is probably a better name for what I am referring to.
I agree that pushremote is probably enough for sane cases. I seem to
recall that people advocating the upstream push
On Wed, Jan 08, 2014 at 02:55:04AM +0530, Ramkumar Ramachandra wrote:
Jeff King wrote:
My daily procedure is something like:
all_topics |
while read topic; do echo $topic $(git rev-parse $topic@{u}); done |
topo_sort |
while read topic upstream; do
git rebase $upstream
On Tue, Jan 07, 2014 at 12:31:57PM -0800, Junio C Hamano wrote:
c. Just leave it at Brodie's patch with nothing else on top.
My thinking in favor of (b) was basically does anybody actually care
about ambiguous refs in this situation anyway?. If they do, then I
think (c) is my
We should always have been freeing our strbuf, but doing so
consistently was annoying until the refactoring in the
previous patch.
Signed-off-by: Jeff King p...@peff.net
---
builtin/cat-file.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/builtin/cat-file.c b/builtin/cat-file.c
index
.
Signed-off-by: Jeff King p...@peff.net
---
builtin/cat-file.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/builtin/cat-file.c b/builtin/cat-file.c
index ce79103..c64e287 100644
--- a/builtin/cat-file.c
+++ b/builtin/cat-file.c
@@ -264,6 +264,7 @@ static int batch_objects(struct
This just pulls the return value for the function out of the
inner loop, so we can break out of the loop rather than do
an early return. This will make it easier to put any cleanup
for the function in one place.
Signed-off-by: Jeff King p...@peff.net
---
Just making the subsequent diffs less
=raw
real0m0.675s
user0m0.552s
sys 0m0.120s
[after]
$ best-of-five -i commits ./git rev-list --stdin --no-walk --pretty=raw
real0m0.415s
user0m0.400s
sys 0m0.012s
Signed-off-by: Jeff King p...@peff.net
---
Obviously we drop this one (and revert 25fba78d
On Tue, Jan 07, 2014 at 02:06:12PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
I think that is sensible, and only heightens my sense of the upstream
push.default as useless. :)
Yes, it only is good for centralized world (it was designed back in
the centralized days
On Tue, Jan 07, 2014 at 05:08:56PM -0500, Jeff King wrote:
OK. I agree with that line of thinking. Let's take it one step at
a time, i.e. do c. and also use warn_on_object_refname_ambiguity in
rev-list --stdin first and leave the simplification (i.e. b.) for
later.
Here's a series
We should always have been freeing our strbuf, but doing so
consistently was annoying until the refactoring in the
previous patch.
Signed-off-by: Jeff King p...@peff.net
---
builtin/cat-file.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/builtin/cat-file.c b/builtin/cat-file.c
index
This just pulls the return value for the function out of the
inner loop, so we can break out of the loop rather than do
an early return. This will make it easier to put any cleanup
for the function in one place.
Signed-off-by: Jeff King p...@peff.net
---
builtin/cat-file.c | 11 +--
1
namespace, and make it available at both sites. This
is simple, and given that we do not have a proliferation of
flags (we have had exactly one until now), it is probably
sufficient.
Signed-off-by: Jeff King p...@peff.net
---
I think the flags thing is OK as explained above, but Michael may have
, with speedup]
$ best-of-five -i objects ./git cat-file --batch-check
real0m0.388s
user0m0.356s
sys 0m0.028s
So the new implementation does just as well as we did with
the flag turning the whole thing off (better actually, but
that is within the noise).
Signed-off-by: Jeff
is much lower, as we are avoiding
hundreds of thousands of stat() calls.
Signed-off-by: Jeff King p...@peff.net
---
I wanted to make the ref traversal as cheap as possible, hence the
NO_RECURSE flag I added. I thought INCLUDE_BROKEN used to not open up
the refs at all, but it looks like it does
On Tue, Jan 07, 2014 at 06:58:50PM -0500, Jeff King wrote:
+ if (flags DO_FOR_EACH_NO_RECURSE) {
+ struct ref_dir *subdir = get_ref_dir(entry);
+ sort_ref_dir(subdir);
+ retval
On Wed, Jan 08, 2014 at 02:59:37PM +0800, Li Zhang wrote:
I tried to add url xxx insteadof xxx in .gitconfig. If the length of
url exceed 125, git will not work.
I am using Ubuntu. The default version is 1.7.9.5. Maybe the latest
version solve this already.
Yes, this was fixed in 0971e99
On Wed, Jan 08, 2014 at 03:05:48AM +0530, Ramkumar Ramachandra wrote:
Agreed. I'll start working on @{publish}. It's going to take quite a
bit of effort, because I won't actually start using it until my prompt
is @{publish}-aware.
There's a fair bit of refactoring involved. I took a stab at
We will be adding new mark types in the future, so separate
the suffix data from the logic.
Signed-off-by: Jeff King p...@peff.net
---
sha1_name.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index b1873d8..0c50801 100644
Right now we simply check if ret is valid before doing
further processing. As we add more processing, this will
become more and more cumbersome. Instead, let's just check
whether ret is invalid and return early with the error.
Signed-off-by: Jeff King p...@peff.net
---
remote.c | 5 -
1 file
we
store separately as pushremote_config_default.
We can then set the branch's pushremote field by doing the
normal sequence of config fallback.
Signed-off-by: Jeff King p...@peff.net
---
remote.c | 23 +++
remote.h | 2 ++
2 files changed, 21 insertions(+), 4 deletions
simpler to add more constructs in future patches.
While we're at it, let's also break apart the refactored
code into a few helper functions. These will be useful when
we implement similar @{upstream}-like constructs.
Signed-off-by: Jeff King p...@peff.net
---
sha1_name.c | 83
an example:
$ git checkout -b foo origin/master
$ git config remote.pushdefault github
$ git push
Signed-off-by: Jeff King p...@peff.net
---
The implementation feels weird, like the where do we push to code
should be factored out from somewhere else. I think what we're doing
here is not _wrong_
On Tue, Jan 07, 2014 at 10:47:33PM -0500, Jeff King wrote:
On Tue, Jan 07, 2014 at 06:58:50PM -0500, Jeff King wrote:
+ if (flags DO_FOR_EACH_NO_RECURSE) {
+ struct ref_dir *subdir = get_ref_dir(entry);
+ sort_ref_dir
On Wed, Jan 08, 2014 at 04:35:31AM -0500, Jeff King wrote:
@@ -385,8 +387,11 @@ static int handle_config(const char *key, const char
*value, void *cb)
name = key + 7;
/* Handle remote.* variables */
- if (!strcmp(name, pushdefault))
- return git_config_string
-01-04)
because t5531.6 is trying to provoke a failure of git push
due to a submodule check. When combined with b2ed944 the
push still fails, but for the wrong reason (because our
upstream setup does not exist, not because of the submodule).
Signed-off-by: Jeff King p...@peff.net
---
On Wed, Jan 08
On Wed, Jan 08, 2014 at 05:27:07AM -0500, Jeff King wrote:
This patch passes the test suite by itself (with or without that fixup).
But oddly, it seems to fail t5531 when merged with 'next'. I can't
figure out why, though. It shouldn't affect any code that doesn't look
at branch-pushremote
On Thu, Dec 05, 2013 at 08:02:50PM +0700, Nguyễn Thái Ngọc Duy wrote:
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Documentation/gitremote-helpers.txt | 7 +++
builtin/fetch-pack.c| 16 +---
remote-curl.c | 31
On Wed, Jan 08, 2014 at 03:42:09PM -0800, Junio C Hamano wrote:
This patch introduces the branch@{publish} shorthand (or
@{pu} to be even shorter). It refers to the tracking
If @{u} can already be used for upstream, why not allow @{p} but
require two letters @{pu}? Just being curious---I
On Wed, Jan 08, 2014 at 12:29:51PM +0100, Michael Haggerty wrote:
Here's a fixed version of patch 3/5.
v2 4/5 doesn't apply cleanly on top of v3 3/5. So I'm basing my review
on the branch you have at GitHub peff/git jk/cat-file-warn-ambiguous;
I hope it is the same.
Hrmph. I didn't have
On Thu, Jan 09, 2014 at 09:51:24AM -0800, Junio C Hamano wrote:
On Tue, Jan 07, 2014 at 06:58:50PM -0500, Jeff King wrote:
+ if (flags DO_FOR_EACH_NO_RECURSE) {
+ struct ref_dir *subdir = get_ref_dir(entry
On Wed, Jan 08, 2014 at 07:13:19PM +0700, Nguyễn Thái Ngọc Duy wrote:
Commit 48d25ca adds a new commit 7 to the repo that the next test case
in commit 1609488 clones from. But the next test case does not expect
this commit. For these tests, it's the bottom that's important, not
the top. Fix
On Thu, Jan 09, 2014 at 08:39:44AM -, Philip Oakley wrote:
From: Jeff King p...@peff.net
Sent: Wednesday, January 08, 2014 9:37 AM
In a triangular workflow, you may have a distinct
@{upstream} that you pull changes from, but publish by
default (if you typed git push) to a different
On Fri, Jan 10, 2014 at 09:59:25AM +0100, Michael Haggerty wrote:
However, is it safe to prime only part of the loose ref namespace?
[...]
prime_ref_dir() is called by do_for_each_entry(), which all the
iteration functions pass through. It is always called before the
iteration starts,
On Wed, Jan 08, 2014 at 05:09:25PM +0100, Michael Haggerty wrote:
It's not only racy WRT other processes. If the current git process
would create a new reference, it wouldn't be reflected in the cache.
It's true that the main ref_cache doesn't invalidate itself
automatically either when a
On Fri, Jan 10, 2014 at 03:34:59PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
... but the
failing test is actually somewhat broken in 'next' already.
Hmph, in what way? I haven't seen t5531 breakage on 'next', with or
without your series...
The test still passes
On Sun, Jan 12, 2014 at 10:41:06PM +0530, Ramkumar Ramachandra wrote:
When a caller uses branch_get() to retrieve a struct branch, they get
the per-branch remote name and a pointer to the remote struct. However,
they have no way of knowing about the per-branch pushremote from this
interface.
On Mon, Jan 13, 2014 at 04:52:52PM +0530, Ramkumar Ramachandra wrote:
Not sure I understand what the problem is. Let's say we have two
branches: master, and side with remote.pushdefault = ram,
branch.*.remote = origin, and branch.side.pushremote = peff. Now, when
I query master's pushremote,
On Mon, Jan 13, 2014 at 12:15:08PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
It does not matter for actually pushing, because to do a non-default
push, you must always specify a remote. But @{publish} will ask the
question even if I am on 'side' now, what would happen
On Fri, Jan 10, 2014 at 04:41:20AM -0500, Jeff King wrote:
That being said, we could further optimize this by not opening the files
at all (and make that the responsibility of do_one_ref, which we are
avoiding here). I am slightly worried about the open() cost of my
solution. It's amortized
On Tue, Jan 14, 2014 at 03:45:27PM -0800, Junio C Hamano wrote:
Yet 'git check-ref-format --branch @mybranch@{u}'
claims @mybranch is an invalid branch name.
I do not think it claims any such thing.
$ git check-ref-format --branch @foo@{u}; echo $?
fatal: '@foo@{u}' is not a
On Tue, Jan 14, 2014 at 11:46:58PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
Is that what --branch does? I have never used it, but the manpage
seems to suggest it is about _parsing_ (which, IMHO, means it probably
should have been an option to rev-parse
On Wed, Jan 15, 2014 at 12:00:03AM -0500, Jeff King wrote:
$ git rev-parse --symbolic-full-name HEAD@{u}
refs/remotes/origin/master
$ git rev-parse --symbolic-full-name @mybranch@{u}
@mybranch@{u}
fatal: ambiguous argument '@mybranch@{u}': unknown revision or path
simpler to further refactor the function in future patches.
While we're at it, let's also break apart the refactored
code into a few helper functions. These will be useful if we
eventually implement similar @{upstream}-like constructs.
Signed-off-by: Jeff King p...@peff.net
---
This is identical
In the original version of this function, cp acted as a
pointer to many different things. Since the refactoring in
the last patch, it only marks the at-sign in the string.
Let's use a more descriptive variable name.
Signed-off-by: Jeff King p...@peff.net
---
Obviously can be squashed
the
code more obviously correct, and to future-proof us
against callers with more exotic buffers.
Signed-off-by: Jeff King p...@peff.net
---
sha1_name.c| 17 ++---
t/t1508-at-combinations.sh | 15 ++-
2 files changed, 24 insertions(+), 8 deletions
that
the upstream mark we found is actually a pathname, and
should be disregarded completely. This patch implements that
logic.
Signed-off-by: Jeff King p...@peff.net
---
I think this would actually be cleaner if get_sha1() simply did the
colon-parsing first, and omitted the first pass completely. Then
sub
to
find the left-most one in this case (and we then recurse as
HEAD@{upstream}).
Signed-off-by: Jeff King p...@peff.net
---
And this one actually fixes Keith's bug.
The diff is noisy due to indentation changes; try it with -b for
increased reading pleasure.
sha1_name.c | 20
On Wed, Jan 15, 2014 at 01:56:52PM +0800, 乙酸鋰 wrote:
what are the possible causes of this?
After stash pop, refs/stash becomes 40 zeroes.
This is the only stash, so refs/stash should be deleted after pop.
However, it becomes 40 zeroes.
git 1.8.x
I can't reproduce the problem here. Running
On Tue, Jan 14, 2014 at 02:42:09PM -0500, Martin Langhoff wrote:
On Tue, Jan 14, 2014 at 2:36 PM, Martin Fick mf...@codeaurora.org wrote:
Perhaps the receiving process is dying hard and leaving
stuff behind? Out-of-memory, out of disk space?
Yes, that's my guess as well. This server had
On Tue, Jan 14, 2014 at 04:41:03PM +0100, krz...@gmail.com wrote:
git can't execute hooks no partitions mounted with noexec - even if
those are just scripts with shebang line
Right. Git does not know that they are shell (or other) scripts; they
could be anything, and the advertised interface
[+cc Junio, as the bug blames to him]
On Fri, Jan 10, 2014 at 02:15:40PM +0100, Francis Moreau wrote:
In mykernel repository, I'm having 2 different behaviours with git-log
but I don't understand why:
Doing:
$ git log --oneline --cherry-pick --left-right v3.4.71-1^{}...next
and
with the multiple levels of
filtering (which can cause problems when they are out of
sync), or even forbid one-level refs entirely. However,
those decisions can come later; this fixes the most
immediate problem, which is the mismatch between the two.
Signed-off-by: Jeff King p...@peff.net
On Wed, Jan 15, 2014 at 05:46:13AM -0500, Jeff King wrote:
This discussion stalled, but I finally got around to looking at it
today. I agree that we should leave aside more complex policy for now,
and start with bringing the fetch and fetch-pack filters into
harmony. That turns off format
On Sun, Jan 12, 2014 at 06:03:39PM +0700, Nguyễn Thái Ngọc Duy wrote:
This patch establishes a connection between a new file watcher daemon
and git. Each index file may have at most one file watcher attached to
it. The file watcher maintains a UNIX socket at
$GIT_DIR/index.watcher. Any
On Wed, Jan 15, 2014 at 11:37:08AM +0100, David Kastrup wrote:
The question is what guarantees I have with regard to the commit date of
a commit in relation to that of its parent commits:
a) none
b) commitdate(child) = commitdate(parent)
c) commitdate(child) commitdate(parent)
a) none
is simple and safe both for current and future
code.
Signed-off-by: Jeff King p...@peff.net
---
On top of jk/pack-bitmap.
pack-revindex.c | 11 ---
pack-revindex.h | 1 -
sha1_file.c | 1 -
3 files changed, 13 deletions(-)
diff --git a/pack-revindex.c b/pack-revindex.c
index 0bb13b1
On Wed, Jan 15, 2014 at 11:57:39AM -0800, Junio C Hamano wrote:
Where do we pass down other flags from tags to commits? For
example, if we do this:
$ git log ^v1.8.5 master
we mark v1.8.5 tag as UNINTERESTING, and throw that tag (not commit
v1.8.5^0) into revs-pending.objects[].
On Wed, Jan 15, 2014 at 12:26:13PM -0800, Junio C Hamano wrote:
With the previous fix 895c5ba3 (revision: do not peel tags used in
range notation, 2013-09-19), handle_revision_arg() that processes
command line arguments for the git log family of commands no
longer directly places the object
On Thu, Jan 16, 2014 at 04:27:03AM -0800, Yuri wrote:
While debugging, I find that remove_junk() deletes all directories
from under __cxa_finalize.
Before this, exit(128) is called from recvline_fh (Debug: Remote
helper quit.) And this function in turn is called from under
refs =
I recently came across a repository with a commit containing 100 million
paths in its tree. Cleverly, the whole repo fits into a 1.5K packfile
(can you guess how it was done?). Not so cleverly, running diff-tree
--root on that commit uses a large amount of memory. :)
I do not think it is worth
{
DIRTY_SUBMODULE_UNTRACKED = 1,
DIRTY_SUBMODULE_MODIFIED = 2
} dirty_submodule;
would be more obvious, but it bloats the structure. Limiting
the enum size like:
} dirty_submodule : 2;
might work, but it is not portable.
Signed-off-by: Jeff King p...@peff.net
---
diffcore.h | 2 +-
1
The only mention of this field in the code is by some
debugging code which prints it out (and it will always be
zero, since we never touch it otherwise). It was obsoleted
very early on by 25d5ea4 ([PATCH] Redo rename/copy detection
logic., 2005-05-24).
Signed-off-by: Jeff King p...@peff.net
-off-by: Jeff King p...@peff.net
---
diffcore.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/diffcore.h b/diffcore.h
index 22993e1..d911bf0 100644
--- a/diffcore.h
+++ b/diffcore.h
@@ -45,9 +45,9 @@ struct diff_filespec {
#define DIRTY_SUBMODULE_MODIFIED 2
unsigned
don't see any change
(because the savings end up as padding), but it does leave
room for another free 32-bit value to be added later.
Signed-off-by: Jeff King p...@peff.net
---
I don't typically use bit-sized integers like this for anything but
unsigned integers to be used as flags. My understanding
1 - 100 of 13736 matches
Mail list logo
