While investigating this StackOverflow question:
http://stackoverflow.com/questions/15516168/how-to-cross-compile-git-for-arm
I found that fetch-pack.c uses ST_MTIME_NSEC outside of the protection
of #ifdef USE_NSEC. This results in a broken build if
!defined(USE_NSEC) && !defined(NO_NSEC) and the
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 an
On Wed, Mar 20, 2013 at 1:34 AM, Junio C Hamano 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 "unsubscribe git" in
the
On Tue, Mar 19, 2013 at 11:11 PM, Thomas Rast 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 wondering if there was
u
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 g
From: Junio C Hamano
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
subdirectories.
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
---
As before.
builtin/add.c | 21 +++
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 pres
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: Jonatha
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
From: Jeff King
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 when
we do mak
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 i
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 plat
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
). There are also some sysadmins that I know of who use git and download
sysadmin scripts via git to Servers. Finally, I would hazard a
Junio C Hamano writes:
> Torsten Bögershausen 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
>
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
Torsten Bögershausen 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 questionable.
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
> s
On Friday 08 February 2013 07:08:14 Torsten Bögershausen wrote:
> On 07.02.13 20:35, Junio C Hamano wrote:
> > Ramsay Jones writes:
> >
> >> Torsten Bögershausen wrote:
> >>> t0070 and t1301 fail when running the test suite under cygwin.
> >>> Skip the failing tests by unsetting POSIXPERM.
> >> t1
Jonathan Nieder 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, fair enough.
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
> de
Junio C Hamano wrote:
> Matthieu Moy 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
Nguyễn Thái Ngọc Duy 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 somewhere in t
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
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
Jeff King 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
Jonathan Nieder writes:
> Junio C Hamano wrote:
>> Jonathan Nieder 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 instead of
Thomas Rast 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 needs a rewrite t
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 subdi
Junio C Hamano writes:
>> 2) git merge VS git merge
>> ...
>> 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 first
> place, so
Thomas Rast 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 += write_compressed(f,
Jeff King 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
Yann Droneaud writes:
> 1) there's no mention of the git merge 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 the command line.
>
>
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 re
Thomas Rast writes:
> Thomas Rast writes:
>
>> (gdb) r index-pack --keep --stdin -v --pack_header=2,50757 > Starting program: /Users/trast/.local/bin/git index-pack --keep
>> --stdin -v --pack_header=2,50757 > Reading symbols for shared libraries +++ done
>> Recei
Ramkumar Ramachandra 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 () {
t/t7810-grep.sh:test_confi
Jeff King 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 expanding the tabs
On Tue, Mar 19, 2013 at 9:48 PM, Junio C Hamano wrote:
> Would we we better off kicking nd/read-directory-recursive-optim
> back to 'pu' (and eventually ejecting it) and replacing it with a
> reroll of Karsten's series when it comes, perhaps?
I have no problem with that. Whatever better should ge
On Tue, Mar 19, 2013 at 10:43:40PM +0700, Nguyen Thai Ngoc Duy wrote:
> > I could not replicate his benchmarks at all. In fact, my measurements
> > showed a slight slowdown with 1a812f3 (hashcmp(): inline memcmp() by
> > hand to optimize, 2011-04-28).
> [...]
>
> What gcc and glibc versions are y
Thomas Rast 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 matter all that muc
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 writes:
> >
> > > Commit 38a4556 (index-pack: start learning to emulate
> > > "verify-pack -v", 2011-06-03) added a "delta_depth" counter
> > > to each "stru
Thomas Rast writes:
> (gdb) r index-pack --keep --stdin -v --pack_header=2,50757Starting program: /Users/trast/.local/bin/git index-pack --keep
> --stdin -v --pack_header=2,50757Reading symbols for shared libraries +++ done
> Receiving objects: 100% (50757/5075
On Mon, Mar 18, 2013 at 2:32 PM, Jeff King 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:
>
> http://article.gmane.org/gmane.comp.version-contro
"Holger Hellmuth (IKS)" 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 from t
On Tue, Mar 19, 2013 at 04:33:42PM +0100, Thomas Rast wrote:
> Jeff King 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 t
Duy Nguyen 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 own bar
bra
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,
Jeff King 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 + 1"
Matthieu Moy 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 than with yours. But the "da
Jonathan Nieder 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".
> +
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 behavior in git-merge.1
When asking Git to merge a tag (such as a signed tag or annotated tag),
it will always
Duy Nguyen writes:
> On Tue, Mar 19, 2013 at 11:08 AM, Junio C Hamano wrote:
>> Karsten Blees writes:
>>
>>> This patch series addresses several bugs and performance issues in
>>> .gitignore processing that came up in the inotify discussion.
>>
>> Thanks.
>>
>> How does this interact with the n
On 3/19/13, Ramkumar Ramachandra 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 add" to add my c
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 va
On Tue, Mar 19, 2013 at 8:50 PM, Thomas Rast 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
> per-thread outer loop
Nguyễn Thái Ngọc Duy 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 will not be u
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
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).
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 http://
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
object_en
On Tue, Mar 19, 2013 at 3:17 PM, Thomas Rast 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
> aren't
On Tue, Mar 19, 2013 at 6:53 PM, Ramkumar Ramachandra
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, we'll 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 http:
Duy Nguyen wrote:
> On Tue, Mar 19, 2013 at 12:08 AM, Jeff King 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 s
On Tue, Mar 19, 2013 at 12:08 AM, Jeff King 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 remote a
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
thei
On Tue, Mar 19, 2013 at 08:58:23AM +0700, Duy Nguyen wrote:
> On Tue, Mar 19, 2013 at 1:26 AM, John Keeping 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 itself does
Am 19.03.2013 06:20, schrieb Duy Nguyen:
> On Tue, Mar 19, 2013 at 11:08 AM, Junio C Hamano wrote:
>> Karsten Blees writes:
>>
>>> This patch series addresses several bugs and performance issues in
>>> .gitignore processing that came up in the inotify discussion.
>>
>> Thanks.
>>
>> How does this
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
Jeff King 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 sur
Ok, sorrry for not responsding for quite a while, we had the 5.0 release and
had too much to do.
I found out why it segfaults: I had a .gitconfig file (sry must have somehow
missed that no idea why actually) with the following contents:
http://dpaste.com/1027662/
it seems that the memory corr
test_config() is already a well-defined function in
test-lib-functions.sh. Don't duplicate it unnecessarily.
Signed-off-by: Ramkumar Ramachandra
---
Found this while randomly grep'ping around.
t/t7811-grep-open.sh | 5 -
1 file changed, 5 deletions(-)
diff --git a/t/t7811-grep-open.sh b/
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
Jeff King 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 (deep
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->de
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
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:
> >
>
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 val
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
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
Jeff King 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 f
81 matches
Mail list logo
