Jonathan Nieder jrnie...@gmail.com writes:
The warning about use of 'git add -u' with no pathspec is annoying
because it serves no purpose in this case. So suppress the warning
unless there are changes outside the cwd that are not being added.
No time to review the code now. I thought about
Jeff King p...@peff.net writes:
On Fri, Mar 15, 2013 at 03:42:40PM -0700, Stefan Zager wrote:
We have uncovered a regression in this commit:
b8a2486f1524947f232f657e9f2ebf44e3e7a243
The symptom is that 'git fetch' dies with:
error: index-pack died of signal 10
fatal: index-pack
On Tue, Mar 19, 2013 at 09:17:32AM +0100, Thomas Rast wrote:
but the line in question is:
if (deepest_delta delta_obj-delta_depth)
And in the debugger, both of those variables appear to have sane values
(nor should either impacted by the patch you bisected to). On top of
that,
Jeff King wrote:
On Mon, Mar 18, 2013 at 10:28:59PM +0530, Ramkumar Ramachandra wrote:
Is there a reason for the remote not being optional, or are we just
waiting for a patch? The only problem I can foresee is very minor:
there is a ref with the same name as a remote; in this case, we'd have
On Tue, Mar 19, 2013 at 05:30:34AM -0400, Jeff King wrote:
On Tue, Mar 19, 2013 at 09:17:32AM +0100, Thomas Rast wrote:
but the line in question is:
if (deepest_delta delta_obj-delta_depth)
And in the debugger, both of those variables appear to have sane values
(nor should
On Tue, Mar 19, 2013 at 03:28:12PM +0530, Ramkumar Ramachandra wrote:
I think the ambiguity is a little more complex than that, because we
cannot enumerate the universe of all remotes. Keep in mind that we can
take either a configured remote or a URL (or ssh host). So what does:
git
On Tue, Mar 19, 2013 at 05:59:43AM -0400, Jeff King wrote:
Yes, that has been my experience with valgrind false positives, too. But
if this is a real problem, it may be different from the OP's issue. It
seems to trigger for me in v1.7.10, before Duy's threading patches. It
does not seem
On Tue, Mar 19, 2013 at 06:08:00AM -0400, Jeff King wrote:
@@ -538,6 +539,8 @@ static void resolve_delta(struct object_entry *delta_obj,
delta_obj-real_type = base-obj-real_type;
delta_obj-delta_depth = base-obj-delta_depth + 1;
+ if (deepest_delta delta_obj-delta_depth)
Jeff King p...@peff.net writes:
On Tue, Mar 19, 2013 at 06:08:00AM -0400, Jeff King wrote:
@@ -538,6 +539,8 @@ static void resolve_delta(struct object_entry *delta_obj,
delta_obj-real_type = base-obj-real_type;
delta_obj-delta_depth = base-obj-delta_depth + 1;
+if
On Tue, Mar 19, 2013 at 11:29:36AM +0100, Thomas Rast wrote:
Ah, indeed. Putting:
fprintf(stderr, %lu\n, base-obj-delta_depth);
before the conditional reveals that base-obj-delta_depth is
uninitialized, which is the real problem. I'm sure there is some
perfectly logical
test_config() is already a well-defined function in
test-lib-functions.sh. Don't duplicate it unnecessarily.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
Found this while randomly grep'ping around.
t/t7811-grep-open.sh | 5 -
1 file changed, 5 deletions(-)
diff --git
Jeff King p...@peff.net writes:
On Tue, Mar 19, 2013 at 11:29:36AM +0100, Thomas Rast wrote:
Ah, indeed. Putting:
fprintf(stderr, %lu\n, base-obj-delta_depth);
before the conditional reveals that base-obj-delta_depth is
uninitialized, which is the real problem. I'm sure there is
On Tue, Mar 19, 2013 at 11:45:56AM +0100, Thomas Rast wrote:
Now consider
// somewhere on the stack
struct foo {
char c;
int i;
} a, b;
a.c = a.i = 0;
memcpy(b, a, sizeof(struct foo));
The compiler could legitimately leave the padding between c and i
Am 19.03.2013 06:20, schrieb Duy Nguyen:
On Tue, Mar 19, 2013 at 11:08 AM, Junio C Hamano gits...@pobox.com wrote:
Karsten Blees karsten.bl...@gmail.com writes:
This patch series addresses several bugs and performance issues in
.gitignore processing that came up in the inotify discussion.
On Tue, Mar 19, 2013 at 08:58:23AM +0700, Duy Nguyen wrote:
On Tue, Mar 19, 2013 at 1:26 AM, John Keeping j...@keeping.me.uk wrote:
On Fri, Mar 15, 2013 at 01:06:42PM +0700, Nguyễn Thái Ngọc Duy wrote:
This passes the pathspec, more or less unmodified, to
git-add--interactive. The command
Commit 38a4556 (index-pack: start learning to emulate
verify-pack -v, 2011-06-03) added a delta_depth counter
to each struct object_entry. Initially, all object entries
have their depth set to 0; in resolve_delta, we then set the
depth of each delta to base + 1. Base entries never have
their depth
On Tue, Mar 19, 2013 at 12:08 AM, Jeff King p...@peff.net wrote:
Is there a reason for the remote not being optional, or are we just
waiting for a patch? The only problem I can foresee is very minor:
there is a ref with the same name as a remote; in this case, we'd have
to specify both the
Duy Nguyen wrote:
On Tue, Mar 19, 2013 at 12:08 AM, Jeff King p...@peff.net wrote:
Is there a reason for the remote not being optional, or are we just
waiting for a patch? The only problem I can foresee is very minor:
there is a ref with the same name as a remote; in this case, we'd have
to
Am 19.03.2013 12:33, schrieb Duy Nguyen:
git push . foo:bar
'.' has more like a here semantic, '..' might be a more fitting
mnemonic here.
--
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
On Tue, Mar 19, 2013 at 6:53 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
git push . foo:bar
A URL may be a path to a git repository, and '.' is a valid path.
Currently, 'git push .' seems to push to the current repository (what
does that even mean?). For something truly unambiguous,
On Tue, Mar 19, 2013 at 3:17 PM, Thomas Rast tr...@student.ethz.ch wrote:
but the line in question is:
if (deepest_delta delta_obj-delta_depth)
...
Duy, what was the reasoning why resolve_delta() does not need to hold
locks when it looks when it looks at deepest_delta? My coffee levels
deepest_delta is a global variable but is updated without protection
in resolve_delta(), a multithreaded function. Add a new mutex for it,
but only protect and update when it's actually used (i.e. show_stat is
non-zero).
Another variable that will not be updated is delta_depth in struct
Would it make sense to allow abbreviation similar to how git objects can
be abbreviated? This would mean origin usually could be spelled just o
--
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
On Tue, Mar 19, 2013 at 08:01:15PM +0700, Nguyen Thai Ngoc Duy wrote:
deepest_delta is a global variable but is updated without protection
in resolve_delta(), a multithreaded function. Add a new mutex for it,
but only protect and update when it's actually used (i.e. show_stat is
non-zero).
On Tue, Mar 19, 2013 at 11:42:45AM +0100, Bernhard Posselt wrote:
it seems that the memory corruption does not happen anymore when i change
[apply]
whitespace = fix
to
[apply]
#whitespace = fix
so fixing whitespaces may be the culprit
Thanks, I'm able to reproduce
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
deepest_delta is a global variable but is updated without protection
in resolve_delta(), a multithreaded function. Add a new mutex for it,
but only protect and update when it's actually used (i.e. show_stat is
non-zero).
Another variable that
On Tue, Mar 19, 2013 at 8:50 PM, Thomas Rast tr...@student.ethz.ch wrote:
-- 8 --
Subject: [PATCH] index-pack: guard nr_resolved_deltas reads by lock
The threaded parts of index-pack increment the number of resolved
deltas in nr_resolved_deltas guarded by counter_mutex. However, the
The threaded parts of index-pack increment the number of resolved
deltas in nr_resolved_deltas guarded by counter_mutex. However, the
per-thread outer loop accessed nr_resolved_deltas without any locks.
This is not wrong as such, since it doesn't matter all that much
whether we get an outdated
On 3/19/13, Ramkumar Ramachandra artag...@gmail.com wrote:
I know that this is expected behavior, but is there an easy way to get
rid of this inconsistency?
You can actually rely on rebase to run the appropriate command. In
the first edit commit (the_
no conflict one), I usually run only git
Duy Nguyen pclo...@gmail.com writes:
On Tue, Mar 19, 2013 at 11:08 AM, Junio C Hamano gits...@pobox.com wrote:
Karsten Blees karsten.bl...@gmail.com writes:
This patch series addresses several bugs and performance issues in
.gitignore processing that came up in the inotify discussion.
Hi,
While trying to reproduce/understand the problems[1][2] I was facing
when using Google's Git repo tool[3], I've found minor problems in Git:
1) there's no mention of the git merge tag behavior in git-merge.1
When asking Git to merge a tag (such as a signed tag or annotated tag),
it will
Jonathan Nieder jrnie...@gmail.com writes:
Yes, that can work, for example like this (replacing the patch you're
replying to).
I think that would be a better approach if we were to do this. I
still have the same reservation that this is fundamentally not
worse but still hurts the users more.
Matthieu Moy matthieu@grenoble-inp.fr writes:
No time to review the code now. I thought about implementing something
like that, but did not do it because I didn't want the change in the
code to be too big. At some point, we'll have to remove the warning and
it's easier with my version
Jeff King p...@peff.net writes:
Commit 38a4556 (index-pack: start learning to emulate
verify-pack -v, 2011-06-03) added a delta_depth counter
to each struct object_entry. Initially, all object entries
have their depth set to 0; in resolve_delta, we then set the
depth of each delta to base +
sza...@google.com (Stefan Zager) writes:
We have uncovered a regression in this commit:
b8a2486f1524947f232f657e9f2ebf44e3e7a243
The symptom is that 'git fetch' dies with:
error: index-pack died of signal 10
fatal: index-pack failed
So after that fun detour into threading issues, I have
Duy Nguyen pclo...@gmail.com writes:
Assume that we agree on what remote is implied, we could simplify
parsing by specifying the remote with . (or something short and
unambiguous). So the above command would become
git push . foo:bar
That is an established idiom, a handy way to update your
Holger Hellmuth (IKS) hellm...@ira.uka.de writes:
Am 19.03.2013 12:33, schrieb Duy Nguyen:
git push . foo:bar
'.' has more like a here semantic, '..' might be a more fitting
mnemonic here.
Heh, why not say origin? Or rename it to o if you like in your
own repository ;-)
--
To unsubscribe
On Tue, Mar 19, 2013 at 04:33:42PM +0100, Thomas Rast wrote:
Jeff King p...@peff.net writes:
Commit 38a4556 (index-pack: start learning to emulate
verify-pack -v, 2011-06-03) added a delta_depth counter
to each struct object_entry. Initially, all object entries
have their depth set to
On Mon, Mar 18, 2013 at 2:32 PM, Jeff King p...@peff.net wrote:
By the way, looking at that made me think for a few minutes about
hashcmp, and I was surprised to find that we use an open-coded
comparison loop. That dates back to this thread by Ingo:
Thomas Rast tr...@student.ethz.ch writes:
(gdb) r index-pack --keep --stdin -v --pack_header=2,50757 borked
Starting program: /Users/trast/.local/bin/git index-pack --keep
--stdin -v --pack_header=2,50757 borked
Reading symbols for shared libraries +++ done
On Tue, Mar 19, 2013 at 11:43:53AM -0400, Jeff King wrote:
On Tue, Mar 19, 2013 at 04:33:42PM +0100, Thomas Rast wrote:
Jeff King p...@peff.net writes:
Commit 38a4556 (index-pack: start learning to emulate
verify-pack -v, 2011-06-03) added a delta_depth counter
to each struct
Thomas Rast tr...@student.ethz.ch writes:
The threaded parts of index-pack increment the number of resolved
deltas in nr_resolved_deltas guarded by counter_mutex. However, the
per-thread outer loop accessed nr_resolved_deltas without any locks.
This is not wrong as such, since it doesn't
Jeff King p...@peff.net writes:
and so on. I haven't quite figured out what is going on. It looks like
we call update_pre_post_images with postlen==0, which causes it to just
write the fixed postimage into the existing buffer. But of course the
fixed version is bigger, because we are
Ramkumar Ramachandra artag...@gmail.com writes:
test_config() is already a well-defined function in
test-lib-functions.sh. Don't duplicate it unnecessarily.
There are other instances of it in t7810 and t4018, with slightly
different styles.
t/t4018-diff-funcname.sh:test_config () {
Thomas Rast tr...@student.ethz.ch writes:
Thomas Rast tr...@student.ethz.ch writes:
(gdb) r index-pack --keep --stdin -v --pack_header=2,50757 borked
Starting program: /Users/trast/.local/bin/git index-pack --keep
--stdin -v --pack_header=2,50757 borked
Reading symbols for shared
On Tue, Mar 19, 2013 at 11:52:44AM -0400, Jeff King wrote:
Commit 38a4556 (index-pack: start learning to emulate
verify-pack -v, 2011-06-03) added a delta_depth counter
to each struct object_entry. Initially, all object entries
have their depth set to 0; in resolve_delta, we then
Yann Droneaud ydrone...@opteya.com writes:
1) there's no mention of the git merge tag behavior in git-merge.1
When asking Git to merge a tag (such as a signed tag or annotated tag),
it will always create a merge commit even if fast-forward was possible.
It's like having --no-ff present on
Jeff King p...@peff.net writes:
On Tue, Mar 19, 2013 at 11:52:44AM -0400, Jeff King wrote:
Commit 38a4556 (index-pack: start learning to emulate
verify-pack -v, 2011-06-03) added a delta_depth counter
to each struct object_entry. Initially, all object entries
have their depth
Thomas Rast tr...@student.ethz.ch writes:
It apparently relates to the use of .idx.offset to compute the next
offset, cf. append_obj_to_pack():
struct object_entry *obj = objects[nr_objects++];
...
obj[1].idx.offset = obj[0].idx.offset + n;
obj[1].idx.offset +=
Junio C Hamano gits...@pobox.com writes:
2) git merge tag VS git merge object-id
...
It would be great to have Git using the tag message and check the
signature.
Perhaps, but if you feed the $(git rev-parse v1.12.2) to merge, your
subject will not be able to say Merge tag 'v1.12.2' in the
Prior to v1.8.1.1, if I did this:
git init
echo content foo
mkdir subdir
echo content subdir/bar
echo subdir export-ignore .gitattributes
git add .
git commit -m one
git archive HEAD | tar tf -
my archive would contain only foo and .gitattributes, not subdir. As
of v1.8.1.1,
Thomas Rast tr...@student.ethz.ch writes:
Actually scratch that again. It *is* a stack overflow, except that this
is a thread stack, for which the OS X defaults are 512kB apparently, as
opposed to 2MB on linux.
...
And indeed the following patch fixes it. Sounds like the delta
unpacking
Jonathan Nieder jrnie...@gmail.com writes:
Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
Test nits:
...
Hope that helps,
Jonathan Nieder (3):
push test: use test_config where appropriate
push test: simplify check of push result
push test: rely on -chaining
Jeff King p...@peff.net writes:
Prior to v1.8.1.1, if I did this:
git init
echo content foo
mkdir subdir
echo content subdir/bar
echo subdir export-ignore .gitattributes
git add .
git commit -m one
git archive HEAD | tar tf -
my archive would contain only foo and
On Tue, Mar 19, 2013 at 01:57:56PM -0400, Jeff King wrote:
Prior to v1.8.1.1, if I did this:
git init
echo content foo
mkdir subdir
echo content subdir/bar
echo subdir export-ignore .gitattributes
git add .
git commit -m one
git archive HEAD | tar tf -
my
This seems to break t7300-clean.sh #8
--
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
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
This round fixes the design issue of read_and_strip_branch(), makes
use of jc/reflog-reverse-walk and performs cheaper sha-1 check on
detached commits.
I was running git bisect start pu jch (jch is a branch I do not
push out everywhere that is
Junio C Hamano wrote:
Matthieu Moy matthieu@grenoble-inp.fr writes:
No time to review the code now. I thought about implementing something
like that, but did not do it because I didn't want the change in the
code to be too big. At some point, we'll have to remove the warning and
it's
danny.tho...@blackboard.com wrote on Mon, 18 Mar 2013 09:26 -0400:
Interesting. 'Implementing sitewide pessimistic locking with p4 typemap',
http://www.perforce.com/perforce/doc.current/manuals/p4sag/03_superuser.htm
l seems to suggest this is all that's needed. I believe we're using the
Jonathan Nieder jrnie...@gmail.com writes:
... So I
find myself being trained to ignore the warning.
... Running a full-tree diff which slows down
the code that decides whether to print a warning is a good way to
train people regarding how long to expect a plain git add -u to
take.
Ok,
On Friday 08 February 2013 07:08:14 Torsten Bögershausen wrote:
On 07.02.13 20:35, Junio C Hamano wrote:
Ramsay Jones ram...@ramsay1.demon.co.uk writes:
Torsten Bögershausen wrote:
t0070 and t1301 fail when running the test suite under cygwin.
Skip the failing tests by unsetting
Junio C Hamano wrote:
Incidentally, I am rebuilding the 'next' by kicking many of the
topics back to 'pu' (essentially, only the ones marked as Safe in
the latest issue of What's cooking are kept in 'next'), so perhaps
we can rebuild the jc/add-2.0-u-A-sans-pathspec topic with your
series at
Torsten Bögershausen tbo...@web.de writes:
Use a compile switch IGNORECYGWINFSTRICKS to disable the usage
of cygwin_lstat_fn() only in path.c
The analysis of the problem and the basic idea to disable the
fast-but-lying fstricks in the code that matters may be good, but
the implementation is
Am 18.03.2013 22:20, schrieb Josh Rowe:
On Windows with an NTFS volume with Deduplication enabled, Git
believes that deduplicated files are symlinks. It then fails to be
able to do anything with the file. This can be repro-ed by creating
an NTFS volume with dedup, creating some duplicate
Junio C Hamano gits...@pobox.com writes:
Torsten Bögershausen tbo...@web.de writes:
Use a compile switch IGNORECYGWINFSTRICKS to disable the usage
of cygwin_lstat_fn() only in path.c
The analysis of the problem and the basic idea to disable the
fast-but-lying fstricks in the code that
Yes, Dedup is in fact a Server-only feature. However, there are lots of people
using the Server SKU as development workstations (especially here at Microsoft
g). There are also some sysadmins that I know of who use git and download
sysadmin scripts via git to Servers. Finally, I would hazard
packed_object_info() and packed_delta_info() were mutually recursive.
The former would handle ordinary types and defer deltas to the latter;
the latter would use the former to resolve the delta base.
This arrangement, however, leads to trouble with threaded index-pack
and long delta chains on
As promised, here is a rerolled version of the make pathless 'add
[-u|-A]' warning less noisy, incorporating patches from
jc/add-2.0-u-A-sans-pathspec. Thanks for your help so far.
Just like jc/add-2.0-u-A-sans-pathspec, the only transition in this
series is the pull the bandaid kind. That is,
From: Jeff King p...@peff.net
Date: Thu, 14 Mar 2013 02:44:04 -0400
This behavior is due to change in the future, but let's test
it anyway. That helps make sure we do not accidentally
switch the behavior too soon while we are working in the
area, and it means that we can easily verify the change
Currently warn_pathless_add() is only called directly by cmd_add(),
but that is about to change. Move its definition higher in the file
and pass the --update or --all option name used in its message
through globals instead of function arguments to make it easier to
call without passing values
Make warn_pathless_add() print its warning the first time it is called
and do nothing if called again. This will make it easier to show the
warning on the fly when a relevant condition is detected without
risking showing it multiple times when multiple such conditions hold.
Signed-off-by:
A common workflow in large projects is to chdir into a subdirectory of
interest and only do work there:
cd src
vi foo.c
make test
git add -u
git commit
The upcoming change to 'git add -u' behavior would not affect such a
workflow: when the only changes
In the spirit of the recent similar change for 'git add -u', avoid
pestering users that restrict their attention to a subdirectory and
will not be affected by the coming change in the behavior of pathless
'git add -A'.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
As before.
From: Junio C Hamano gits...@pobox.com
As promised in 0fa2eb530fb7 (add: warn when -u or -A is used without
pathspec, 2013-01-28), in Git 2.0, git add -u/-A that is run
without pathspec in a subdirectory updates all updated paths in the
entire working tree, not just the current directory and its
The subject says it all. I didn't get around to Jonathan's
add-u/-A, Thomas's packed_object_info() work, .gitattributes
regression that made plain pattern not to match directories, or
longstanding apply --whitespace=fix breakage today.
--
To unsubscribe from this list: send the line unsubscribe
On Tue, Mar 19, 2013 at 11:11 PM, Thomas Rast tr...@student.ethz.ch wrote:
Actually scratch that again. It *is* a stack overflow, except that this
is a thread stack, for which the OS X defaults are 512kB apparently, as
opposed to 2MB on linux.
Thanks. I was scratching my head last night
On Wed, Mar 20, 2013 at 1:34 AM, Junio C Hamano gits...@pobox.com wrote:
This seems to break t7300-clean.sh #8
Repeatedly? I saw some t7300-clean.sh failures when running tests in
parallel, but never been able to reproduce it alone.
--
Duy
--
To unsubscribe from this list: send the line
On Tue, Mar 19, 2013 at 03:50:50PM -0700, Jonathan Nieder wrote:
This is the interesting one.
[...]
* summarized Peff's review with an Ack. I hope that's ok.
Yeah, OK with me. I certainly agree with the intent, and I think your
reasoning on the performance change is valid.
I don't see
78 matches
Mail list logo
