GIT_WORK_TREE not set as expected when changing git repository from a script using a git alias

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"

Re: [PATCH] revision.c: fix possible null pointer access

"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

Re: [PATCH v2] add test to demonstrate that shallow recursive clones fail

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 >>

Re: [PATCH 0/5] Split .git/config in multiple worktree setup

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

Re: best practices against long git rebase times?

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

best practices against long git rebase times?

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

Re: GIT_WORK_TREE not set as expected when changing git repository from a script using a git alias

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

Feature request - allow requesting a lock timeout

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

Re: best practices against long git rebase times?

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

Re: [RFC/PATCH 6/8] config: add core.untrackedCache

> 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

Re: best practices against long git rebase times?

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

Re: best practices against long git rebase times?

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

Re: [PATCH v2] add test to demonstrate that shallow recursive clones fail

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

Re: Multiple fetches when unshallowing a shallow clone

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

Re: [PATCH] Fix quoting of redirect in test script

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

Re: [RFC/PATCH 6/8] config: add core.untrackedCache

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:

Re: [PATCH 2/2] setup.c: re-fix d95138e (setup: set env $GIT_WORK_TREE when ..

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

Re: [PATCH v6] Add git-grep threads param

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

Re: What's cooking in git.git (Dec 2015, #02; Fri, 4)

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

Re: [PATCHv2] document submodule sync --recursive

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

Re: Multiple fetches when unshallowing a shallow clone

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:

Re: Multiple fetches when unshallowing a shallow clone

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"); >

What's cooking in git.git (Dec 2015, #02; Fri, 4)

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

Re: git-credential-cache--daemon quits on SIGHUP, can we change it to ignore instead?

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

Re: Multiple fetches when unshallowing a shallow clone

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

Re: Multiple fetches when unshallowing a shallow clone

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

change to allow cross compile ARM and MIPS‏

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

Re: Multiple fetches when unshallowing a shallow clone

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

Re: Multiple fetches when unshallowing a shallow clone

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

Re: [PATCH] revision.c: fix possible null pointer access

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

Re: git-credential-cache--daemon quits on SIGHUP, can we change it to ignore instead?

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

Re: [PATCH] Fix quoting of redirect in test script

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

Re: [PATCH 2/2] push: Use "last one wins" convention for --recurse-submodules

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

Push --follow tags does not agree with its documentation

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

Re: Multiple fetches when unshallowing a shallow clone

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'

Re: Multiple fetches when unshallowing a shallow clone

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),

Re: [PATCH 01/16] refs: add a backend method structure with transaction functions

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;

Re: [PATCH 13/16] init: allow alternate backends to be set for new repos

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; > @@

Re: [PATCH 15/16] refs: add LMDB refs backend

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: +

Re: What's cooking in git.git (Dec 2015, #02; Fri, 4)

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

Re: [PATCH 15/16] refs: add LMDB refs backend

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

Re: [PATCH 13/16] init: allow alternate backends to be set for new repos

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

Re: Multiple fetches when unshallowing a shallow clone

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

Re: [PATCH 2/2] setup.c: re-fix d95138e (setup: set env $GIT_WORK_TREE when ..

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

Re: [PATCH 1/3] externalize is_git_repository

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

Re: [PATCH 2/3] add is_git_repo (is_git_repository for char*)

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

Re: [PATCH 13/16] init: allow alternate backends to be set for new repos

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

Re: [PATCH/RFC 3/3] ls-files/dir: use is_git_repo to detect submodules

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.

[PATCH] git-check-ref-format.txt: typo, s/avoids/avoid/

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 ---

Re: best practices against long git rebase times?

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

Re: [PATCH 5/5] show-ref: stop using PARSE_OPT_NO_INTERNAL_HELP

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

Re: git-credential-cache--daemon quits on SIGHUP, can we change it to ignore instead?

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()

Re: git-credential-cache--daemon quits on SIGHUP, can we change it to ignore instead?

On Fri, Dec 04, 2015 at 10:55:32AM -0800, Junio C Hamano wrote: > >> + int ignore_sighup = 0; > >> + git_config_get_bool("credentialcache.ignoresighup", _sighup); > >> + > > > > Style-wise, I think the declaration should go above the options-list. > > I was about to merge this to 'master',