Re: [PATCH 1/2] add: warn when adding an embedded repository

On Wed, Jun 14, 2017 at 10:53:12AM -0700, Stefan Beller wrote: > >> In my ideal dream world of submodules we would have the following: > >> > >> $ cat .gitmodules > >> [submodule "sub42"] > >> path = foo > >> # path only in tree! > > > > TBH, I am not sure why we need "path"; couldn't

Re: [PATCH v4 0/6] Avoid problem where git_dir is set after alias expansion

On Wed, Jun 14, 2017 at 01:35:22PM +0200, Johannes Schindelin wrote: > Changes since v3: > > - avoided the strbuf in alias_lookup() by using skip_prefix() and !strcmp() > instead. > > - fixed tyop ("read" instead of "reading", causing Junio to stumble) in the > commit message of 6/6.

Re: [PATCH v1] Configure Git contribution guidelines for github.com

On Mon, Jun 12, 2017 at 5:52 PM, Junio C Hamano wrote: > "Philip Oakley" writes: > >> From: "Lars Schneider" >>> Many open source projects use github.com for their contribution process. >>> Although we mirror the Git core

Re: [PATCH] wt-status.c: Modified status message shown for a parent-less branch

On Thu, Jun 15, 2017 at 01:49:20PM +0530, Kaartic Sivaraam wrote: > What about, "not making any assumptions" about what the user would > think when he views the output of `git status` ? Why not try some > general messages like, > > * Staged changes > * Unstaged changes > > instead of the

Re: rs/strbuf-addftime-zZ, was Re: What's cooking in git.git (Jun 2017, #04; Tue, 13)

Am 15.06.2017 um 07:42 schrieb Jeff King: On Thu, Jun 15, 2017 at 01:03:29AM +0200, René Scharfe wrote: But there's more. strftime on Windows doesn't support common POSIX- defined tokens like %F (%Y-%m-%d) and %T (%H:%M:%S). We could handle them as well. Do we want that? At least we'd have

[PATCH v2] strbuf: let strbuf_addftime handle %z and %Z itself

There is no portable way to pass timezone information to strftime. Add parameters for timezone offset and name to strbuf_addftime and let it handle the timezone-related format specifiers %z and %Z internally. Callers can opt out for %Z by passing NULL as timezone name. %z is always handled

Re:

I would need your partnership in a transaction and details will disclose to you once i receive your reply. Thanks Saif.

[BUG] git cherry-pick segfaults with local changes in working directory

Hi, This is with git 2.11.0 (Debian 2.11.0-4) and can be reproduced with the packed checkout here: https://people.freedesktop.org/~slomo/git-cherry-pick-segfault_gst-plugins-good.tar.xz $ tar xf git-cherry-pick-segfault_gst-plugins-good.tar.xz $ cd gst-plugins-good $ git cherry-pick

Re: Small issue with "add untracked" option of 'git add -i'

On Wed, 2017-06-14 at 18:34 +0530, Kaartic Sivaraam wrote: > That's right. Though I'm not sure of the implementation, I guess the > following patch would make `git add -i` do what I thought it should. > A possible, probably better, alternative would be to make the empty state output more

[BUG] GITK don't show unstaged changes

Details: https://github.com/git-for-windows/git/issues/1203 Version with bug: 2.13.1 Normal: 2.13.0 CCFelix

[PATCH v3] strbuf: let strbuf_addftime handle %z and %Z itself

There is no portable way to pass timezone information to strftime. Add parameters for timezone offset and name to strbuf_addftime and let it handle the timezone-related format specifiers %z and %Z internally. Callers can opt out for %Z by passing NULL as timezone name. %z is always handled

Re: [PATCH v2] strbuf: let strbuf_addftime handle %z and %Z itself

Am 15.06.2017 um 13:27 schrieb Ulrich Mueller: On Thu, 15 Jun 2017, René Scharfe wrote: Callers can opt out for %Z by passing NULL as timezone name. %z is always handled internally -- this helps on Windows, where strftime would expand it to a timezone name (same as %Z), in violation of

Re: [PATCH] wt-status.c: Modified status message shown for a parent-less branch

On Thu, Jun 15, 2017 at 07:43:17AM -0400, Samuel Lijin wrote: > > Saying just "staged changes" is definitely accurate. I don't know if > > some users would find that too terse, too. The phrase "not staged for > > commit" gives more information if you don't know what "staged" means in > > the Git

