On Sat, Dec 05, 2015 at 07:30:13AM +0100, Duy Nguyen wrote:
> On Thu, Dec 3, 2015 at 1:35 AM, David Turner wrote:
> > git init learns a new argument --refs-backend-type. Presently, only
> > "files" is supported, but later we will add other backends.
> >
> > When this argument is used, the reposi
On Fri, Dec 04, 2015 at 07:15:17PM +0100, Andreas Krey wrote:
> Using resolve_gitlink_ref to check for submodules
> creates submodule list entries even when it isn't
> one, and causes O(n^2) runtime behaviour in repos
> with many untracked directories.
>
> Use is_git_repo instead for detection.
>
On Fri, Dec 04, 2015 at 07:15:16PM +0100, Andreas Krey wrote:
> diff --git a/cache.h b/cache.h
> index 6626e97..42ab0c3 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -440,6 +440,7 @@ extern const char *get_git_dir(void);
> extern const char *get_git_common_dir(void);
> extern int is_git_directory(
On Fri, Dec 04, 2015 at 07:15:15PM +0100, Andreas Krey wrote:
> diff --git a/cache.h b/cache.h
> index 736abc0..6626e97 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -439,6 +439,7 @@ extern int is_inside_work_tree(void);
> extern const char *get_git_dir(void);
> extern const char *get_git_common_d
On Thu, Dec 3, 2015 at 1:35 AM, David Turner wrote:
> git init learns a new argument --refs-backend-type. Presently, only
> "files" is supported, but later we will add other backends.
>
> When this argument is used, the repository's core.refsBackendType
> configuration value is set, and the refs
On Fri, Dec 4, 2015 at 9:35 PM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> ... Now I conclude
>> that setup-messed-by-alias is always evil. So the env restoration is
>> done for _all_ commands whenever aliases are involved.
>
> So a side effect of this is whenever an alias is inv
On Fri, Dec 4, 2015 at 11:45 PM, Junio C Hamano wrote:
> Jeff King writes:
>
>>> But why would fetching a tag (or set of tags) merit a depth of zero?
>>> Doesn't depth 1 mean "give me the the objects, and none of their
>>> descendants"? Why use 0?
>>
>> That comes from this line:
>>
>> transpo
On Fri, 2015-12-04 at 16:08 -0800, Junio C Hamano wrote:
> David Turner writes:
>
> > + while (!mdb_ret) {
> > + if (starts_with(key.mv_data, refname) &&
> > + ((char*)key.mv_data)[refname_len - 2] == '/') {
>
> ERROR: "(foo*)" should be "(foo *)"
> #877: FILE: refs/lmd
Jeff King writes:
> You may want to update this in the whats-cooking template. :)
X-<. This is a bit tricky in that most of the time I want to retain
the customization I made to the top-portion, and this part does not
go through a three-way merge as it probably should.
>
> diff --git a/whats-c
David Turner writes:
> + while (!mdb_ret) {
> + if (starts_with(key.mv_data, refname) &&
> + ((char*)key.mv_data)[refname_len - 2] == '/') {
ERROR: "(foo*)" should be "(foo *)"
#877: FILE: refs/lmdb-backend.c:514:
+ ((char*)key.mv_data)[refname_l
David Turner writes:
> diff --git a/setup.c b/setup.c
> index d343725..de6b8ac 100644
> --- a/setup.c
> +++ b/setup.c
> @@ -1,5 +1,6 @@
> #include "cache.h"
> #include "dir.h"
> +#include "refs.h"
> #include "string-list.h"
>
> static int inside_git_dir = -1;
> @@ -263,6 +264,15 @@ int get_
David Turner writes:
> diff --git a/refs.c b/refs.c
> index 0f7628d..babba8a 100644
> --- a/refs.c
> +++ b/refs.c
> @@ -10,6 +10,31 @@
> #include "tag.h"
>
> /*
> + * We always have a files backend and it is the default.
> + */
> +extern struct ref_be refs_be_files;
It is customary to s/exte
On Fri, Dec 04, 2015 at 07:39:10AM -0800, Junio C Hamano wrote:
> > But you can't do that computation (in the error case under
> > consideration). Null can't be added to anything (as far as the
> > implications of the standards go). These are horrid gotchas because
> > they go against the grain of
On Fri, Dec 04, 2015 at 12:05:52PM -0800, Junio C Hamano wrote:
> > This probably _does_ trigger setup_git_env() when it was not otherwise
> > called, and it will back to looking at ".git/config" for the repo-level
> > config. That may fail to find the file if we are in a bare repository,
> > or a
On Fri, Dec 04, 2015 at 03:15:58PM -0800, Junio C Hamano wrote:
> You can find the normal integration branches at:
>
> https://github.com/git/git/
>
> and all topic branches at:
>
> https://github.com/peff/git/
>
> But note that I will _not_ be pushing to kernel.org.
You may want to u
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
A big thank-you to Peff for managing the list traffic during my
absence for the past few weeks. I think my tree is now back in
shape and I star
I have add an description into INSTALL, that other user have direct an
indicator.
diff --git a/INSTALL b/INSTALL
index ffb071e..5918182 100644
--- a/INSTALL
+++ b/INSTALL
@@ -2,13 +2,13 @@
Git installation
Normally you can just do "make" followed by "make install", and that
-will insta
Jeff King writes:
>> But why would fetching a tag (or set of tags) merit a depth of zero?
>> Doesn't depth 1 mean "give me the the objects, and none of their
>> descendants"? Why use 0?
>
> That comes from this line:
>
> transport_set_option(transport, TRANS_OPT_DEPTH, "0");
>
> That line blam
On Fri, Dec 04, 2015 at 01:57:30PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > This seems to reproduce consistently for me:
> >
> > $ git clone --depth=1 git://github.com/git/git
> > Cloning into 'git'...
> > remote: Counting objects: 2925, done.
> > remote: Compressing object
Jeff King writes:
> This seems to reproduce consistently for me:
>
> $ git clone --depth=1 git://github.com/git/git
> Cloning into 'git'...
> remote: Counting objects: 2925, done.
> remote: Compressing objects: 100% (2602/2602), done.
> remote: Total 2925 (delta 230), reused 2329 (delta
On Fri, Dec 04, 2015 at 04:38:16PM -0500, Jason Paller-Rzepka wrote:
> It appears that it happens when the shallow history grows to include a
> commit that's pointed to by a previously unseen tag. For example,
> when I deepen a checkout of git to depth 8, I hit v2.5.2, and a second
> fetch takes
I can reproduce it now. Instead of using my $random version, I just
needed origin/master
to reproduce.
The second fetch is invoked via
(as outputted via GIT_TRACE=1 git -C git fetch --depth=8)
13:44:56.863841 run-command.c:343 trace: run_command:
'fetch-pack' '--stateless-rpc' '--stdin' '--
On Fri, Dec 04, 2015 at 01:05:20PM -0800, Junio C Hamano wrote:
> Do you want to sign-off this patch?
>
> Thanks.
Oops, yes please.
Signed-off-by: Charles Bailey
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordom
When deleting an annotated tag with git push -d while having
push.follwTags set to true, causes push to push other annotated tags. I
was surprised by this as this does not agree with the documentation
Push all the refs that would be pushed without this option, and
also push annotat
It appears that it happens when the shallow history grows to include a
commit that's pointed to by a previously unseen tag. For example,
when I deepen a checkout of git to depth 8, I hit v2.5.2, and a second
fetch takes place.
```
$ git clone --depth=1 http://github.com/git/git
Cloning into 'git'
On Fri, Dec 4, 2015 at 1:27 PM, Jeff King wrote:
>>
>> and could not see a second fetch, but only a
>> fetch-pack with --depth=2147483647
>
> This seems to reproduce consistently for me:
>
> $ git clone --depth=1 git://github.com/git/git
I used the http protocol, so I guess that's the differenc
On Fri, Dec 04, 2015 at 12:46:59PM -0800, Stefan Beller wrote:
> On Mon, Nov 30, 2015 at 11:35 AM, Jason Paller-Rzepka
> wrote:
> > Hi all,
> >
> > Would anyone be willing to help me understand some shallow-clone
> > behavior? (I found a bug in Dulwich, and I'm looking for some context
> > so I
Thanks, will queue.
--
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
Do you want to sign-off this patch?
Thanks.
--
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
Thanks, will queue.
--
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 Mon, Nov 30, 2015 at 11:35 AM, Jason Paller-Rzepka
wrote:
> Hi all,
>
> Would anyone be willing to help me understand some shallow-clone
> behavior? (I found a bug in Dulwich, and I'm looking for some context
> so I can determine how to fix it.)
>
> I learned that cgit sometimes performs two f
Nguyễn Thái Ngọc Duy writes:
> ... Now I conclude
> that setup-messed-by-alias is always evil. So the env restoration is
> done for _all_ commands whenever aliases are involved.
So a side effect of this is whenever an alias is involved, all
commands are re-spawned, not just the external ones b
This version seems to break t7811 when applied on top of 37023ba3
(Seventh batch for 2.7, 2015-10-26).
I'll eject it from 'pu' for today's integration.
--
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 h
Jeff King writes:
> On Fri, Dec 04, 2015 at 10:55:32AM -0800, Junio C Hamano wrote:
>>
>> I was puzzled that git_config_get_bool() is used here without even
>> checking if we are inside any Git repository and wondered if it was
>> correct
>
> This probably _does_ trigger setup_git_env() when
On Fri, Dec 4, 2015 at 6:54 PM, Torsten Bögershausen wrote:
>> Current state of affairs:
>>
>> * Enable on a per-repo basis: git update-index --untracked-cache
>> * Disable on a per-repo basis: git update-index --no-cache
>> * Enable system-wide: N/A
>> * Disable system-wide: N/A
>>
>> With th
On Fri, Dec 04, 2015 at 10:55:32AM -0800, Junio C Hamano wrote:
> >> + int ignore_sighup = 0;
> >> + git_config_get_bool("credentialcache.ignoresighup", &ignore_sighup);
> >> +
> >
> > Style-wise, I think the declaration should go above the options-list.
>
> I was about to merge this to 'master
Jeff King writes:
>> diff --git a/credential-cache--daemon.c b/credential-cache--daemon.c
>> index eef6fce..6cda9c0 100644
>> --- a/credential-cache--daemon.c
>> +++ b/credential-cache--daemon.c
>> @@ -256,6 +256,9 @@ int main(int argc, const char **argv)
>> OPT_END()
>> };
>>
René Scharfe writes:
> The flag PARSE_OPT_NO_INTERNAL_HELP is set to allow overriding the
> option -h, except when it's the only one given.
> This is the default behavior now,...
OK, so in the old world order, "-h" used to trigger the internal
help even before consulting parse_short_opt() to see
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/git-check-ref-format.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/git-check-ref-format.txt
b/Documentation/git-check-ref-format.txt
index 9044dfa..91a3622 100644
--- a/Documentation/git-check-ref-forma
On Fri, Dec 4, 2015 at 9:33 AM, demerphq wrote:
> In all fairness however, I do believe that some of the recent changes
> to git helped, but I dont how much or which. What I do know is we
> still have the cron sweeper process cleaning refs. (It broke one of my
> repos that I set up with --referenc
> Current state of affairs:
>
> * Enable on a per-repo basis: git update-index --untracked-cache
> * Disable on a per-repo basis: git update-index --no-cache
> * Enable system-wide: N/A
> * Disable system-wide: N/A
>
> With this patch:
>
> * Enable on a per-repo basis: git update-index --un
On 4 December 2015 at 18:28, John Keeping wrote:
> On Fri, Dec 04, 2015 at 06:09:33PM +0100, demerphq wrote:
>> On 4 December 2015 at 16:05, Andreas Krey wrote:
>> > Hi all,
>> >
>> > our workflow is pretty rebase-free for diverse reasons yet.
>> >
>> > One obstacle now appearing is that rebases
On Fri, Dec 04, 2015 at 06:09:33PM +0100, demerphq wrote:
> On 4 December 2015 at 16:05, Andreas Krey wrote:
> > Hi all,
> >
> > our workflow is pretty rebase-free for diverse reasons yet.
> >
> > One obstacle now appearing is that rebases simply take
> > very long - once you might want to do a re
On 4 December 2015 at 16:05, Andreas Krey wrote:
> Hi all,
>
> our workflow is pretty rebase-free for diverse reasons yet.
>
> One obstacle now appearing is that rebases simply take
> very long - once you might want to do a rebase there are
> several hundred commits on the remote branch, and our t
Stefan Beller writes:
> Did you have any reason to pick . specifically or are we welcome to bikeshed
> why a colon might be better? (or ":", "?", "[", "\", "^", "~", SP, or TAB)
>
> We could use [id]c78f7b5ed9dc1c6edc8db06ac65860151d54fd07
> or [const]c78f7b5ed9dc1c6edc8db06ac65860151d54fd07 ?
A
On Thu, Dec 3, 2015 at 9:53 PM, Max Kirillov wrote:
> On Thu, Dec 03, 2015 at 09:07:07AM +0100, Duy Nguyen wrote:
>> On Thu, Dec 3, 2015 at 7:15 AM, Max Kirillov wrote:
>>> Using builtin defaults might be confusing for users -
>>> editing the info/config.worktree they must keep in mind the
>>> li
Stefan Beller writes:
>> A single dot "." would be a possibility
>> (i.e. a ref component cannot begin with a dot), but squating on it
>> and saying "anything that begins with . must be followed by 40-hex
>> (and in the future by an extended SHA-1)" would rob extensibility
>> from us, so perhaps
"Philip Oakley" writes:
> From: "Junio C Hamano"
>> Stefan Naewe writes:
>>
>>> Two functions dereference a tree pointer before checking
>>
>> Reading them a bit carefully, a reader would notice that they
>> actually do not dereference the pointer at all. It just computes
>> another pointer an
On Fri, Dec 04, 2015 at 04:05:46PM +0100, Andreas Krey wrote:
> our workflow is pretty rebase-free for diverse reasons yet.
>
> One obstacle now appearing is that rebases simply take
> very long - once you might want to do a rebase there are
> several hundred commits on the remote branch, and our
Hi all,
our workflow is pretty rebase-free for diverse reasons yet.
One obstacle now appearing is that rebases simply take
very long - once you might want to do a rebase there are
several hundred commits on the remote branch, and our tree
isn't small either.
This produces rebase times in the min
On Fri, Dec 4, 2015 at 10:54 AM, Gabriel Ganne wrote:
> Hi,
>
> Following commit d95138e695d99d32dcad528a2a7974f434c51e79 (since
> v2.5.1) the following workflow I use seems broken :
You are not the first one bitten [1] by that commit. A fix is being
worked on [2]. Sorry for the trouble.
[1] htt
It appears that almost all of the locking calls in the current code use hold_lock_file_for_update() which translates
into a request with zero timeout.
This effectively means that for certain classes of usage, you can't use git concurrently without either external locking
or retry logic. It woul
Hi,
Following commit d95138e695d99d32dcad528a2a7974f434c51e79 (since
v2.5.1) the following workflow I use seems broken :
I wrote a script to list all git repositories that can be found from
where I am, and then call for each repository a given command.
Given the following tree, where "a" & "b" a
53 matches
Mail list logo