On ma, 2016-09-12 at 23:22 -0400, Jeff King wrote:
> The motivation for this series is to fix the regression in v2.9 where
> core.logallrefupdates is sometimes not set properly in a newly
> initialized repository, as described in this thread:
>
> http://public-inbox.org/git/c46d36ef-3c2e-374f-0
On vr, 2016-09-09 at 15:39 -0600, Nathan Williams wrote:
> it ignore doesn't seem to be working properly when adding exceptions.
>8 -- snip testcase
> Expected results
> % git st
> On branch master
> Untracked files:
> (use "git add ..." to include in what will be committed)
>
> foo/ba
On Tue, 13 Sep 2016, Eric Wong wrote:
> What is unclear to me is how only Yaroslav's repository seems to
> trigger this bug after all these years...
Thank you Eric very much for tracking down this issue! Since issue is
intermittent, I guess people just didn't bother going through reporting
if th
Hi everyone,
I'm happy announce that the 19th edition of Git Rev News is now published:
https://git.github.io/rev_news/2016/09/14/edition-19/
Thanks a lot to all the contributors and helpers, especially Brian,
Jakub, Lars and Josh!
Enjoy,
Christian and Thomas.
Signed-off-by: Ramsay Jones
---
Hi Lars,
If you need to re-roll your 'ls/filter-process' branch, could you
please squash this into the relevant patch; commit 2afd9b22
("pkt-line: add packet_write_gently()", 08-09-2016).
[If you think the symbol should be public (I don't), then add a
suitable d
I have spent some time chasing the wild goose (well - the .gitignore
file) after getting:
$> git-submodule add --name fcx-1 ./fcx-1/ ./fcx-1/
The following path is ignored by one of your .gitignore files:
fcx-1
Use -f if you really want to add it.
long story short -- the culprit i
On Wed, Sep 14, 2016 at 12:55:41PM +0200, Dennis Kaarsemaker wrote:
> > [14/16]: config: only read .git/config from configured repos
> > [15/16]: init: expand comments explaining config trickery
> > [16/16]: init: reset cached config when entering new repo
>
> Couldn't find anything to comm
Oleg Taranenko writes:
> Sorry for bothering, why not introduce a brand new option like git
> checkout -b foo --skip-worktree-merge for such rare optimization use
> case?
I am not sure what problem such a new option solves. How would you
describe and explain what "--skip-worktree-merge" option
Mike Ralphson writes:
> Two instances of %ld being used for unsigned longs.
>
> Signed-off-by: Mike Ralphson
> ---
Good eyes. Thanks for spotting.
> vcs-svn/fast_export.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/vcs-svn/fast_export.c b/vcs-svn/fast_export.
On Tue, Sep 13, 2016 at 10:54:47PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > It has been a while since I looked at rfc2822, but aren't the quoting
> > and syntax rules different for addresses versus other headers? We would
> > not want to dequote a Subject header, I think.
>
> You'r
If the function context for a hunk (with -W) reaches the beginning of
the next hunk then we need to merge these two -- otherwise we'd show
some lines twice, which looks strange and even confuses git apply. We
already do this checking and merging in xdl_emit_diff(), but forget to
consider regular c
On Tue, Sep 13, 2016 at 1:14 AM, Lars Schneider
wrote:
>
>> On 12 Sep 2016, at 21:11, Junio C Hamano wrote:
>>
>> [..]
>> properly; supporting "huge objects" better in the object layer,
>> without having to resort to ugly hacks like GitLFS that will never
>> be part of the core Git. [...]
>
> I a
Lars Schneider writes:
> Some applications have test data, image assets, and other data sets that
> need to be versioned along with the source code.
>
> How would you deal with these kind of "huge objects" _today_?
When you know that you'd find the answer to that question totally
uninteresting,
To check whether a submodule needs to be pushed we need to collect all
changed submodules. Lets collect them first and then execute the
possibly expensive test whether certain revisions are already pushed
only once per submodule.
There is further potential for optimization since we can assemble on
Kevin Daudt writes:
> When applied the the author of this patch shows up as:
>
> Author: A U Thor" (test)
>
> So I agree with Jeff[1] where he states that the surrounding quotes
> should be removed, if that's not a problem for git.
>
> [1]:https://public-inbox.org/git/20160914051305.vphknpsi
We are iterating over each pushed ref and want to check whether it
contains changes to submodules. Instead of immediately checking each ref
lets first collect them and then do the check for all of them in one
revision walk.
Signed-off-by: Heiko Voigt
---
Sorry this was not catched earlier. This
From: Hopfauf, Sandee
Sent: Wednesday, September 14, 2016 10:36 AM
Subject: E-mail User:-
Dear E-mail User:-
Take note of this important update that our new web mail has been improved with
a new messaging system from Owa/outlook which also include faster usage o
On Wed, Sep 14, 2016 at 06:40:57AM +, Mike Ralphson wrote:
> Two instances of %ld being used for unsigned longs
Obviously this is an improvement, but I'm kind of surprised that
compiler warnings didn't flag this. I couldn't find a "-W" combination
that noticed, though (at least not with gcc 6
Did you get my message?
On Wed, Sep 14, 2016 at 10:43:18AM -0700, Junio C Hamano wrote:
> I think we can go either way and it does not matter all that much if
> "mailinfo" changes its output or the reader of "mailinfo" output
> changes its input--we will either be munging data read from "From:"
> when producing the "Auth
On Tue, Sep 13, 2016 at 11:15:52AM -0700, Jeff King wrote:
> On Tue, Sep 13, 2016 at 09:52:51AM -0700, Brandon Williams wrote:
>
> > removed function prototypes from pathspec.h which don't have a
> > corresponding implementation.
>
> I'm always curious of the "why" in cases like this. Did we for
Jeff King writes:
> On Wed, Sep 14, 2016 at 10:43:18AM -0700, Junio C Hamano wrote:
>
>> I think we can go either way and it does not matter all that much if
>> "mailinfo" changes its output or the reader of "mailinfo" output
>> changes its input--we will either be munging data read from "From:"
On Wed, Sep 14, 2016 at 12:23 PM, Jeff King wrote:
> On Tue, Sep 13, 2016 at 11:15:52AM -0700, Jeff King wrote:
> I should have done a better job of not just providing the answer, but
> showing how. The easiest tool here is "git log -S":
>
> git log -1 -p -Scheck_path_for_gitlink
>
> (and then
On Wed, Sep 14, 2016 at 7:03 AM, Yaroslav Halchenko wrote:
> I have spent some time chasing the wild goose (well - the .gitignore
> file) after getting:
>
> $> git-submodule add --name fcx-1 ./fcx-1/ ./fcx-1/
> The following path is ignored by one of your .gitignore files:
> fcx-1
>
On Wed, Sep 14, 2016 at 12:30:06PM -0700, Junio C Hamano wrote:
> Another small thing I am not sure about is if the \ quoting can hide
> an embedded newline in the author name. Would we end up turning
>
> From: "Jeff \
> King"
>
> or somesuch into
>
> Author: Jeff
>
On Wed, Sep 14, 2016 at 07:51:30PM +0200, Heiko Voigt wrote:
> Here are some numbers (using the my development clone of git
> itself) from my local machine:
>
> rm -rf && mkdir &&
> (cd && git init) &&
> time git push --mirror
>
>real 0m16.056s
>user 0m24.424s
>sys
On Wed, Sep 14, 2016 at 12:46 PM, Heiko Voigt wrote:
> On Wed, Sep 14, 2016 at 07:51:30PM +0200, Heiko Voigt wrote:
>> Here are some numbers (using the my development clone of git
>> itself) from my local machine:
>>
>> rm -rf && mkdir &&
>> (cd && git init) &&
>> time git push --mirror
>>
>>
On September 14, 2016 3:32:11 PM EDT, Stefan Beller wrote:
!
>I think we could chop off "2>&1" as that would have exposed the
>underlying error.
>
>Another way to go would be to use verbose git-add and grep for
>the string "add '$sm_path'".
>
> if test -z "$force" && ! git add --verbose --dry-
On Tue, Aug 30, 2016 at 01:45:56PM +0200, Thomas Bétous wrote:
> Are you able to reproduce this problem?
No. I just did a clone and an immediate deinit afterwards and no error.
Maybe you can provide a script to reproduce? Which System was this on?
Cheers Heiko
Thanks Junio for the review of my last round.
Changes since then:
[1/4]: patch unchanged
[2/4]: Only adds a test now, and corrects the type of the argument of
chmod_path, but leaves the rest of the patch unchanged.
[3/4]: chmod_index_entry now takes a char as argument which can either
The git add --chmod option was introduced in 4e55ed3 ("add: add
--chmod=+x / --chmod=-x options", 2016-05-31), but was never
documented. Document the feature.
Signed-off-by: Thomas Gummerer
---
Documentation/git-add.txt | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/D
As there are chmod options for both add and update-index, introduce a
new chmod_index_entry function to do the work. Use it in update-index,
while it will be used in add in the next patch.
Signed-off-by: Thomas Gummerer
---
builtin/update-index.c | 16 ++--
cache.h|
Currently there is no test checking the expected behaviour when multiple
chmod flags with different arguments are passed. As argument handling
is not in line with other git commands it's easy to miss and
accidentally change the current behaviour.
While there, fix the argument type of chmod_path,
When the chmod option was added to git add, it was hooked up to the diff
machinery, meaning that it only works when the version in the index
differs from the version on disk.
As the option was supposed to mirror the chmod option in update-index,
which always changes the mode in the index, regardle
Thomas Gummerer writes:
> As there are chmod options for both add and update-index, introduce a
> new chmod_index_entry function to do the work. Use it in update-index,
> while it will be used in add in the next patch.
>
> Signed-off-by: Thomas Gummerer
> ---
> builtin/update-index.c | 16 ++--
Thomas Gummerer writes:
> When the chmod option was added to git add, it was hooked up to the diff
> machinery, meaning that it only works when the version in the index
> differs from the version on disk.
>
> As the option was supposed to mirror the chmod option in update-index,
> which always ch
On Tue, 2016-09-13 at 13:18 -0400, Mike Hawes wrote:
> To whom this may concern,
>
> I found a bug in git while trying to push my website.
> I redid the process and it happened again.
> I also tried it on another computer and it happened again.
> I was wondering how to claim a bug?
Hi Mike,
When
Heiko Voigt writes:
> Sorry about the late reply. I was not able to process emails until now.
> Here are two patches that should help to improve the situation and batch
> up some processing. This one is for repositories with submodules, so
> that they do not iterate over the same submodule twice
I've queued this trivial SQUASH??? on top, which I think should be
squashed into 3/4.
Thanks.
read-cache.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/read-cache.c b/read-cache.c
index 2445e30..c2b2e97 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -779,7 +779,7 @@ int
Junio C Hamano writes:
> I do not mind doing it myself, but I am already in today's
> integration cycle (which will merge a handful of topics to
> 'master'), so I won't get around to it for some time. If you are
> inclined to, please be my guest ;-)
I queued this on top for now; I think it can
On Tue, Sep 13, 2016 at 11:39:56PM +0200, Daniel Hahler wrote:
> I have used "git stash --include-untracked", checked out another branch,
> went back, and "git stash pop"ed the changes.
> Then my system crashed/hung (music that was playing was repeated in a
> loop). I have waited for some minutes
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
You can find the changes described
On Wed, Sep 14, 2016 at 03:57:36PM -0700, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > I do not mind doing it myself, but I am already in today's
> > integration cycle (which will merge a handful of topics to
> > 'master'), so I won't get around to it for some time. If you are
> > inclin
I try a lot of different experiments with git performance, some of them
more hare-brained than others. The ones that succeed end up as real
patches. But I hate for the ones that fail to die a quiet death. Then
nobody learns what _doesn't_ work, and nobody has the opportunity to
point out the spot w
For operations that traverse the whole reachability graph,
like "rev-list --objects", the obj_hash in object.c shows up
as a hotspot. We basically have to do "nr_commits *
size_of_tree" hash lookups, because each tree we look at, we
need to say "have we seen this sha1 yet?" (it's a little
more comp
There's a fancy new compression algorithm called "zstd". The
idea is that it's supposed to get similar compression ratios
to zlib, but with much faster compression and decompression
times. And on top of that, a nice sliding scale to trade off
size versus time on the compression side.
The zstd site
---
I've been trying to think through how we could potentially add pathspec support
for --recurse-submodule options (for builtins like ls-files or grep down the
line). This is something that could be useful if the user supply's a pathspec
that could match to a file in a submodule. We could match
Hi git, I've been seeing git segfault over the past few days. I'm on Mac OS X
10.12, 64-bit, compiling with clang (Apple LLVM version 8.0.0 (clang-800.0.40)).
I first noticed it during a checkout, then also during `log -u`. I'm still
debugging, but wanted to give a heads-up in case anyone else i
On Wed, Sep 14, 2016 at 4:56 PM, Jeff King wrote:
> For operations that traverse the whole reachability graph,
> like "rev-list --objects", the obj_hash in object.c shows up
> as a hotspot. We basically have to do "nr_commits *
> size_of_tree" hash lookups, because each tree we look at, we
> need
On Wed, Sep 14, 2016 at 05:42:29PM -0700, Jonathon Mah wrote:
> Hi git, I've been seeing git segfault over the past few days. I'm on Mac OS X
> 10.12, 64-bit, compiling with clang (Apple LLVM version 8.0.0
> (clang-800.0.40)).
> [...]
> Bisect says:
>
> 8261e1f139db3f8aa6f9fd7d98c876cbeb0f927c
On Wed, Sep 14, 2016 at 05:52:06PM -0700, Stefan Beller wrote:
> > So finding "1011" involves traversing the trie: down the "1"
> > side, then the "0" side, and then check that the rest
> > matches "11".
>
> So we stop building a tree as soon as we hit a unique data
> element (i.e. if we stick to
On Wed, Sep 14, 2016 at 4:58 PM, Jeff King wrote:
> There's a fancy new compression algorithm called "zstd". The
> idea is that it's supposed to get similar compression ratios
> to zlib, but with much faster compression and decompression
> times. And on top of that, a nice sliding scale to trade o
$ time ./git rev-list HEAD --count
44271
print_time_spent_object: measure time needed for resolving hash collisions
This shows that we roughly spent a third of the time in resolving
hash collisions:
I am using linux.git to measure:
$ time git rev-list --objects --count HEAD >/dev/null
print_time
Hello,
I think this is an unintended behavior, but I might be wrong:
Using `git add -N` allows creating of empty commits:
git init test && cd test
echo text > file
git add --intent-to-add file
git commit -m 'Empty commit'
echo $?# prints 0
git log -1 -p --for
On Wed, Sep 14, 2016 at 12:38:20PM -0700, Jeff King wrote:
> On Wed, Sep 14, 2016 at 12:30:06PM -0700, Junio C Hamano wrote:
>
> > Another small thing I am not sure about is if the \ quoting can hide
> > an embedded newline in the author name. Would we end up turning
> >
> > From: "Jeff \
>
On Wed, Sep 14, 2016 at 06:22:17PM -0700, Stefan Beller wrote:
> > Disappointingly, the answer seems to be "no".
>
> After having looked at the data, I disagree with the conclusion.
> And for that I think we need to reason about the frequency
> of the operations happening.
I definitely agree tha
On Wed, Sep 14, 2016 at 07:01:41PM -0700, Stefan Beller wrote:
> According to Jeff, sending patches that don't get accepted is the new hype!
It is what all the cool kids are doing. Unfortunately, it does not save
you from nitpicky reviews...;)
> first = i = hash_obj(sha1, obj_hash_size);
57 matches
Mail list logo