Re: [BUG] add_again() off-by-one error in custom format

On Thu, Jun 15, 2017 at 01:33:34PM +0200, René Scharfe wrote: > > The difference is that in the "before" case, we actually opened each > > directory and ran getdents(). But after gc, the directories are gone > > totally and open() fails. We also have to do a linear walk through the > > objects in

Re: Which hash function to use, was Re: RFC: Another proposed hash function transition plan

On Thu, Jun 15, 2017 at 08:05:18PM +0900, Mike Hommey wrote: > On Thu, Jun 15, 2017 at 12:30:46PM +0200, Johannes Schindelin wrote: > > Footnote *1*: SHA-256, as all hash functions whose output is essentially > > the entire internal state, are susceptible to a so-called "length > > extension

Re: [BUG] git cherry-pick segfaults with local changes in working directory

On Thu, Jun 15, 2017 at 01:37:36PM +0300, Sebastian Dröge wrote: > > Note that the tarball doesn't have all the necessary objects. Its > > .git/objects/info/alternates points to another full clone of > > git://anongit.freedesktop.org/gstreamer/gst-plugins-good. > > Ah good to know, I thought

Re: preserve untracked cache, was Re: What's cooking in git.git (Jun 2017, #01; Thu, 1)

Hi Junio, On Sat, 3 Jun 2017, Junio C Hamano wrote: > Johannes Schindelin writes: > > > On Fri, 2 Jun 2017, Junio C Hamano wrote: > > > >> Samuel Lijin writes: > >> > >> >> What is holding this topic up? Anything Ben or I can do to move this >

Re: [PATCH v2] strbuf: let strbuf_addftime handle %z and %Z itself

> On Thu, 15 Jun 2017, René Scharfe wrote: > Callers can opt out for %Z by passing NULL as timezone name. %z is > always handled internally -- this helps on Windows, where strftime would > expand it to a timezone name (same as %Z), in violation of POSIX. > Modifiers are not handled, e.g. %Ez

Re: [BUG] git cherry-pick segfaults with local changes in working directory

On Thu, Jun 15, 2017 at 12:11:50PM +0300, Sebastian Dröge wrote: > This is with git 2.11.0 (Debian 2.11.0-4) and can be reproduced with > the packed checkout here: > > https://people.freedesktop.org/~slomo/git-cherry-pick-segfault_gst-plugins-good.tar.xz > > $ tar xf

Re: [BUG] git cherry-pick segfaults with local changes in working directory

Hi Jeff, Thanks for the fast reply! On Thu, 2017-06-15 at 06:32 -0400, Jeff King wrote: > On Thu, Jun 15, 2017 at 12:11:50PM +0300, Sebastian Dröge wrote: > > > This is with git 2.11.0 (Debian 2.11.0-4) and can be reproduced with > > the packed checkout here: > >   > >

[PATCH] checkout: don't write merge results into the object database

Merge results need to be written to the worktree, of course, but we don't necessarily need object entries for them, especially if they contain conflict markers. Use pretend_sha1_file() to create fake blobs to pass to make_cache_entry() and checkout_entry() instead. Signed-off-by: Rene Scharfe

Re: [BUG] add_again() off-by-one error in custom format

Am 15.06.2017 um 07:56 schrieb Jeff King: One interesting thing is that the cost of finding short hashes very much depends on your loose object setup. I timed: git log --format=%H >/dev/null versus git log --format=%h >/dev/null on git.git. It went from about 400ms to about 800ms. But

[PATCH] docs/pretty-formats: stress that %- removes all preceding line-feeds

Signed-off-by: SZEDER Gábor --- A mere plural "line-feeds" was too subtle for me to grasp on first (and second...) reading. Documentation/pretty-formats.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/pretty-formats.txt

Which hash function to use, was Re: RFC: Another proposed hash function transition plan

Hi, I thought it better to revive this old thread rather than start a new thread, so as to automatically reach everybody who chimed in originally. On Mon, 6 Mar 2017, Brandon Williams wrote: > On 03/06, brian m. carlson wrote: > > > On Sat, Mar 04, 2017 at 06:35:38PM -0800, Linus Torvalds

Re: pushing for a new hash, was Re: [PATCH 2/3] rebase: Add tests for console output

