Re: [PATCH] packfile: Correct zlib buffer handling

On Sun, May 27, 2018 at 1:57 AM, Junio C Hamano wrote: > Duy Nguyen writes: > >> On Sat, May 26, 2018 at 12:56 AM, Jeremy Linton >> wrote: >>> @@ -1416,7 +1416,7 @@ static void *unpack_compressed_entry(struct >>> packed_git *p,

Re: [PATCH] t990X: use '.git/objects' as 'deep inside .git' path

On Sat, May 26, 2018 at 8:47 AM, Christian Couder wrote: > Tests t9902-completion.sh and t9903-bash-prompt.sh each have tests > that check what happens when we are "in the '.git' directory" and > when we are "deep inside the '.git' directory". > > To test the case when

Re: 2.17.0 Regression When Adding Patches Without Whitespace In Initial Column

Todd, it looks like that may very well be the same issue. And it looks like it's planning on being fixed in the next release? Would that be 2.17.1 since it's a regression? > On 2018 May 26, at 16:07, Todd Zullinger wrote: > > Hi Jeff, > > Jeff Felchner wrote: >> Ever since

Re: [RFC] git gc "--prune=now" semantics considered harmful

On Sat, May 26, 2018 at 4:31 PM Junio C Hamano wrote: > *That* is something I don't do. After all, I am fully aware that I > have started end-of-day ritual by that time, so I won't even look at > a new patch (or a pull request for that matter). Sounds like you're more

Re: [PATCH 2/5] t6036, t6042: use test_line_count instead of wc -l

Elijah Newren writes: >> I'd expect that a reader of the commit who cares enough to bother to >> wonder by looking at the patch and seeing that 2 became 3 would know >> why already. And a reader of the resulting file would not know that >> the 3 used to be 2, and won't be

Re: [PATCH] packfile: Correct zlib buffer handling

Duy Nguyen writes: > On Sat, May 26, 2018 at 12:56 AM, Jeremy Linton > wrote: >> @@ -1416,7 +1416,7 @@ static void *unpack_compressed_entry(struct packed_git >> *p, >> return NULL; >> memset(, 0, sizeof(stream)); >>

Re: [RFC] git gc "--prune=now" semantics considered harmful

Linus Torvalds writes: > Soes my use pattern of "git gc --prune=now" make sense? Maybe not. But > it's what I've gotten used to, and it's at least not entirely insane. FWIW, my end-of-day ritual is to do repack -a -d -f with a large window and a small depth,

[RFC] git gc "--prune=now" semantics considered harmful

So this is a RFC patch, I'm not sure how much people really care, but I find the current behavior of "git gc --prune=now" to be unnecessarily dangerous. There's two issues with it: (a) parse_expiry_date() considers "now" to be special, and it actually doesn't mean "now" at all, it means

From: Mr James Tan (Urgent & Confidential)

-- -- (From: Mr.James Tan (Urgent & Confidential) Good Day, Please Read. My name is Mr.James Tan , I am the Bill and Exchange manager here in Bank of Africa (BOA) Lome-Togo.West-Africa. I have a business proposal in the tune of $9.7m, (Nine Million Seven Hundred Thousand Dollars Only) after

Re: 2.17.0 Regression When Adding Patches Without Whitespace In Initial Column

Hi Jeff, Jeff Felchner wrote: > Ever since 2.17.0, when saving a patch (using add --patch > but probably other ways as well), if the whitespace is > removed from the initial column, the patch doesn't apply. This sounds a bit like the issue discussed in this thread a few weeks ago:

2.17.0 Regression When Adding Patches Without Whitespace In Initial Column

Ever since 2.17.0, when saving a patch (using add --patch but probably other ways as well), if the whitespace is removed from the initial column, the patch doesn't apply. Full walkthrough (including comparison with 2.16.3) in the video attached to this link:

Re: [PATCH v3 02/20] commit-graph: fix GRAPH_MIN_SIZE

On Sat, May 26, 2018 at 08:46:09PM +0200, Jakub Narebski wrote: > One issue: in the future when Git moves to NewHash, it could encounter > then both commit-graph files using SHA-1 and using NewHash. What about > GRPH_OID_LEN then: for one of those it would be incorrect. Unless it is > about

Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

On Friday 25 May 2018 08:10 AM, Jeff King wrote: > Subject: [PATCH] branch: customize "-l" warning in list mode > > People mistakenly use "git branch -l", thinking that it > triggers list mode. It doesn't, but the lack of non-option > arguments in that command does (and the "-l" becomes a >

Re: [PATCH v3 02/20] commit-graph: fix GRAPH_MIN_SIZE

Derrick Stolee writes: > The GRAPH_MIN_SIZE macro should be the smallest size of a parsable > commit-graph file. However, the minimum number of chunks was wrong. > It is possible to write a commit-graph file with zero commits, and > that violates this macro's value. > >

Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

On Friday 25 May 2018 01:01 AM, Jeff King wrote: > On Thu, May 24, 2018 at 03:22:14PM -0400, Jeff King wrote: > > Hmm, actually, I suppose the true value of the warning is to help people > doing "git branch -l foo", and it would still work there. The "more > extreme" from your suggested patch

Re: RFC: New reference iteration paradigm

Jeff King writes: > On Thu, Mar 31, 2016 at 11:01:44AM -0700, Junio C Hamano wrote: >> Michael Haggerty writes: >> >>> the backend now has to implement >>> struct ref_iterator *ref_iterator_begin_fn(const char *submodule,

[GSoC] GSoC with git, week 4

Hi, I published my blog post about this week. You can read it here: https://blog.pa1ch.fr/posts/2018/05/26/en/gsoc2018-week-4.html All comments are welcome! Cheers, Alban

Proposal

Hello Greetings to you please i have a business proposal for you contact me for more detailes asap thanks. Best Regards, Miss.Zeliha ömer faruk Esentepe Mahallesi Büyükdere Caddesi Kristal Kule Binasi No:215 Sisli - Istanbul, Turkey

[PATCH v2 05/11] fsck: produce camelCase config key names

Signed-off-by: Nguyễn Thái Ngọc Duy --- fsck.c | 22 ++ 1 file changed, 18 insertions(+), 4 deletions(-) diff --git a/fsck.c b/fsck.c index b65ff2d856..ff1547d3c7 100644 --- a/fsck.c +++ b/fsck.c @@ -74,14 +74,15 @@ enum fsck_msg_id { #undef MSG_ID

[PATCH v2 11/11] log-tree: allow to customize 'grafted' color

Commit 76f5df305b (log: decorate grafted commits with "grafted" - 2011-08-18) lets us decorate grafted commits but I forgot about the color.decorate.* config. Signed-off-by: Nguyễn Thái Ngọc Duy --- Documentation/config.txt | 3 ++- log-tree.c | 1 + 2 files

[PATCH v2 10/11] completion: support case-insensitive config vars

Config variables are case-insensitive but this case/esac construct is case-sensitive by default. For bash v4, it'll be easy. For platforms that are stuck with older versions, we need an external command, but that is not that critical. And where this additional overhead matters the most is Windows,

[PATCH v2 03/11] fsck: factor out msg_id_info[] lazy initialization code

This array will be used by some other function than parse_msg_id() in the following commit. Factor out this prep code so it could be called from that one. Signed-off-by: Nguyễn Thái Ngọc Duy --- fsck.c | 40 1 file changed, 24

[PATCH v2 08/11] completion: drop the hard coded list of config vars

The new help option --config-for-completion is a machine friendlier version of --config where all the placeholders and wildcards are dropped, leaving only the good, completable prefixes for git-completion.bash to consume. Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/help.c

[PATCH v2 02/11] grep: keep all colors in an array

This is more inline with how we handle color slots in other code. It also allows us to get the list of configurable color slots later. Signed-off-by: Nguyễn Thái Ngọc Duy --- grep.c | 106 ++--- grep.h | 21 +++- 2

[PATCH v2 06/11] advice: keep config name in camelCase in advice_config[]

For parsing, we don't really need this because the main config parser will lowercase everything so we can do exact matching. But this array now is also used for printing in `git help --config`. Keep camelCase so we have a nice printout. Signed-off-by: Nguyễn Thái Ngọc Duy ---

[PATCH v2 04/11] help: add --config to list all available config

Sometimes it helps to list all available config vars so the user can search for something they want. The config man page can also be used but it's harder to search if you want to focus on the variable name, for example. This is not the best way to collect the available config since it's not

[PATCH v2 07/11] am: move advice.amWorkDir parsing back to advice.c

The only benefit from this move (apart from cleaner code) is that advice.amWorkDir should now show up in `git help --config`. There should be no regression since advice config is always read by the git_default_config(). While at there, use advise() like other code. We now get "hint: " prefix and

[PATCH v2 09/11] completion: keep other config var completion in camelCase

The last patch makes "git config " shows camelCase names because that's what's in the source: config.txt. There are still a couple manual var completion in this code. Let's make them follow the naming convention as well. In theory we could automate this part too because we have the information.

[PATCH v2 00/11] completion: avoid hard coding config var list

v2 changes: - based on 'next' - C99 is now mentioned in the commit message - fixed Eric's comments - the old 8/9 partial case-insensitive support patch is replaced with Szeder's version. Szeder I claimed authorship because I wrote the commit message which may not be what you like. If you

[PATCH v2 01/11] Add and use generic name->id mapping code for color slot parsing

Instead of hard coding the name-to-id mapping in C code, keep it in an array and use a common function to do the parsing. This reduces code and also allows us to list all possible color slots later. This starts using C99 designated initializers more for convenience (the first designated

Re: [PATCH v3] checkout & worktree: introduce checkout.implicitRemote

On Fri, May 25, 2018 at 8:38 PM, Ævar Arnfjörð Bjarmason wrote: > > On Fri, May 25 2018, Duy Nguyen wrote: > >> On Fri, May 25, 2018 at 10:12 AM, Junio C Hamano wrote: +Currently this is used by linkgit:git-checkout[1] when 'git checkout +' will

[PATCH v2 3/4] t2203: add a test about "diff HEAD" case

Previous attempts to fix ita-related diffs breaks this case. To make sure that does not happen again, add a test to verify the behavior wrt. ita entries when we diff a worktree and a tree. Signed-off-by: Nguyễn Thái Ngọc Duy --- t/t2203-add-intent.sh | 17 + 1

[PATCH v2 4/4] apply: add --intent-to-add

Similar to 'git reset -N', this option makes 'git apply' automatically mark new files as intent-to-add so they are visible in the following 'git diff' command and could also be committed with 'git commit -a'. Signed-off-by: Nguyễn Thái Ngọc Duy --- Documentation/git-apply.txt

[PATCH v2 1/4] diff: ignore --ita-[in]visible-in-index when diffing worktree-to-tree

This option is supposed to fix the diff of "diff-files" (not reporting ita entries as new files) and "diff-index --cached " ( showing ita entries as present in the index with empty content) but not "diff-index ". When --ita-invisible-in-index is set on "git diff-index ", unpack_trees() will

[PATCH v2 2/4] diff: turn --ita-invisible-in-index on by default

Due to the implementation detail of intent-to-add entries, the current "git diff" (i.e. no treeish or --cached argument) would show the changes in the i-t-a file, but it does not mark the file as new, while "diff --cached" would mark the file as new while showing its content as empty. $ git

[PATCH v2 0/4] Fix i-t-a entries in git-diff and git-apply

v2 first fixes a bug in --ita-invisible-in-index that accidentally affects diffing a worktree and a tree. This caused a regression when v1's 1/2 turned this option on by default. Other than that, 4/4 should address Junio's comments on v1's 2/2. Nguyễn Thái Ngọc Duy (4): diff: ignore

[PATCH] upload-pack: reject shallow requests that would return nothing

Shallow clones with --shallow-since or --shalow-exclude work by running rev-list to get all reachable commits, then draw a boundary between reachable and unreachable and send "shallow" requests based on that. The code does miss one corner case: if rev-list returns nothing, we'll have no border

RE: [PATCH 1/2] remote-curl: accept all encoding supported by curl

Hi Jonathan, I'd like to confirm, that your patch fixes my problem: I can sync with google repository now using git and curl version without gzip support. Do you know how this patch is going to be released? Just HEAD now and GA in the next planned release? Communication looks like follow now:

[PATCH] t990X: use '.git/objects' as 'deep inside .git' path

Tests t9902-completion.sh and t9903-bash-prompt.sh each have tests that check what happens when we are "in the '.git' directory" and when we are "deep inside the '.git' directory". To test the case when we are "deep inside the '.git' directory" the test scripts used to perform a `cd

Fwd: [PATCH v2 02/18] Add a new builtin: branch-diff

Just want to throw my support in for range-diff since ranges is what you pass to the command. Alternatively, diff-diff since that's how I've crudely tried to accomplish this before. git diff A..B > diff1 git diff C..D > diff2 winmerge diff1 diff2