Re: core.autocrlf=true causes `git apply` to fail on patch generated with `git diff-index HEAD --patch`

>I left it unsaid by mistake, but I think the right thing to use as >the "previous" to take hint from in the context of "git apply" is >what is in the working tree, i.e. the result of applying patch in >step (4) to create a file F in the sample scenario. >While applying patch in step (5),

Re: core.autocrlf=true causes `git apply` to fail on patch generated with `git diff-index HEAD --patch`

Test from mutt

Re: [RFC] clang-format: outline the git project's coding style

Jeff King writes: > On Fri, Aug 11, 2017 at 10:52:37AM -0700, Brandon Williams wrote: > >> On 08/09, Stefan Beller wrote: >> > On Wed, Aug 9, 2017 at 3:53 PM, Stefan Beller wrote: >> > >> > > I would think based on these options, a pre commit hook can be >> >

What's cooking in git.git (Aug 2017, #02; Fri, 11)

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. The first batch of 32 topics (not

Re: [PATCHv5 1/2] clone: respect additional configured fetch refspecs during initial fetch

Junio C Hamano writes: > Jeff King writes: > >> I'd still prefer this to have: >> >> if (!remote->fetch && remote->fetch_refspec_nr) >> BUG("attempt to add refspec to uninitialized list"); >> >> at the top, as otherwise this case writes garbage into

Re: [PATCH] hash: Allow building with the external sha1dc library

Ævar Arnfjörð Bjarmason writes: > On Fri, Jul 28, 2017 at 5:58 PM, Ævar Arnfjörð Bjarmason > wrote: > > I sent this last bit a tad too soon in a checkout of > sha1collisiondetection.git: > > $ make PREFIX=/tmp/local install >/dev/null 2>&1 && find

Re: [RFC PATCH 0/3] Fixes to "diff --color-moved" MIN_BLOCK_LENGTH handling

Jonathan Tan writes: > Note that these patches are for "next", depending on the "--color-moved" > patches. As we have finished Git 2.14 cycle, in preparation for the next one, the 'next' branch will be rewound and rebuilt early next week. I do not mind tentatively

Re: [PATCH 1/2] http: Fix handling of missing CURLPROTO_*

"Tom G. Christensen" writes: > Commit aeae4db1 refactored the handling of the curl protocol restriction > support into a function but failed to add a version check for older > versions of curl that lack CURLPROTO_* support. > This adds the missing check and at the same time

Would it make sense to add `--depth=0` feature?

Would it be feasible/sensical to support clone/fetch with --depth=0? The point is to download the tags/commit objects but not the actual trees and blobs, creating a "ledger" acting as a promise for the remote'e repo content? Is there some estimation of the effort required to do such thing? Best,

[RFC PATCH 1/3] diff: avoid redundantly clearing a flag

No code in diff.c sets DIFF_SYMBOL_MOVED_LINE except in mark_color_as_moved(), so it is redundant to clear it for the current line. Therefore, clear it only for previous lines. This makes a refactoring in a subsequent patch easier. Signed-off-by: Jonathan Tan ---

[RFC PATCH 0/3] Fixes to "diff --color-moved" MIN_BLOCK_LENGTH handling

Note that these patches are for "next", depending on the "--color-moved" patches. While working on something else [1], I noticed some irregularities with how "diff --color-moved" treats the minimum block size, occasionally coloring blocks smaller than that as moved. I've marked this as RFC

[RFC PATCH 2/3] diff: respect MIN_BLOCK_LENGTH for last block

Currently, MIN_BLOCK_LENGTH is only checked when diff encounters a line that does not belong to the current block. In particular, this means that MIN_BLOCK_LENGTH is not checked after all lines are encountered. Perform that check. Signed-off-by: Jonathan Tan ---

[RFC PATCH 3/3] diff: check MIN_BLOCK_LENGTH at start of new block

When noticing that the current line is not the continuation of the current block, but the start of a new one, mark_color_as_moved() does not check the length of the current block. Perform that check. Signed-off-by: Jonathan Tan --- diff.c | 6

Re: [PATCH v2 2/2] rebase: turn on progress option by default for format-patch

Kevin Willford writes: > This change passes the progress option of format-patch checking > that stderr is attached and rebase is not being run in quiet mode. Pass the "--progress" option to format-patch when the standard error stream goes to the terminal and the

Re: [PATCH v2 1/2] format-patch: have progress option while generating patches

Jeff King writes: > On Thu, Aug 10, 2017 at 02:32:55PM -0400, Kevin Willford wrote: > >> @@ -1493,6 +1496,8 @@ int cmd_format_patch(int argc, const char **argv, >> const char *prefix) >> OPT_FILENAME(0, "signature-file", _file, >> N_("add

Re: [PATCH 0/2] http: handle curl with vendor backports

"Tom G. Christensen" writes: > The curl packages provided by Red Hat for RHEL contain several > backports of features from later curl releases. > This causes problems with current version based checks in http.c. > > Here is an overview of the features that have been

Re: [PATCH] stash: clean untracked files before reset

Nicolas Morey-Chaisemartin writes: > If calling git stash -u on a repo that contains a file that is not > ignored any more due to a current modification of the gitignore file, > this file is stashed but not remove from the working tree. > This is due to git-stash

Re: [PATCH 2/2] sha1_file: remove read_packed_sha1()

Jonathan Tan writes: > Use read_object() in its place instead. This avoids duplication of code. > > This makes force_object_loose() slightly slower (because of a redundant > check of loose object storage), but only in the error case. > > Signed-off-by: Jonathan Tan

Re: [PATCH 1/2] sha1_file: set whence in storage-specific info fn

Jonathan Tan writes: > Move the setting of oi->whence to sha1_loose_object_info() and > packed_object_info(). > > This allows sha1_object_info_extended() to not need to know about the > delta base cache. This will be useful during a future refactoring in > which

Re: [RFC PATCH 01/10] pack: move pack name-related functions

Ben Peart writes: > On 8/9/2017 1:16 PM, Jonathan Tan wrote: > >> Ah, I forgot to mention this in the cover letter. I thought that one >> header was sufficient to cover all pack-related things, so if we wanted >> to know which files used pack-related things, we would only

Re: [RFC] clang-format: outline the git project's coding style

On Fri, Aug 11, 2017 at 10:52:37AM -0700, Brandon Williams wrote: > On 08/09, Stefan Beller wrote: > > On Wed, Aug 9, 2017 at 3:53 PM, Stefan Beller wrote: > > > > > I would think based on these options, a pre commit hook can be > > > written that formats precisely the

Re: Not understanding with git wants to copy one file to another

Stefan Beller writes: [...] > Ah. Sorry for confusing even more. > By pointing out the options for git-diff, I just wanted to point out that > such a mechanism ("rename/copy detection") exists. [...] >> What am I missing? >> > >

[PATCH 0/2] non-move patches in preparation for packfile.c

Thanks, I'll work on that. In the meantime, could these 2 patches be merged in (after review, of course) first? This will make the remaining set much easier to review, as you can check most of them with the new --color-moved functionality of diff. Incidentally, after rebasing on "pu" and

[PATCH 2/2] sha1_file: remove read_packed_sha1()

Use read_object() in its place instead. This avoids duplication of code. This makes force_object_loose() slightly slower (because of a redundant check of loose object storage), but only in the error case. Signed-off-by: Jonathan Tan --- sha1_file.c | 26

[PATCH 1/2] sha1_file: set whence in storage-specific info fn

Move the setting of oi->whence to sha1_loose_object_info() and packed_object_info(). This allows sha1_object_info_extended() to not need to know about the delta base cache. This will be useful during a future refactoring in which packfile-related functions, including the handling of the delta

Re: [RFC] clang-format: outline the git project's coding style

On 8/10/2017 5:30 PM, Brandon Williams wrote: On 08/10, Junio C Hamano wrote: Brandon Williams writes: On 08/10, Junio C Hamano wrote: I vaguely recall that there was a discussion to have SubmitGit wait for success from Travis CI; if that is already in place, then I

Re: [PATCH v2 00/25] Move exported packfile funcs to its own file

On 8/8/2017 9:22 PM, Jonathan Tan wrote: Here is the complete patch set. I have only moved the exported functions that operate with packfiles and their static helpers - for example, static functions like freshen_packed_object() that are used only by non-pack-specific functions are not moved.

Re: [RFC PATCH 01/10] pack: move pack name-related functions

On 8/9/2017 1:16 PM, Jonathan Tan wrote: On Wed, 9 Aug 2017 14:00:40 +0200 Christian Couder wrote: On Tue, Aug 8, 2017 at 10:50 PM, Jonathan Tan wrote: On Tue, 8 Aug 2017 13:36:24 -0700 Stefan Beller wrote: There

Re: [PATCH 4/5] interpret-trailers: add an option to normalize output

On Fri, Aug 11, 2017 at 11:06 AM, Jeff King wrote: > On Fri, Aug 11, 2017 at 09:02:24AM +0200, Christian Couder wrote: > >> > But I really don't want callers to think of it as "unfold". I want it to >> > be "turn this into something I can parse simply". Hence if we were to >> >

Re: [RFC] clang-format: outline the git project's coding style

Brandon Williams writes: >> checkpatch.pl also warns a SP immediately before HT, which I do pay > > I'm sorry what's 'HT'? Horizontal tab. "man ascii" or http://man7.org/linux/man-pages/man7/ascii.7.html

Re: [PATCH 4/4] Fix delta offset overflow

Martin Koegler writes: > On Thu, Aug 10, 2017 at 01:49:24PM -0700, Junio C Hamano wrote: >> The lower 4-byte of moff (before incrementing it with msize) were >> already encoded to the output stream before this hunk. Shouldn't >> we be checking if moff would fit in

Re: [PATCH V2 1/2] Fix delta integer overflows

Jeff King writes: > On Thu, Aug 10, 2017 at 01:07:07PM -0700, Junio C Hamano wrote: > >> Perhaps we should teach the receiving end to notice that the varint >> data it reads encodes a size that is too large for it to grok and >> die. With that, we can safely move forward with

Re: [PATCH V2 1/2] Fix delta integer overflows

Martin Koegler writes: > On Thu, Aug 10, 2017 at 01:07:07PM -0700, Junio C Hamano wrote: >> > The current delta code produces incorrect pack objects for files > 4GB. >> > >> > Signed-off-by: Martin Koegler >> >> I am a bit torn on this

Re: [PATCH v1 1/1] dir: teach status to show ignored directories

On 08/11/2017 01:39 PM, Brandon Williams wrote: On 08/10, Jameson Miller wrote: Teach Git to optionally show ignored directories when showing all untracked files. The git status command exposes the options to report ignored and/or untracked files. However, when reporting all untracked files

Re: [PATCH] t4062: stop using repetition in regex

René Scharfe writes: > Am 09.08.2017 um 19:47 schrieb Junio C Hamano: >> René Scharfe writes: >> >>> There could be any characters except NUL and LF between the 4096 zeros >>> and "0$" for the latter to match wrongly, no? So there are 4095 >>> opportunities for the

Re: [RFC] clang-format: outline the git project's coding style

On 08/09, Stefan Beller wrote: > On Wed, Aug 9, 2017 at 3:53 PM, Stefan Beller wrote: > > > I would think based on these options, a pre commit hook can be > > written that formats precisely the touched lines of code of each file. > > I did not search enough,

Re: [RFC] clang-format: outline the git project's coding style

On 08/09, Junio C Hamano wrote: > Junio C Hamano writes: > > >>> > +# Insert a space after a cast > >>> > +# x = (int32) y;notx = (int32)y; > >>> > +SpaceAfterCStyleCast: true > >>> > >>> Hmph, I thought we did the latter, i.e. cast sticks to the casted > >>>

Re: [PATCH v1 1/1] dir: teach status to show ignored directories

On 08/10/2017 04:03 PM, Stefan Beller wrote: On Thu, Aug 10, 2017 at 11:49 AM, Jameson Miller wrote: Welcome to the Git mailing list. :) Thank you for the welcome and the review! I will include the suggested code changes in the next patch version. Teach Git to

Re: [PATCH v1 1/1] dir: teach status to show ignored directories

On 08/10, Jameson Miller wrote: > Teach Git to optionally show ignored directories when showing all > untracked files. The git status command exposes the options to report > ignored and/or untracked files. However, when reporting all untracked > files (--untracked-files=all), all individual

Re: [PATCH v2 02/15] submodule: don't use submodule_from_name

On Fri, Aug 04, 2017 at 02:53:11PM -0700, Brandon Williams wrote: > On 08/03, Stefan Beller wrote: > > On Thu, Aug 3, 2017 at 11:19 AM, Brandon Williams wrote: > > > The function 'submodule_from_name()' is being used incorrectly here as a > > > submodule path is being used

Re: [PATCH v2 14/15] unpack-trees: improve loading of .gitmodules

On Thu, Aug 03, 2017 at 11:19:59AM -0700, Brandon Williams wrote: > diff --git a/unpack-trees.c b/unpack-trees.c > index 5dce7ff7d..3c7f464fa 100644 > --- a/unpack-trees.c > +++ b/unpack-trees.c > @@ -1,5 +1,6 @@ > #define NO_THE_INDEX_COMPATIBILITY_MACROS > #include "cache.h" > +#include

[PATCH] stash: clean untracked files before reset

If calling git stash -u on a repo that contains a file that is not ignored any more due to a current modification of the gitignore file, this file is stashed but not remove from the working tree. This is due to git-stash first doing a reset --hard which clears the .gitignore file modification and

Re: [PATCH 02/15] submodule: don't use submodule_from_name

Hi, sorry for the late reply, just stumpled upon this. On Mon, Jul 31, 2017 at 01:43:04PM -0700, Stefan Beller wrote: > On Sun, Jul 30, 2017 at 6:43 AM, Jens Lehmann wrote: > > Am 26.07.2017 um 23:06 schrieb Junio C Hamano: > >> > >> Stefan Beller

[PATCH 1/2] http: Fix handling of missing CURLPROTO_*

Commit aeae4db1 refactored the handling of the curl protocol restriction support into a function but failed to add a version check for older versions of curl that lack CURLPROTO_* support. This adds the missing check and at the same time converts it to a feature check instead of a version based

[PATCH 0/2] http: handle curl with vendor backports

The curl packages provided by Red Hat for RHEL contain several backports of features from later curl releases. This causes problems with current version based checks in http.c. Here is an overview of the features that have been backported: 7.10.6 (el3) Backports CURLPROTO_* 7.12.1 (el4) Backports

[PATCH 2/2] http: use a feature check to enable GSSAPI delegation control

Turn the version check into a feature check to ensure this functionality is also enabled with vendor supported curl versions where the feature may have been backported. Signed-off-by: Tom G. Christensen --- http.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)

Bug when stashing previously-ignored file plus associated .gitignore change

Hi there, I'm running git 2.7.4 on Ubuntu 16.04. I've found a couple of problems when "un-ignoring" files in tandem with git stash. Here's how to reproduce: Say you have a project using git, with a .gitignore file which contains the following line: bin/* You can then see the problems by

Re: [PATCH] cache-tree: remove use of strbuf_addf in update_one

Am 10.08.2017 um 20:47 schrieb Kevin Willford: > String formatting can be a performance issue when there are > hundreds of thousands of trees. > > Change to stop using the strbuf_addf and just add the strings > or characters individually. > > There are a limited number of modes so added a switch

Re: [PATCH] fsck: free buffers on error in fsck_obj()

On Thu, Aug 10, 2017 at 11:42:10AM +0200, René Scharfe wrote: > Move the code for releasing tree buffers and commit buffers in > fsck_obj() to the end of the function and make sure it's executed no > matter of an error is encountered or not. This looks good to me. > @@ -374,7 +369,12 @@ static

Re: git-describe --contains

On Aug 11 2017, Davide Cavallari wrote: > Please help me understand how this command works. There is one case in the > linux kernel repository that puzzles me. Let's consider patch "drm/i915/ > execlists: Reset RING registers upon resume" [1]. This patch was committed

Re: git-describe --contains

Le 11/08/2017 à 08:50, Davide Cavallari a écrit : > Please help me understand how this command works. There is one case in the > linux kernel repository that puzzles me. Let's consider patch "drm/i915/ > execlists: Reset RING registers upon resume" [1]. This patch was committed 641 > commits

Re: [PATCH 4/5] interpret-trailers: add an option to normalize output

On Fri, Aug 11, 2017 at 09:02:24AM +0200, Christian Couder wrote: > > But I really don't want callers to think of it as "unfold". I want it to > > be "turn this into something I can parse simply". Hence if we were to > > find another case where the output is irregular, I'd feel comfortable > >

Re: [PATCH] apply: remove prefix_length member from apply_state

On Fri, Aug 11, 2017 at 10:52:48AM +0200, René Scharfe wrote: > > I wondered at first whether it's actually necessary. Wouldn't > > an empty prefix always match? > > > > But I think we're looking for the pathname to be a proper superset of > > the prefix (hence the "!*rest" check). So I guess an

Re: [PATCH] apply: remove prefix_length member from apply_state

Am 11.08.2017 um 01:41 schrieb Jeff King: > On Wed, Aug 09, 2017 at 05:54:46PM +0200, René Scharfe wrote: > >> Use a NULL-and-NUL check to see if we have a prefix and consistently use >> C string functions on it instead of storing its length in a member of >> struct apply_state. This avoids

Re: [PATCH] strbuf: clear errno before calling getdelim(3)

Am 11.08.2017 um 09:50 schrieb Simon Ruderich: > On Thu, Aug 10, 2017 at 10:56:40PM +0200, René Scharfe wrote: >> getdelim(3) returns -1 at the end of the file and if it encounters an >> error, but sets errno only in the latter case. Set errno to zero before >> calling it to avoid misdiagnosing

Re: [PATCH] strbuf: clear errno before calling getdelim(3)

On Thu, Aug 10, 2017 at 10:56:40PM +0200, René Scharfe wrote: > getdelim(3) returns -1 at the end of the file and if it encounters an > error, but sets errno only in the latter case. Set errno to zero before > calling it to avoid misdiagnosing an out-of-memory condition due to a > left-over value

Re: [PATCH V2 1/2] Fix delta integer overflows

On Thu, Aug 10, 2017 at 01:07:07PM -0700, Junio C Hamano wrote: > > The current delta code produces incorrect pack objects for files > 4GB. > > > > Signed-off-by: Martin Koegler > > I am a bit torn on this change. > > Given that this is not merely a local storage

Re: [PATCH V2 2/2] Convert size datatype to size_t

On Thu, Aug 10, 2017 at 03:04:51PM -0700, Junio C Hamano wrote: > Martin Koegler writes: > > > For next. As this touches core functions, it will likely produce > > conflicts with other changes. Please provide the commit you want > > to rebase the patch on and I'll

Bug with corruption on clone/fsck/... with large packs + 64-bit Windows, problem with usage of "long" datatype for sizes/offsets?

Hi, on Windows 64-bit, for a repository having a .pack file > 4GB I get during cloning: $ git clone file:///repositories/test.git test Cloning into 'test'... remote: Counting objects: 210294, done. remote: error: bad object header remote: error: bad object header remote: fatal: packed object

Re: [PATCH 5/9] Convert sha1_file.c to size_t

On Thu, Aug 10, 2017 at 03:27:28PM -0700, Junio C Hamano wrote: > Please do not start your patch series from 5/9 when there is no 1/9, > 2/9, 3/9, and 4/9. It is seriously confusing. > > I am guessing that you are trying to split the series into > manageable pieces by going per call graph and

Re: [PATCH 4/5] interpret-trailers: add an option to normalize output

On Fri, Aug 11, 2017 at 1:10 AM, Jeff King wrote: > On Fri, Aug 11, 2017 at 12:02:49AM +0100, Ramsay Jones wrote: > >> > But some of those things are not 1:1 mappings with normalization. For >> > instance, --json presumably implies --only-trailers. Or are we proposing >> > to

Re: [PATCH 4/4] Fix delta offset overflow

On Thu, Aug 10, 2017 at 01:49:24PM -0700, Junio C Hamano wrote: > The lower 4-byte of moff (before incrementing it with msize) were > already encoded to the output stream before this hunk. Shouldn't > we be checking if moff would fit in uint32_t _before_ that happens? moff is otherwise only

git-describe --contains

Please help me understand how this command works. There is one case in the linux kernel repository that puzzles me. Let's consider patch "drm/i915/ execlists: Reset RING registers upon resume" [1]. This patch was committed 641 commits after version 4.8-rc2: ~$ git describe