Hi Ævar, On Fri, 2 Jun 2017, Ævar Arnfjörð Bjarmason wrote: > On Fri, Jun 2, 2017 at 7:54 PM, Jonathan Nieder wrote: > > > > Johannes Schindelin wrote: > >> On Thu, 1 Jun 2017, Stefan Beller wrote: > > > >>> We had a discussion off list how much of the test suite is in bad >

Re: Which hash function to use, was Re: RFC: Another proposed hash function transition plan

On Thu, Jun 15, 2017 at 12:30:46PM +0200, Johannes Schindelin wrote: > Footnote *1*: SHA-256, as all hash functions whose output is essentially > the entire internal state, are susceptible to a so-called "length > extension attack", where the hash of a secret+message can be used to > generate the

Re: [PATCH] wt-status.c: Modified status message shown for a parent-less branch

On Thu, Jun 15, 2017 at 4:42 AM, Jeff King wrote: > > On Thu, Jun 15, 2017 at 01:49:20PM +0530, Kaartic Sivaraam wrote: > > > What about, "not making any assumptions" about what the user would > > think when he views the output of `git status` ? Why not try some > > general

Re: [PATCH 2/2] date: use localtime() for "-local" time formats

Am 15.06.2017 um 15:52 schrieb Jeff King: But for the special case of the "-local" formats, we can just skip the adjustment and use localtime() instead of gmtime(). This makes --date=format-local:%Z work correctly, showing the local timezone instead of an empty string.

git diff sometimes brings up buggy pager

When I do `git diff` sometimes I get this: ...skipping... ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ...skipping... ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ...skipping... ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ it goes on like this for about 10 times the length. Looks like this happens

Re: Which hash function to use, was Re: RFC: Another proposed hash function transition plan

On Thu, Jun 15 2017, Jeff King jotted: > On Thu, Jun 15, 2017 at 08:05:18PM +0900, Mike Hommey wrote: > >> On Thu, Jun 15, 2017 at 12:30:46PM +0200, Johannes Schindelin wrote: >> > Footnote *1*: SHA-256, as all hash functions whose output is essentially >> > the entire internal state, are

[PATCH] diff-highlight: split code into module

The diff-so-fancy project is also written in perl, and most of its users pipe diffs through both diff-highlight and diff-so-fancy. It would be nice if this could be done in a single script. So let's pull most of diff-highlight's code into its own module which can be used by diff-so-fancy. In

Re: [PATCH v3] strbuf: let strbuf_addftime handle %z and %Z itself

On Thu, Jun 15, 2017 at 02:29:53PM +0200, René Scharfe wrote: > There is no portable way to pass timezone information to strftime. Add > parameters for timezone offset and name to strbuf_addftime and let it > handle the timezone-related format specifiers %z and %Z internally. > > Callers can

Re: [PATCH] checkout: don't write merge results into the object database

On Thu, Jun 15, 2017 at 01:33:42PM +0200, René Scharfe wrote: > Merge results need to be written to the worktree, of course, but we > don't necessarily need object entries for them, especially if they > contain conflict markers. Use pretend_sha1_file() to create fake > blobs to pass to

[PATCH 1/2] t0006: check --date=format zone offsets

We already test that "%z" and "%Z" show the right thing, but we don't actually check that the time we display is the correct one. Let's add two new tests: 1. Test that "format:" shows the time in the author's timezone, just like the other time formats. 2. Test that "format-local:" shows

[PATCH 2/2] date: use localtime() for "-local" time formats

When we convert seconds-since-epochs timestamps into a broken-down "struct tm", we do so by adjusting the timestamp according to the known offset and then using gmtime() to break down the result. This means that the resulting struct "knows" that it's in GMT, even though the time it represents is

Re: [PATCH] sub-process: fix comment about api-sub-process.txt

On 6/14/2017 2:26 PM, Jonathan Nieder wrote: Christian Couder wrote: Subject: sub-process: fix comment about api-sub-process.txt nit: this one-line description doesn't describe what was wrong and is being fixed. I think something like sub-process: correct path to API docs in

Re: [PATCH] wt-status.c: Modified status message shown for a parent-less branch

On Mon, 2017-06-12 at 17:37 -0400, Jeff King wrote: > On Mon, Jun 12, 2017 at 02:31:25PM -0700, Junio C Hamano wrote: > > > I think "staged for commit" still makes perfect sense even when > > > we are > > > just asking "what's the current status" and not "what would it > > > look like > > > if I

