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

On Tue, Dec 1, 2015 at 11:22 PM, Junio C Hamano wrote: > As to ${sign}, I was tempted to say an empty string might be > sufficient (i.e. "do not use 40-hex as your branch name"), but it > probably is a bad idea. A single dot "." would be a possibility > (i.e. a ref component

[PATCH v2] Make error message after failing commit_lock_file() less confusing

The error message after a failing commit_lock_file() call sometimes looks like this, causing confusion: $ git remote add remote g...@server.com/repo.git error: could not commit config file .git/config # Huh?! # I didn't want to commit anything, especially not my config file! While in the

Re: Bug: Incorrect stripping of the [PATCH] prefix in git-am

Dear Peff, I have no problem working around this bug/feature. I just happen to think that the current *default* behaviour is not the default behaviour that users have a right to expect: I believe that users have every right to expect `git format-patch`/`git am` to preserve commit messages

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

On Thu, Dec 3, 2015 at 7:15 AM, Max Kirillov wrote: > On Wed, Dec 02, 2015 at 08:13:41PM +0100, Nguyễn Thái Ngọc Duy wrote: >> Let's restart this. From the last discussion [1], we need to make >> core.worktree per-worktree for submodules to work. We also need >>

Re: [PATCH] Make error message after failing commit_lock_file() less confusing

Quoting Eric Sunshine : diff --git a/config.c b/config.c @@ -64,7 +64,8 @@ static void rewrite_credential_file(const char *fn, struct credential *c, print_line(extra); parse_credential_file(fn, c, NULL, print_line); if

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

Use the "last one wins" convention for --recurse-submodules rather than treating conflicting options as an error. Also, fix the declaration of the file-scope recurse_submodules global variable to put it on a separate line. Signed-off-by: Mike Crowe --- builtin/push.c

[PATCH 1/2] push: Fully test --recurse-submodules on command line overrides config

t5531 only checked that the push.recurseSubmodules config option was overridden by passing --recurse-submodules=check on the command line. Add new tests for overriding with --recurse-submodules=no, --no-recurse-submodules and --recurse-submodules=push too. Also correct minor typo in test commit

Re: [PATCH/RFC 05/10] ref-filter: introduce color_atom_parser()

On Wed, Dec 2, 2015 at 4:57 AM, Eric Sunshine wrote: > On Wed, Nov 11, 2015 at 2:44 PM, Karthik Nayak wrote: >> Introduce color_atom_parser() which will parse a "color" atom and >> store its color in the "use_atom" structure for further usage in >

Re: [PATCH] push: Improve --recurse-submodules support

On Wednesday 02 December 2015 at 15:21:13 -0800, Junio C Hamano wrote: > Mike Crowe writes: > > > b33a15b08131514b593015cb3e719faf9db20208 added support for the > > push.recurseSubmodules config option. After it was merged Junio C Hamano > > suggested some improvements: > > > >

Re: Known issues in Git

On Thu, Dec 03, 2015 at 03:14:31PM +, Hamann, Kerstin wrote: > Hi, > > I would like to have a list of known issues for Git (Server and Client) in > order to do the risk analysis for Git and Bitbucket usage for a software > project in the medical device development. Where can I find such a  

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

On Thu, Dec 3, 2015 at 5:10 PM, Torsten Bögershausen wrote: > [snip all good stuff] > > First of all: > Thanks for explaining it so well > > I now can see the point in having this patch. > (Do the commit messages reflect all this ? I need to re-read) Maybe not. I will have a look

Known issues in Git

Hi, I would like to have a list of known issues for Git (Server and Client) in order to do the risk analysis for Git and Bitbucket usage for a software project in the medical device development. Where can I find such a  list? For Bitbucket it is easy (go to jira and open the project). Note:

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

[snip all good stuff] First of all: Thanks for explaining it so well I now can see the point in having this patch. (Do the commit messages reflect all this ? I need to re-read) The other question is: Do you have patch on a public repo ? And, of course, can we add 1 or 2 test cases ? Thanks

Re: [PATCH] document submodule sync --recursive

Stefan Beller writes: > The git-submodule(1) is inconsistent. In the synopsis, it says: > >git submodule [--quiet] sync [--recursive] [--] [...] > > The description of the sync does not mention --recursive, and the > description of --recursive says that it is only

Re: [PATCH] document submodule sync --recursive

On Thu, Dec 3, 2015 at 12:17 PM, Junio C Hamano wrote: >> >> Tested-by: Per Cederqvist > > Isn't this Reported-by? (genuine question; I haven't caught up with > my inbox backlog and do not claim having seen everything Per wrote > to this list). Per wrote he

[PATCH] document submodule sync --recursive

The git-submodule(1) is inconsistent. In the synopsis, it says: git submodule [--quiet] sync [--recursive] [--] [...] The description of the sync does not mention --recursive, and the description of --recursive says that it is only available for foreach, update and status. The option

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

Duy Nguyen writes: > If a variable _must_ be per-worktree or something will break, then it > should belong to the builtin list (so the user is less likely to mess > with it). If it may or may not be per-worktree, depending on one's > preference, then we can keep this in

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

Two functions dereference a tree pointer before checking if the pointer is valid. Fix that by doing the check first. Signed-off-by: Stefan Naewe --- This has been reported through the CppHints newsletter (http://cpphints.com/hints/40) but doesn't seem to have made its

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

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 and that is done by adding the offset of object

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

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 >> list of defaults (which they seem to don't

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

On Thu, Dec 3, 2015 at 1:34 PM, Philip Oakley wrote: > From: "Junio C Hamano" >> >> Stefan Naewe writes: >> >>> Two functions dereference a tree pointer before checking >> >> >> Reading them a bit carefully, a reader would notice

[PATCHv2] document submodule sync --recursive

The git-submodule(1) is inconsistent. In the synopsis, it says: git submodule [--quiet] sync [--recursive] [--] [...] The description of the sync does not mention --recursive, and the description of --recursive says that it is only available for foreach, update and status. The option was

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

On Thu, Dec 03, 2015 at 11:52:43AM -0800, Junio C Hamano wrote: > I actually prefer *not* to have any configurability > to avoid confusion between users. This could be an approach. But because of upgrade issues which I described in the other response it looks like this decision is not easy to

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

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

[PATCH v2] send-email: enable SSL level 1 debug output

If a server's certificate isn't accepted by send-email, the output is: Unable to initialize SMTP properly. Check config and use --smtp-debug. but adding --smtp-debug=1 just produces the same output since we don't get as far as talking SMTP. Turning on SSL debug at level 1 gives:

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

On Tue, Dec 1, 2015 at 2:22 PM, Junio C Hamano wrote: > Junio C Hamano writes: > >> I do not think you would need a new option for this, by the way. >> Just add a new syntax for the LFS of a refspec that cannot possibly >> be confused with existing choices

change to allow cross compile ARM and MIPS

I was trying to build git for MIPS. And found that configure.ac will compile some stuff on the host machine during configure step. So I am not sure how the inventor wants that it work. My solution was to remove the parts with ac_cv_fread_reads_directories and ac_cv_snprintf_returns_bogus from

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

On Thu, Dec 3, 2015 at 9:06 PM, Junio C Hamano wrote: > > 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

Re: [PATCH/RFC 06/10] strbuf: introduce strbuf_split_str_without_term()

On Wed, Dec 2, 2015 at 1:34 PM, Eric Sunshine wrote: > On Wed, Nov 11, 2015 at 2:44 PM, Karthik Nayak wrote: >> The current implementation of 'strbuf_split_buf()' includes the >> terminator at the end of each strbuf post splitting. Include an

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

Commit d95138e [1] fixes a .git file problem by setting GIT_WORK_TREE whenever GIT_DIR is set. It sounded harmless because we handle GIT_DIR and GIT_WORK_TREE side by side for most commands, with two exceptions: git-init and git-clone. "git clone" is not happy with d95138e. This command ignores

[PATCH 1/2] git.c: make it clear save_env() is for alias handling only

Signed-off-by: Nguyễn Thái Ngọc Duy --- git.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/git.c b/git.c index 6ed824c..6ce7043 100644 --- a/git.c +++ b/git.c @@ -25,14 +25,14 @@ static const char *env_names[] = {