Re: [PATCH v2 2/2] Makefile: add style build rule

On Mon, Aug 14, 2017 at 2:30 PM, Brandon Williams wrote: > Add the 'style' build rule which will run git-clang-format on the diff > between HEAD and the current worktree. The result is a diff of > suggested changes. Notes from in-office discussion: * 'git clang-format

Re: [External] Re: gitk -m ?

Maybe there is a chance that combining `gitk `git log -m --follow --pretty=format:%h PATHSPEC`` with typing in _Enter files and directories to include, one per line:_ any (or maybe all) of the paths the doc had through history, would do; but /me more pessimistic now. Uxío Prego Madiva

Re: [PATCH v2 0/2] clang-format

On 08/14, Brandon Williams wrote: > Changes in v2: > * Changed a couple rules to be more inline with our coding style. > * Added a Makefile build rule to run git-clang-format on the diff of the >working tree to suggest style changes. > > I found that the llvm project also has the

[PATCH v2] stash: prevent warning about null bytes in input

The `no_changes` function calls the `untracked_files` function through command substitution. `untracked_files` will return null bytes because it runs ls-files with the '-z' option. Bash since version 4.4 warns about these null bytes. As they are not required for the test that is being done, make

Re: [PATCH] doc: clarify "config --bool" behaviour with empty values

Am 14.08.2017 um 19:53 schrieb Junio C Hamano: > Andreas Heiduk writes: > >> `git config --bool xxx.yyy` returns `true` for `[xxx]yyy` but >> `false` for `[xxx]yyy=` or `[xxx]yyy=""`. This is tested in >> t1300-repo-config.sh since 09bc098c2. >> >> Signed-off-by: Andreas

Re: [PATCH] hook: use correct logical variable

On Mon, Aug 14, 2017 at 1:46 AM, Kaartic Sivaraam wrote: > Sign-off added should be that of the "committer" not that of the > "commit's author". > > Use the correct logical variable that identifies the committer. > > Signed-off-by: Kaartic Sivaraam

RE: [External] Re: gitk -m ?

Neither of those two work for me. They don't limit the view to the single file of interest. Also, I tried "additional arguments to git log", using "-m --follow". I filled in the single file of interest in the 'Enter files' section. The error message was: Can't parse git log

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

On Fri, Aug 11, 2017 at 1:41 PM, Harry Putnam wrote: > 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")

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

On Mon, Aug 14, 2017 at 12:37 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> On Fri, Aug 11, 2017 at 5:39 PM, Junio C Hamano wrote: >> ... >>> My preference however is to keep sb/diff-color-move topic as-is >>> without replacing

[PATCH] t1002: stop using sum(1)

sum(1) is a command for calculating checksums of the contents of files. It was part of early editions of Unix ("Research Unix", 1972/1973, [1]). cksum(1) appeared in 4.4BSD (1993) as a replacement [2], and became part of POSIX.1-2008 [3]. OpenBSD 5.6 (2014) removed sum(1). We only use sum(1) in

Re: [PATCH] win32: plug memory leak on realloc() failure in syslog()

Hi René, On Thu, 10 Aug 2017, René Scharfe wrote: > If realloc() fails then the original buffer is still valid. Free it > before exiting the function. > > Signed-off-by: Rene Scharfe The subject had me worried for a second... The realloc() fails so rarely that I, for one, have

Re: [PATCH 1/9] Convert pack-objects to size_t

On Mon, Aug 14, 2017 at 08:31:50PM +0100, Ramsay Jones wrote: > > > On 14/08/17 18:08, Junio C Hamano wrote: > > Junio C Hamano writes: > > > >> One interesting question is which of these two types we should use > >> for the size of objects Git uses. > >> > >> Most of the

Re: [PATCH] stash: prevent warning about null bytes in input

On Mon, Aug 14, 2017 at 12:51:26PM -0700, Junio C Hamano wrote: > Kevin Daudt writes: > > > The no_changes function calls the untracked_files function through > > command substitution. untracked_files will return null bytes because it > > runs ls-files with the '-z' option. > > >

Re: [PATCH] stash: prevent warning about null bytes in input

Kevin Daudt writes: > On Mon, Aug 14, 2017 at 12:51:26PM -0700, Junio C Hamano wrote: >> Kevin Daudt writes: >> >> > The no_changes function calls the untracked_files function through >> > command substitution. untracked_files will return null bytes because it

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