Re: [PATCH] checkout: don't write merge results into the object database

Am 15.06.2017 um 15:57 schrieb Jeff King: > On Thu, Jun 15, 2017 at 01:33:42PM +0200, René Scharfe wrote: > >> Merge results need to be written to the worktree, of course, but we >> don't necessarily need object entries for them, especially if they >> contain conflict markers. Use

Re: What's cooking in git.git (Jun 2017, #04; Tue, 13)

Jonathan Nieder writes: >> It is not known if a simple "yes/no" is sufficient in the longer >> term, and what should happen when --recurse-submodules option starts >> taking "recurse into them how?" parameter, though. > > Any pointers for where this has been discussed, if

Re: [BUG] add_again() off-by-one error in custom format

René Scharfe writes: > Am 13.06.2017 um 23:20 schrieb Junio C Hamano: > >> I think the real question is how likely people use more than one >> occurrence of the same thing in their custom format, and how deeply >> they care that --format='%h %h' costs more than --format='%h'. The

Re: [PATCH v2 4/4] sha1_file, fsck: add missing blob support

A reroll is coming soon, but there is an interesting discussion point here so I'll reply to this e-mail first. On Thu, 15 Jun 2017 11:34:45 -0700 Junio C Hamano wrote: > Jonathan Tan writes: > > > +struct missing_blob_manifest { > > + struct

Re: [PATCH v2 2/4] sha1_file: move delta base cache code up

Jonathan Tan writes: > In a subsequent patch, packed_object_info() will be modified to use the > delta base cache, so move the relevant code to before > packed_object_info(). > > Signed-off-by: Jonathan Tan > --- > sha1_file.c | 226 >

Re: [PATCH v2 3/4] sha1_file: consolidate storage-agnostic object fns

Jonathan Tan writes: > Looking at the 3 primary functions (sha1_object_info_extended, > read_object, has_sha1_file_with_flags), they independently implement > mechanisms such as object replacement, retrying the packed store after > failing to find the object in the

[ANNOUNCE] Git for Windows 2.13.1(2)

Dear Git users, It is my pleasure to announce that Git for Windows 2.13.1(2) is available from: https://git-for-windows.github.io/ Changes since Git for Windows v2.13.1 (June 13th 2017) Bug Fixes * git commit and git status no longer randomly throw segmentation faults. Filename

Re: [PATCH] diff-highlight: split code into module

On 06/15/2017 12:15 PM, Junio C Hamano wrote: > Do you want +x bit for the last one? I could throw that bit in > while queuing if you want. > > Thanks. > Ya probably best.

Re: git diff sometimes brings up buggy pager

Any chance you can tell us what repo this happens on? + git version, OS, and what the triggering diff invocation is. On Thu, Jun 15, 2017 at 12:19 PM, Matthew Groth wrote: > When I do `git diff` sometimes I get this: > > > ...skipping... > ~ > ~ > ~ > ~ > ~ > ~ > ~ > ~ > ~ >

Re: Which hash function to use, was Re: RFC: Another proposed hash function transition plan

On 06/15, Johannes Schindelin wrote: > Hi, > > I thought it better to revive this old thread rather than start a new > thread, so as to automatically reach everybody who chimed in originally. > > On Mon, 6 Mar 2017, Brandon Williams wrote: > > > On 03/06, brian m. carlson wrote: > > > > > On

Re: [PATCH] diff-highlight: split code into module

Jeff King writes: > The diff-so-fancy project is also written in perl, and most > of its users pipe diffs through both diff-highlight and > diff-so-fancy. It would be nice if this could be done in a > single script. So let's pull most of diff-highlight's code > into its own module

Re: [PATCH v4 6/6] Use the early config machinery to expand aliases

Hi Junio, On Thu, 15 Jun 2017, Junio C Hamano wrote: > Johannes Schindelin writes: > > > +struct config_alias_data > > +{ > > Style: "struct config_alias_data {" > > which I can tweak while applying. Please do. > Other than that, everything looks good. Thanks,

Re: [PATCH v1] Configure Git contribution guidelines for github.com

Am 15.06.2017 um 18:43 schrieb Junio C Hamano: > Another thing that may regress that you did not mention is that we > would lose a convenient way to _count_ proposed changes coming via > submitGit (i.e. you can simply go to the pull-request page), so that > the number can be compared with the

Re: [PATCH v2 3/4] sha1_file: consolidate storage-agnostic object fns

On Thu, 15 Jun 2017 10:50:46 -0700 Junio C Hamano wrote: > Jonathan Tan writes: > > > Looking at the 3 primary functions (sha1_object_info_extended, > > read_object, has_sha1_file_with_flags), they independently implement > > mechanisms such as

Re: [PATCH v2 4/4] sha1_file, fsck: add missing blob support

Jonathan Tan writes: > diff --git a/sha1_file.c b/sha1_file.c > index 98086e21e..75fe2174d 100644 > --- a/sha1_file.c > +++ b/sha1_file.c > @@ -27,6 +27,9 @@ > #include "list.h" > #include "mergesort.h" > #include "quote.h" > +#include "iterator.h" > +#include

Re: [PATCH] diff-highlight: split code into module

Junio C Hamano writes: >> contrib/diff-highlight/.gitignore | 2 ++ >> .../{diff-highlight => DiffHighlight.pm} | 40 >> +- >> contrib/diff-highlight/Makefile| 21 ++-- >>

Re: [WIP v2 2/2] pack-objects: support --blob-max-bytes

On 6/2/2017 6:26 PM, Jeff King wrote: On Fri, Jun 02, 2017 at 12:38:45PM -0700, Jonathan Tan wrote: ... We have a name-hash cache extension in the bitmap file, but it doesn't carry enough information to deduce the .git-ness of a file. I don't think it would be too hard to add a "flags"

Re: Which hash function to use, was Re: RFC: Another proposed hash function transition plan

Hi Dscho, Johannes Schindelin wrote: > From what I read, pretty much everybody who participated in the discussion > was aware that the essential question is: performance vs security. I don't completely agree with this framing. The essential question is: how to get the right security properties

Re: Which hash function to use, was Re: RFC: Another proposed hash function transition plan

Brandon Williams writes: >> It would make a whole of a lot of sense to make that knob not Boolean, >> but to specify which hash function is in use. > > 100% agree on this point. I believe the current plan is to have the > hashing function used for a repository be a repository

Re: [PATCH v4 6/6] Use the early config machinery to expand aliases

Johannes Schindelin writes: > +struct config_alias_data > +{ Style: "struct config_alias_data {" which I can tweak while applying. Other than that, everything looks good. Thanks.

Re: [PATCH v2 1/2] git-compat-util: add a FREEZ() wrapper around free(ptr); ptr = NULL

On Thu, Jun 15, 2017 at 6:48 PM, Junio C Hamano wrote: > Jeff King writes: > >> On Sat, Jun 10, 2017 at 03:21:43AM +, Eric Wong wrote: >> >>> > So make Jonathan's freez_impl a public API and rename it to >>> > free_and_null(), perhaps? >>> >>> Perhaps... I

Re: [PATCH v3 0/6] config.h

Brandon Williams writes: > Changes in v3: > > * tweaked the discover_git_directory function's API based on Peff's feedback > * reordered the last three patches so that they flowed a bit better > * renamed 'git_config_with_options' > * rebased ontop of v4 of Dscho's alias

Re: [PATCH v1] Configure Git contribution guidelines for github.com

Andreas Heiduk writes: > Am 15.06.2017 um 18:43 schrieb Junio C Hamano: >> Another thing that may regress that you did not mention is that we >> would lose a convenient way to _count_ proposed changes coming via >> submitGit (i.e. you can simply go to the pull-request page),

Re: Which hash function to use, was Re: RFC: Another proposed hash function transition plan

Hi, On Thu, 15 Jun 2017, Ævar Arnfjörð Bjarmason wrote: > On Thu, Jun 15 2017, Jeff King jotted: > > > On Thu, Jun 15, 2017 at 08:05:18PM +0900, Mike Hommey wrote: > > > >> On Thu, Jun 15, 2017 at 12:30:46PM +0200, Johannes Schindelin wrote: > >> > >> > Footnote *1*: SHA-256, as all hash

Re: Which hash function to use, was Re: RFC: Another proposed hash function transition plan

(I was asked to comment a few points in public by Jonathan.) I think this group can safely assume that SHA-256, SHA-512, BLAKE2, K12, etc are all secure to the extent that I don't believe that making comparisons between them on that axis is meaningful. Thus I think the question is primarily

Re: [PATCH v2 0/3] Add regression tests for rectent rebase -i fixes

Phillip Wood writes: > From: Phillip Wood > > I've revised the second two tests as Johannes suggested to drop the > sed script. The first one is unchanged. > > Phillip Wood (3): > rebase -i: Add test for reflog message > rebase: Add

Re: [PATCH v2 0/3] Add regression tests for rectent rebase -i fixes

Junio C Hamano writes: > Junio C Hamano writes: > >> Phillip Wood writes: >> >>> From: Phillip Wood >>> >>> I've revised the second two tests as Johannes suggested to drop the >>> sed script. The

Re: [PATCH v3 0/6] config.h

On 06/15, Brandon Williams wrote: > On 06/15, Junio C Hamano wrote: > > Brandon Williams writes: > > > > > On 06/15, Junio C Hamano wrote: > > > > > >> ... so please eyeball the resulting 12 patches carefully when > > >> they are pushed out. I just took a look at what you

[PATCH v3 1/4] sha1_file: teach packed_object_info about typename

In commit 46f0344 ("sha1_file: support reading from a loose object of unknown type", 2015-05-06), "struct object_info" gained a "typename" field that could represent a type name from a loose object file, whether valid or invalid, as opposed to the existing "typep" which could only represent valid

[PATCH v3 4/4] sha1_file, fsck: add missing blob support

Currently, Git does not support repos with very large numbers of blobs or repos that wish to minimize manipulation of certain blobs (for example, because they are very large) very well, even if the user operates mostly on part of the repo, because Git is designed on the assumption that every blob

[PATCH v3 3/4] sha1_file: consolidate storage-agnostic object fns

In sha1_file.c, there are a few functions that provide information on an object regardless of its storage (cached, loose, or packed). Looking through all non-static functions in sha1_file.c that take in an unsigned char * pointer, the relevant ones are: - sha1_object_info_extended -

[PATCH v3 0/4] Improvements to sha1_file

Thanks - this has been updated following Junio's comments. Patch 1 is unmodified from the previous version. Patch 2 has been modified to remove the extraneous code pointed out by Junio. I previously had an idea of populating those fields in packed_object_info(), but later changed my mind, but a

[PATCH v3 2/2] *.[ch] refactoring: make use of the FREE_AND_NULL() macro

Replace occurrences of `free(ptr); ptr = NULL` with `FREE_AND_NULL(ptr)`. This introduces no functional changes, but reduces the line count and establishes this pattern as a common idiom with a wrapper macro. Signed-off-by: Ævar Arnfjörð Bjarmason --- alias.c

Re: [PATCH v3 0/6] config.h

On 06/15, Junio C Hamano wrote: > Brandon Williams writes: > > > On 06/15, Junio C Hamano wrote: > > > >> ... so please eyeball the resulting 12 patches carefully when > >> they are pushed out. > > > > Ugh, I'm terribly sorry. Completely my bad as I didn't consider what > >

Re: [PATCH 2/2] date: use localtime() for "-local" time formats

René Scharfe writes: > Am 15.06.2017 um 15:52 schrieb Jeff King: >> But for the special case of the "-local" formats, we can >> just skip the adjustment and use localtime() instead of >> gmtime(). This makes --date=format-local:%Z work correctly, >> showing the local timezone

Re: [PATCH v3 0/2] Add a FREE_AND_NULL() wrapper macro

Ævar Arnfjörð Bjarmason writes: > On Thu, Jun 15 2017, Ævar Arnfjörð Bjarmason jotted: >> I'll change it to FREE_AND_NULL and submit my patch as-is, my reading >> of the rest of this thread is that making it a function instead of a >> macro would be interesting, but has its

Re: [PATCH v2] wildmatch test: cover a blind spot in "/" matching

Ævar Arnfjörð Bjarmason writes: > A negated character class that does not include '/', e.g. [^a-z]: > > - Should match '/' when doing "wildmatch" > - Should not match '/' when doing "pathmatch" > > Add two tests to cover these cases. > > Helped-by: Junio C Hamano

Re: [PATCH 1/2] for_each_bisect_ref(): don't trim refnames

Michael Haggerty writes: > `for_each_bisect_ref()` is called by `for_each_bad_bisect_ref()` with > a term "bad". This used to make it call `for_each_ref_in_submodule()` > with a prefix "refs/bisect/bad". But the latter is the name of the > reference that is being sought, so

Re: Which hash function to use, was Re: RFC: Another proposed hash function transition plan

On Thu, Jun 15, 2017 at 02:59:57PM -0700, Adam Langley wrote: > (I was asked to comment a few points in public by Jonathan.) > > I think this group can safely assume that SHA-256, SHA-512, BLAKE2, > K12, etc are all secure to the extent that I don't believe that making > comparisons between them

Re: [PATCH] builtin/clone: get rid of 'value' strbuf

Christian Couder writes: > This makes the code simpler by removing a few lines, and getting > rid of one variable. > > Signed-off-by: Christian Couder > --- This patch may have meant well, but I think e5698f3a ("clone: respect additional

[PATCH v4 3/6] coccinelle: make use of the "type" FREE_AND_NULL() rule

Apply the result of the just-added coccinelle rule. This manually excludes a few occurrences, mostly things that resulted in many FREE_AND_NULL() on one line, that'll be manually fixed in a subsequent change. Signed-off-by: Ævar Arnfjörð Bjarmason --- alias.c

[PATCH v4 6/6] *.[ch] refactoring: make use of the FREE_AND_NULL() macro

Replace occurrences of `free(ptr); ptr = NULL` which weren't caught by the coccinelle rule. These fall into two categories: - free/NULL assignments one after the other which coccinelle all put on one line, which is functionally equivalent code, but very ugly. - manually spotted occurrences

[PATCH v4 1/6] git-compat-util: add a FREE_AND_NULL() wrapper around free(ptr); ptr = NULL

Add a FREE_AND_NULL() wrapper marco for the common pattern of freeing a pointer and assigning NULL to it right afterwards. The implementation is similar to the (currently unused) XDL_PTRFREE macro in xdiff/xmacros.h added in commit 3443546f6e ("Use a *real* built-in diff generator", 2006-03-24).

[PATCH v4 5/6] coccinelle: make use of the "expression" FREE_AND_NULL() rule

A follow-up to the existing "expression" rule added in an earlier change. This manually excludes a few occurrences, mostly things that resulted in many FREE_AND_NULL() on one line, that'll be manually fixed in a subsequent change. Signed-off-by: Ævar Arnfjörð Bjarmason ---

[ANNOUNCE] git-cinnabar 0.5.0b2

Hi, Git-cinnabar is a git remote helper to interact with mercurial repositories. It allows to clone, pull and push from/to mercurial remote repositories, using git. Code on https://github.com/glandium/git-cinnabar This release on https://github.com/glandium/git-cinnabar/releases/tag/0.5.0b2

[PATCH v4 0/6] Add a FREE_AND_NULL() wrapper macro

I didn't know about the coccinelle semantic patch facility. This adds coccinelle rules to do the code changes, and adds subsequent follow-up commits which apply that change, with the series ending with a patch that I manually authored. This fixes a bug in earlier versions of the series. I was

[PATCH v4 2/6] coccinelle: add a rule to make "type" code use FREE_AND_NULL()

Signed-off-by: Ævar Arnfjörð Bjarmason --- contrib/coccinelle/free.cocci | 8 1 file changed, 8 insertions(+) diff --git a/contrib/coccinelle/free.cocci b/contrib/coccinelle/free.cocci index c03ba737e5..35fb992621 100644 --- a/contrib/coccinelle/free.cocci +++

[PATCH v4 4/6] coccinelle: add a rule to make "expression" code use FREE_AND_NULL()

A follow-up to the existing "type" rule added in an earlier change. This catches some occurrences that are missed by the previous rule. Signed-off-by: Ævar Arnfjörð Bjarmason --- contrib/coccinelle/free.cocci | 7 +++ 1 file changed, 7 insertions(+) diff --git

Re: Which hash function to use, was Re: RFC: Another proposed hash function transition plan

On Fri, Jun 16, 2017 at 01:36:13AM +0200, Ævar Arnfjörð Bjarmason wrote: > On Fri, Jun 16, 2017 at 12:41 AM, brian m. carlson > wrote: > > SHA-256 acceleration exists for some existing Intel platforms already. > > However, they're not practically present on anything

Re: [PATCH v2 4/4] sha1_file, fsck: add missing blob support

Jonathan Tan writes: > There is indeed no reason why we need to keep multiple ones separate for > an extended period of time - my thinking was to let fetch/clone be fast > by not needing to scan through the entire existing manifest (in order to > create the new one),

Re: [PATCH v3 0/6] config.h

Brandon Williams writes: > On 06/15, Junio C Hamano wrote: > >> ... so please eyeball the resulting 12 patches carefully when >> they are pushed out. > > Ugh, I'm terribly sorry. Completely my bad as I didn't consider what > you would need to do on your end. When I built my

Re: [PATCH v2 0/3] Add regression tests for rectent rebase -i fixes

Junio C Hamano writes: > Phillip Wood writes: > >> From: Phillip Wood >> >> I've revised the second two tests as Johannes suggested to drop the >> sed script. The first one is unchanged. >> >> Phillip Wood (3): >>

[suggestion] Include commit-ish in git status output

Hello all, I hope it is not considered too forward of me for my first post to this list to be a suggestion on a change to git’s behavior (though not in any functional manner); but a persistent frustration for me and everyone I’ve worked with (so, yes, 100% based off of anecdata) has been that the

Best practices for updating old repos

Hi All -- I'm working with code that is based on a five year old repository. There are 130 local commits since the repo was forked. Naturally, the upstream project has moved on significantly. I'm wondering about best approaches to updating the repo to the current upstream version. Here are

[PATCH v3 1/2] git-compat-util: add a FREE_AND_NULL() wrapper around free(ptr); ptr = NULL

Add a FREE_AND_NULL() wrapper marco for the common pattern of freeing a pointer and assigning NULL to it right afterwards. The implementation is similar to the (currently unused) XDL_PTRFREE macro in xdiff/xmacros.h added in commit 3443546f6e ("Use a *real* built-in diff generator", 2006-03-24).

[PATCH v3 0/2] Add a FREE_AND_NULL() wrapper macro

On Thu, Jun 15 2017, Ævar Arnfjörð Bjarmason jotted: > I'll change it to FREE_AND_NULL and submit my patch as-is, my reading > of the rest of this thread is that making it a function instead of a > macro would be interesting, but has its own caveats that are likely > better considered as part of

Re: [suggestion] Include commit-ish in git status output

On Thu, Jun 15, 2017 at 7:43 PM, Mahmoud Al-Qudsi wrote: > Hello all, > > I hope it is not considered too forward of me for my first post to this list > to be a suggestion on a change to git’s behavior (though not in any > functional manner); but a persistent frustration for

Re: [suggestion] Include commit-ish in git status output

On Thu, Jun 15, 2017 at 6:55 PM, Samuel Lijin wrote: > > Can you elaborate on why you consider this useful specifically? Personally, primary usages of the current commit-ish info are to file bug reports that include the specific git revision of any given branch that a bug was

Re: [WIP v2 2/2] pack-objects: support --blob-max-bytes

On Thu, 15 Jun 2017 16:28:24 -0400 Jeff Hostetler wrote: > I agree with Peff here. I've been working on my partial/narrow/sparse > clone/fetch ideas since my original RFC and have come to the conclusion > that the server can do the size limiting efficiently, but we

Re: [PATCH v5 00/10] The final building block for a faster rebase -i

Johannes Schindelin writes: > Changes since v4: > > - replaced the "sha1s" part of the names by "ids", to reflect the > current effort to move away from the cryptographically unsafe SHA-1 > > - replaced the confusing term "instruction sheet" in an error message by >

Re: Which hash function to use, was Re: RFC: Another proposed hash function transition plan

On Fri, Jun 16, 2017 at 12:41 AM, brian m. carlson wrote: > On Thu, Jun 15, 2017 at 02:59:57PM -0700, Adam Langley wrote: >> (I was asked to comment a few points in public by Jonathan.) >> >> I think this group can safely assume that SHA-256, SHA-512, BLAKE2, >> K12,

[PATCH v3 2/4] sha1_file: move delta base cache code up

In a subsequent patch, packed_object_info() will be modified to use the delta base cache, so move the relevant code to before packed_object_info(). Signed-off-by: Jonathan Tan --- sha1_file.c | 220 ++-- 1 file

Re: Which hash function to use, was Re: RFC: Another proposed hash function transition plan

On Thu, Jun 15, 2017 at 09:01:45AM -0400, Jeff King wrote: > On Thu, Jun 15, 2017 at 08:05:18PM +0900, Mike Hommey wrote: > > > On Thu, Jun 15, 2017 at 12:30:46PM +0200, Johannes Schindelin wrote: > > > Footnote *1*: SHA-256, as all hash functions whose output is essentially > > > the entire

  1   2   >