On Fri, Aug 11, 2017 at 10:48 AM, Jameson Miller wrote: > The set of files listed by "--ignored" changes when different > values are given to "--untracked-files". If would be nice to > be able to make the ignored output independent of the untracked > settings. This

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

The existing documentation states "If there are fewer than 3 adjacent moved lines, they are not marked up as moved", which is ambiguous as to whether "adjacent moved lines" must be adjacent both at the source and at the destination, or be adjacent merely at the source or merely at the destination.

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

These patches are on sb/diff-color-move. Patches 1 and 2 are unchanged. It was pointed out to me that the documentation for "--color-moved=zebra" is ambiguous, but could plausibly describe the current behavior. I still think that the current behavior is confusing, so I have retained patch 3, but

[PATCH v2 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 ---

[PATCH v2 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 ---

[PATCH v2 1/2] clang-format: outline the git project's coding style

Add a '.clang-format' file which outlines the git project's coding style. This can be used with clang-format to auto-format .c and .h files to conform with git's style. Signed-off-by: Brandon Williams --- .clang-format | 165

[PATCH v2 0/2] clang-format

Changes in v2: * Changed a couple rules to be more inline with our coding style. * Added a Makefile build rule to run git-clang-format on the diff of the working tree to suggest style changes. I found that the llvm project also has the git-clang-format tool which will allow for doing

[PATCH v2 2/2] Makefile: add style build rule

Add the 'style' build rule which will run git-clang-format on the diff between HEAD and the current worktree. The result is a diff of suggested changes. Signed-off-by: Brandon Williams --- Makefile | 4 1 file changed, 4 insertions(+) diff --git a/Makefile b/Makefile

[PATCH v2] commit: skip discarding the index if there is no pre-commit hook

If there is not a pre-commit hook, there is no reason to discard the index and reread it. This change checks to presence of a pre-commit hook and then only discards the index if there was one. Signed-off-by: Kevin Willford --- builtin/commit.c | 15 +-- 1

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

Jeff King writes: > On Thu, Aug 10, 2017 at 11:58:34AM -0700, Stefan Beller wrote: > >> On Thu, Aug 10, 2017 at 11:47 AM, Kevin Willford >> wrote: >> > String formatting can be a performance issue when there are >> > hundreds of thousands of trees. >> >>

GOOD NEWS

Attention My Dear Your first payment of $5000.00 will be sent today via Western Union.if you provide the needed information You are advise to Contact Western Union with your full information to enable them give you the Senders Name, Question and Answer to pick up your First $5000 For

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

Stefan Beller writes: > On Fri, Aug 11, 2017 at 1:41 PM, Harry Putnam wrote: >> Stefan Beller writes: >> >> >> [...] >> >>> Ah. Sorry for confusing even more. >>> By pointing out the options for git-diff, I just wanted to point out

Re: [PATCH 1/9] Convert pack-objects to size_t

Ramsay Jones writes: > In a previous comment, I said that (on 32-bit Linux) it was likely > that an object of > 4GB could not be handled correctly anyway. (more > likely > 2GB). This was based on the code from (quite some) years ago. > In particular, before you added

Re: [PATCH v3 1/2 / RFC] builtin/branch: stop supporting the use of --set-upstream option

Kaartic Sivaraam writes: > The '--set-upstream' option of branch was deprecated in, > > b347d06bf branch: deprecate --set-upstream and show help if we > detect possible mistaken use (Thu, 30 Aug 2012 19:23:13 +0200) > > It was deprecated for the reasons

Re: [PATCH v2 1/2] clang-format: outline the git project's coding style

On Mon, Aug 14, 2017 at 2:30 PM, Brandon Williams wrote: > Add a '.clang-format' file which outlines the git project's coding > style. This can be used with clang-format to auto-format .c and .h > files to conform with git's style. > > Signed-off-by: Brandon Williams

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

Junio C Hamano writes: > Perhaps we may want to replace the calls to progress_delay() with a > call to a simpler wrapper that does not let the callers give their > own delay threashold to simplify the API. ... which does not look too bad, but because it makes me wonder if we

Re: [PATCH v3 1/2 / RFC] builtin/branch: stop supporting the use of --set-upstream option

On 14 August 2017 at 10:54, Kaartic Sivaraam wrote: > The '--set-upstream' option of branch was deprecated in, > > b347d06bf branch: deprecate --set-upstream and show help if we > detect possible mistaken use (Thu, 30 Aug 2012 19:23:13 +0200) > > It was

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

Stefan Beller writes: > On Fri, Aug 11, 2017 at 5:39 PM, Junio C Hamano wrote: > ... >> My preference however is to keep sb/diff-color-move topic as-is >> without replacing and fixing it with incremental updates like these >> patches. > > I would have

Re: [PATCH 0/4] dropping support for older curl

Hi Paolo, On Thu, 10 Aug 2017, Paolo Ciarrocchi wrote: > Il 10 ago 2017 11:39 AM, "Johannes Schindelin" > ha scritto: > > > > Footnote *1*: It is no secret that I find our patch submission less than > inviting. Granted, *I* use it. *I* did not have problems

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

Stefan Beller writes: > On Mon, Aug 14, 2017 at 9:05 AM, Johannes Schindelin > wrote: >> Hi Christoph, >> >> On Fri, 11 Aug 2017, Dr.-Ing. Christoph Cullmann wrote: >> >>> on Windows 64-bit, for a repository having a .pack file > 4GB I get >>>

Re: [PATCH 1/9] Convert pack-objects to size_t

On 14/08/17 18:08, Junio C Hamano wrote: > Junio C Hamano writes: > >> One interesting question is which of these two types we should use >> for the size of objects Git uses. >> >> Most of the "interesting" operations done by Git require that the >> thing is in core as a

Re: [PATCH] t1002: stop using sum(1)

René Scharfe writes: > It's more convenient because it shows differences nicely, it's faster on > MinGW because we have a special implementation there based only on > shell-internal commands,... This made me wonder why we are not using that "faster" one everywhere, but it turns

Re: [PATCH] hook: use correct logical variable

Kaartic Sivaraam writes: > Sign-off added should be that of the "committer" not that of the > "commit's author". > > Use the correct logical variable that identifies the committer. > > Signed-off-by: Kaartic Sivaraam > --- > This

Re: [PATCH] stash: prevent warning about null bytes in input

Kevin Daudt writes: > The no_changes function calls the untracked_files function through > command substitution. untracked_files will return null bytes because it > runs ls-files with the '-z' option. > > Bash since version 4.4 warns about these null bytes. As they are not >

Re: [PATCH v2 1/2] clang-format: outline the git project's coding style

On Mon, Aug 14, 2017 at 02:30:45PM -0700, Brandon Williams wrote: > +# Align escaped newlines as far left as possible > +# #define A \ > +# int ; \ > +# int b;\ > +# int ; > +AlignEscapedNewlines: Left I get: $ git clang-format-5.0 --style file -p --extensions c,h

Re: [PATCH v2 1/2] clang-format: outline the git project's coding style

On Mon, Aug 14, 2017 at 06:48:31PM -0400, Jeff King wrote: > On Mon, Aug 14, 2017 at 02:30:45PM -0700, Brandon Williams wrote: > > > +# Align escaped newlines as far left as possible > > +# #define A \ > > +# int ; \ > > +# int b;\ > > +# int ; > > +AlignEscapedNewlines:

Add --ignore-missing to git-pack-objects?

Hi. Is it possible to add an option akin to git-rev-list's '--ignore-missing' to git-pack-objects? I use git bundles to (incrementally) backup my repositories. My script inspects all bundles in the backup and passes their contained refs as excludes to git-pack-objects to build the pack for the

Re: [PATCH v2 0/2] clang-format

+ llvm-...@lists.llvm.org The Git community is currently discussing adopting a coding style defined by clang-format, here is a bug report: On Mon, Aug 14, 2017 at 4:06 PM, Jeff King wrote: > > One more oddity I found while playing with this that Git folks might run > into: > >

Re: [PATCH v2 2/2] Makefile: add style build rule

On Mon, Aug 14, 2017 at 03:28:50PM -0700, Stefan Beller wrote: > >> +.PHONY: style > >> +style: > >> + git clang-format --style file --diff --extensions c,h > > > > Did we get "git clang-format" subcommand, or is "s/git //" implied > > somewhere? > > You need to have clang-format installed

Re: [PATCH v2 2/2] Makefile: add style build rule

Jeff King writes: > I suspect the "-p" version is going to be the one people invoke the most > often. Should it take the coveted "make style" slot, and the diff get > pushed off to another target? > > I was also confused at first that the "-p" version requires you to stage > the

What's cooking in git.git (Aug 2017, #03; Mon, 14)

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 tip of 'next' has been

Re: [PATCH 1/9] Convert pack-objects to size_t

On 14/08/17 21:32, Torsten Bögershausen wrote: > In general, yes. > I had a patch that allowed a 32 bit linux to commit a file >4GB. > There is however a restriction: The file must not yet be known to the > index. Otherwise the "diff" machinery kicks in, and tries to > compare the "old" and the

Re: [PATCH v2] doc: clarify "config --bool" behaviour with empty values

Andreas Heiduk writes: > `git config --bool xxx.yyy` returns `true` for `[xxx]yyy` but > `false` for `[xxx]yyy=` or `[xxx]yyy=""`. This is tested in > t1300-repo-config.sh since 09bc098c2. > > Signed-off-by: Andreas Heiduk > --- >

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

Jeff King writes: > If it's smooth, the (50,1) case is slightly nicer in that it puts the > progress in front of the user more quickly. I'm not sure if that's > actually worth pushing an additional decision onto the person writing > the calling code, though (especially when we are

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

On Mon, Aug 14, 2017 at 2:31 PM, Jonathan Tan wrote: > The existing documentation states "If there are fewer than 3 adjacent > moved lines, they are not marked up as moved", which is ambiguous as to > whether "adjacent moved lines" must be adjacent both at the source and

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

On Mon, Aug 14, 2017 at 03:42:14PM -0700, Junio C Hamano wrote: > Jeff King writes: > > > If it's smooth, the (50,1) case is slightly nicer in that it puts the > > progress in front of the user more quickly. I'm not sure if that's > > actually worth pushing an additional decision

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

On Wed, Aug 09, 2017 at 07:19:00PM -0400, Jeff King wrote: > On Wed, Aug 09, 2017 at 03:53:17PM -0700, Stefan Beller wrote: > > > >> Right, the reason I stopped pursuing it was that I couldn't find a way > > >> to have it make suggestions for new code without nagging about existing > > >> code.

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

Hi, brian m. carlson wrote: >> On Wed, Aug 09, 2017 at 03:53:17PM -0700, Stefan Beller wrote: >>> We may have different opinions on what is readable/beautiful code. >>> If we were to follow a mutual agreed style that is produced by a tool, >>> we could use clean/smudge filters with different

Re: [PATCH v2 2/2] Makefile: add style build rule

Brandon Williams writes: > Add the 'style' build rule which will run git-clang-format on the diff > between HEAD and the current worktree. The result is a diff of > suggested changes. > > Signed-off-by: Brandon Williams > --- > Makefile | 4 > 1 file

Re: [PATCH v2 1/2] clang-format: outline the git project's coding style

On Mon, Aug 14, 2017 at 03:54:30PM -0700, Brandon Williams wrote: > > And removing that gives me a clean output. I have no idea why my clang > > doesn't like these (but presumably yours does). It's clang-format-5.0 in > > Debian unstable (and clang-format-3.8, etc). > > Those must be features in

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

Jeff King writes: > On Mon, Aug 14, 2017 at 03:42:14PM -0700, Junio C Hamano wrote: > >> Jeff King writes: >> >> > If it's smooth, the (50,1) case is slightly nicer in that it puts the >> > progress in front of the user more quickly. I'm not sure if that's >> >

[PATCH v3 3/3] diff: define block by number of non-space chars

The existing behavior of diff --color-moved=zebra does not define the minimum size of a block at all, instead relying on a heuristic applied later to filter out sets of adjacent moved lines that are shorter than 3 lines long. This can be confusing, because a block could thus be colored as moved at

[PATCH v3 0/3] "diff --color-moved" with different heuristic

These patches are on sb/diff-color-move. Patches 1 and 2 are unchanged. If we're planning to cook a heuristic, we might as well try a better one. What do you think of this? A heuristic of number of non-whitespace characters, applied at the block level, and not dependent on the block's neighbors.

[PATCH v3 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 ---

[PATCH v3 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 ---

Re: [PATCH v2] commit: skip discarding the index if there is no pre-commit hook

On Mon, Aug 14, 2017 at 03:54:25PM -0600, Kevin Willford wrote: > If there is not a pre-commit hook, there is no reason to discard > the index and reread it. > > This change checks to presence of a pre-commit hook and then only > discards the index if there was one. > > Signed-off-by: Kevin

[PATCH v2] doc: clarify "config --bool" behaviour with empty values

`git config --bool xxx.yyy` returns `true` for `[xxx]yyy` but `false` for `[xxx]yyy=` or `[xxx]yyy=""`. This is tested in t1300-repo-config.sh since 09bc098c2. Signed-off-by: Andreas Heiduk --- Documentation/config.txt | 10 +- Documentation/git.txt| 3 ++- 2

Re: [PATCH] doc: clarify "config --bool" behaviour with empty values

Andreas Heiduk writes: >> However, I think this "no value (but still with '=')" is making it >> more confusing than necessary for two reasons. > [...] > >> I notice that in this Values section (where the boolean:: is the >> first entry) there is no mention on how to spell a

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

On Mon, Aug 14, 2017 at 11:35:33AM -0700, Junio C Hamano wrote: > Junio C Hamano writes: > > > Perhaps we may want to replace the calls to progress_delay() with a > > call to a simpler wrapper that does not let the callers give their > > own delay threashold to simplify the

Re: [PATCH v2 2/2] Makefile: add style build rule

On Mon, Aug 14, 2017 at 3:25 PM, Junio C Hamano wrote: > Brandon Williams writes: > >> Add the 'style' build rule which will run git-clang-format on the diff >> between HEAD and the current worktree. The result is a diff of >> suggested changes. >> >>

Re: [PATCH v2 1/2] clang-format: outline the git project's coding style

On 08/14, Jeff King wrote: > On Mon, Aug 14, 2017 at 06:48:31PM -0400, Jeff King wrote: > > > On Mon, Aug 14, 2017 at 02:30:45PM -0700, Brandon Williams wrote: > > > > > +# Align escaped newlines as far left as possible > > > +# #define A \ > > > +# int ; \ > > > +# int b;\ > > >

Re: [PATCH v2 0/2] clang-format

On Mon, Aug 14, 2017 at 02:30:44PM -0700, Brandon Williams wrote: > Changes in v2: > * Changed a couple rules to be more inline with our coding style. > * Added a Makefile build rule to run git-clang-format on the diff of the >working tree to suggest style changes. > > I found that the

Re: [PATCH v2 2/2] Makefile: add style build rule

Junio C Hamano writes: > By the way, I do not know which vintage of /usr/bin/git-clang-format > I happen to have on my box, but I needed a crude workaround patch > (attached at the end) ... I guess you hit the same thing while our messages crossing ;-) > As to what it does,

Re: [PATCH v2 2/2] Makefile: add style build rule

On 08/14, Junio C Hamano wrote: > Junio C Hamano writes: > > > By the way, I do not know which vintage of /usr/bin/git-clang-format > > I happen to have on my box, but I needed a crude workaround patch > > (attached at the end) ... > > I guess you hit the same thing while our

Re: [PATCH] t1002: stop using sum(1)

Hi, René Scharfe wrote: > sum(1) is a command for calculating checksums of the contents of files. > It was part of early editions of Unix ("Research Unix", 1972/1973, [1]). > cksum(1) appeared in 4.4BSD (1993) as a replacement [2], and became part > of POSIX.1-2008 [3]. OpenBSD 5.6 (2014)

Re: [PATCH v2 0/2] clang-format

On Mon, Aug 14, 2017 at 04:15:40PM -0700, Stefan Beller wrote: > + llvm-...@lists.llvm.org > > The Git community is currently discussing adopting a coding style > defined by clang-format, here is a bug report: Since we've added a cc, let me try to give a little more context. > > One more

Re: [PATCH v2 2/2] Makefile: add style build rule

On Mon, Aug 14, 2017 at 04:47:45PM -0700, Junio C Hamano wrote: > > By the way, I do not know which vintage of /usr/bin/git-clang-format > > I happen to have on my box, but I needed a crude workaround patch > > (attached at the end) ... > > I guess you hit the same thing while our messages

Re: [PATCH v2 0/2] clang-format

On Mon, Aug 14, 2017 at 08:03:19PM -0700, Junio C Hamano wrote: > > I'm tempted to say that "config --list" should normalize this case into: > > > > mysection.mykey=true > > > > Normally we avoid coercing values without knowing the context in which > > they'll be used. But the syntax in the

Re: reftable [v5]: new ref storage format

On Mon, Aug 14, 2017 at 04:05:05PM +, David Turner wrote: > > All that aside, we could simply add an EXCLUSIVE open-flag to LMDB, and > > prevent multiple processes from using the DB concurrently. In that case, > > maintaining coherence with other NFS clients is a non-issue. It strikes me >

RE: [PATCH v2] commit: skip discarding the index if there is no pre-commit hook

> On Mon, Aug 14, 2017 at 03:54:25PM -0600, Kevin Willford wrote: > > > If there is not a pre-commit hook, there is no reason to discard > > the index and reread it. > > > > This change checks to presence of a pre-commit hook and then only > > discards the index if there was one. > > > >

Re: [PATCH v2] commit: skip discarding the index if there is no pre-commit hook

On Tue, Aug 15, 2017 at 04:23:50AM +, Kevin Willford wrote: > > This read_cache_from() should be a noop, right, because it immediately > > sees istate->initialized is set? So it shouldn't matter that it is not > > in the conditional with discard_cache(). Though if its only purpose is > > to

Re: [PATCH v2 0/2] clang-format

Jeff King writes: > On Mon, Aug 14, 2017 at 04:15:40PM -0700, Stefan Beller wrote: > >> + llvm-...@lists.llvm.org >> >> The Git community is currently discussing adopting a coding style >> defined by clang-format, here is a bug report: > > Since we've added a cc, let me try to

Re: [PATCH v3 3/3] diff: define block by number of non-space chars

On Mon, Aug 14, 2017 at 4:57 PM, Jonathan Tan wrote: > The existing behavior of diff --color-moved=zebra does not define the > minimum size of a block at all, instead relying on a heuristic applied > later to filter out sets of adjacent moved lines that are shorter than

Re: Bug?: git archive exclude pathspec and gitattributes export-ignore

On Mon, 14 Aug 2017, René Scharfe wrote: > Am 13.08.2017 um 06:53 schrieb David Adam: > > I think I have a bug in git (tested 2.11.0 on Debian 8, 2.14.1 on OS X and > > 2.14.1.145.gb3622a4 on OS X). > > > > Given a repository with an export-ignore directive for a subdirectory in > >

Re: [PATCH v4 0/4] interpret-trailers: add --where, --if-exists, --if-missing

Paolo Bonzini writes: > On 01/08/2017 11:03, Paolo Bonzini wrote: >> From: Paolo Bonzini >> >> These options are useful to experiment with "git interpret-trailers" >> without having to tinker with .gitconfig (Junio said git should ahve >> done this first

[PATCH v3 1/2 / RFC] builtin/branch: stop supporting the use of --set-upstream option

The '--set-upstream' option of branch was deprecated in, b347d06bf branch: deprecate --set-upstream and show help if we detect possible mistaken use (Thu, 30 Aug 2012 19:23:13 +0200) It was deprecated for the reasons specified in the commit message of the referenced commit. Make

[no subject]

£1.5 Million Has Been Granted To You As A Donation Visit www.bbc.co.uk/news/uk-england-19254228 Sendname Address Phone for more info

[PATCH] hook: use correct logical variable

Sign-off added should be that of the "committer" not that of the "commit's author". Use the correct logical variable that identifies the committer. Signed-off-by: Kaartic Sivaraam --- This fixes a small issue when trying to do the following with the script

Re: [PATCH v2 1/2 / RFC] builtin/branch: stop supporting the use of --set-upstream option

On Wednesday 09 August 2017 12:03 AM, Martin Ågren wrote: (Also, is this really a refactoring?) Not quite. --set-upstream:: - If specified branch does not exist yet or if `--force` has been - given, acts exactly like `--track`. Otherwise sets up configuration - like

Draft of Git Rev News edition 30

Hi, A draft of a new Git Rev News edition is available here: https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-30.md Everyone is welcome to contribute in any section either by editing the above page on GitHub and sending a pull request, or by commenting on this GitHub

Re: [PATCH v4 0/4] interpret-trailers: add --where, --if-exists, --if-missing

On 01/08/2017 11:03, Paolo Bonzini wrote: > From: Paolo Bonzini > > These options are useful to experiment with "git interpret-trailers" > without having to tinker with .gitconfig (Junio said git should ahve > done this first and only added configuration afterwards). It can

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

Hello Kevin, Yes, you're right - I didn't commit the change to the .gitignore file, so that addition is also being stashed. Thanks Sam Sam Partington Senior Developer www.whiteoctober.co.uk Office: +44 (0)1865 920 707 This email message and any attachments are confidential and solely for the

Re: reftable [v6]: new ref storage format

On 08/07/2017 03:47 AM, Shawn Pearce wrote: > 6th iteration of the reftable storage format. Thanks! > Changes from v5: > - extensions.refStorage = reftable is used to select this format. > > - Log records can be explicitly deleted (for refs/stash). > - Log records may use Michael Haggerty's

Re: reftable [v5]: new ref storage format

Howard Chu wrote: The primary issue with using LMDB over NFS is with performance. All reads are performed thru accesses of mapped memory, and in general, NFS implementations don't cache mmap'd pages. I believe this is a consequence of the fact that they also can't guarantee cache coherence, so

RE: [External] Re: gitk -m ?

They don't.  In particular, information about commits that are parts of merges is missing. Here's an example. There are only two entries listed in 'gitk --all' for a particular file (sorry, I'd prefer to include a screen sho, but the mailing list doesn't allow HTML messages). gitk --all

Re: Bug?: git archive exclude pathspec and gitattributes export-ignore

Am 13.08.2017 um 06:53 schrieb David Adam: > Hi all, > > I think I have a bug in git (tested 2.11.0 on Debian 8, 2.14.1 on OS X and > 2.14.1.145.gb3622a4 on OS X). > > Given a repository with an export-ignore directive for a subdirectory in > .gitattributes, `git archive` with a pathspec that

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

Jeff King writes: > On Sat, Aug 12, 2017 at 09:06:18AM +0100, Philip Oakley wrote: > >> > > > + progress = start_progress_delay(_("Generating patches"), total, 0, >> > > > 1); >> > > >> > > I don't really have an opinion on a 1 second delay versus 2. I thought >> > > we used 2

Re: [External] Re: gitk -m ?

I do not know if you can do what you want, mostly if you can do what you want as simply as you might be wanting that you want it, but I guess you could use this gitk boot command as a _simple_ work around somehow aliased within your command line configuration: $ gitk (--all)? $(git log -m

Re: [PATCH] Add overflow check to get_delta_hdr_size

Martin Koegler writes: > From: Martin Koegler > > Signed-off-by: Martin Koegler > --- > Applies on top of my size_t series > > I'm not sure, if die or error is better. As there is no fallback when we hit it, die

Re: [PATCH] Add overflow check to get_delta_hdr_size

Martin Koegler writes: > From: Martin Koegler > > Signed-off-by: Martin Koegler > --- > Applies on top of my size_t series > > I'm not sure, if die or error is better. As there is no fallback when we hit it, die

Re: [RFC PATCH 0/7] Implement ref namespaces as a ref storage backend

> Technical description > = > > This patch series adds a new refs backend, stacking on top of the files > backend, > based on whether `core.namespace` is set in git config. Currently there is another Big Thing getting started in in the refs backend.

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

On Mon, Aug 14, 2017 at 9:05 AM, Johannes Schindelin wrote: > Hi Christoph, > > On Fri, 11 Aug 2017, Dr.-Ing. Christoph Cullmann wrote: > >> on Windows 64-bit, for a repository having a .pack file > 4GB I get >> during cloning: > > The reason is Git's source code that

Re: [PATCH 1/9] Convert pack-objects to size_t

Junio C Hamano writes: > One interesting question is which of these two types we should use > for the size of objects Git uses. > > Most of the "interesting" operations done by Git require that the > thing is in core as a whole before we can do anything (e.g. compare > two

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

On Fri, Aug 11, 2017 at 3:49 PM, Jonathan Tan wrote: > 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. Oh that part. I remember debating

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

Hi Junio, On Thu, 10 Aug 2017, Junio C Hamano wrote: > Johannes Schindelin writes: > > > On Wed, 9 Aug 2017, Stefan Beller wrote: > > > >> > I am sure that something even better will be possible: a Continuous > >> > "Integration" that fixes the coding style

RE: reftable [v5]: new ref storage format

> -Original Message- > From: Howard Chu [mailto:h...@symas.com] > Sent: Monday, August 14, 2017 8:31 AM > To: spea...@spearce.org > Cc: David Turner ; ava...@gmail.com; > ben.a...@acegi.com.au; dborow...@google.com; git@vger.kernel.org; > gits...@pobox.com;

  1   2   >