Re: [PATCH v4] technical doc: add a design doc for hash function transition

Jonathan Nieder writes: > +Signed Tags > +~~~ > +We add a new field "gpgsig-newhash" to the tag object format to allow > +signing tags without relying on SHA-1. Its signed payload is the > +newhash-content of the tag with its gpgsig-newhash field and "-BEGIN PGP >

Re: [PATCH v16 1/6] bisect--helper: use OPT_CMDMODE instead of OPT_BOOL

Hey Junio, On Tue, Oct 3, 2017 at 9:21 AM, Junio C Hamano wrote: > Ramsay Jones writes: > >> On 02/10/17 14:44, Pranit Bauva wrote: >> [snip] >>>... >> Yes, I also meant to tidy that up by removing some, now >> redundant, initialisation later in

Re: [PATCH v3 1/5] test-list-objects: List a subset of object ids

Derrick Stolee writes: > Subject: Re: [PATCH v3 1/5] test-list-objects: List a subset of object ids Style nit: s/List/list/; > > Signed-off-by: Derrick Stolee This should stick to the left hand side. No need to resend, only to fix these two,

Re: [PATCH v2] request-pull: capitalise "Git" to make it a proper noun

Jonathan Nieder writes: > Ann T Ropea wrote: > >> Of the many ways to spell the three-letter word, the variant "Git" >> should be used when referring to a repository in a description; or, in >> general, when it is used as a proper noun. >> >> We thus change the pull-request

[PATCH 2/2] colors: git_default_config() does not read color.ui

As we reverted 136c8c8b ("color: check color.ui in git_default_config()", 2017-07-13), these need to be added back to the codebase so that "git tag --list" and "git for-each-ref" would still pay attention to color.ui setting. A real fix to the problem introduced by 4c7f1819 ("make color.ui

[PATCH 0/2] fixing "add -p" regression

We were a bit too agressive in pushing color.ui configuration to plumbing commands. A real fix must be found to override the default "auto" use of colors for any color-capable plumbing commands, but let's leave that to a later round and concentrate on fixing the regression first. Junio C Hamano

[PATCH 1/2] Revert "color: check color.ui in git_default_config()"

This reverts commit 136c8c8b8fa39f1315713248473dececf20f8fe7. Even though we do want to fix the fallout from 4c7f1819 ("make color.ui default to 'auto'", 2013-06-10), which made it impossible to override it with "git -c color.ui={never,always} $plumbing", allowing the plumbing commands to pay

Re: [PATCH v16 1/6] bisect--helper: use OPT_CMDMODE instead of OPT_BOOL

Ramsay Jones writes: > On 02/10/17 14:44, Pranit Bauva wrote: > [snip] >>... > Yes, I also meant to tidy that up by removing some, now > redundant, initialisation later in that function. > > Note, that wasn't the only bug! (I have probably forgotten > some of them,

Re: [PATCH v2] ref-filter.c: pass empty-string as NULL to atom parsers

On Tue, Oct 03, 2017 at 08:55:01AM +0900, Junio C Hamano wrote: > Jonathan Nieder writes: > > > The above does a nice job of explaining > > > > - what this change is going to do > > - how it's good for the internal code structure / maintainability > > > > What it doesn't

Re: Updated to v2.14.2 on macOS; git add --patch broken

Junio C Hamano writes: > In any case, I think the first step may be to revert 136c8c8b from > both 'master' and 2.14.x. These alternative solutions can come on > top. > > Thoughts? With the attached patch, after reverting 136c8c8b ("color: check color.ui in

Re: Updated to v2.14.2 on macOS; git add --patch broken

Junio C Hamano writes: > Jonathan Nieder writes: > >> Yet another alternative would be to treat color.ui=always as a >> deprecated synonym for color.ui=auto. I think that's my preferred >> fix. > > It is mine, too. And I do not think

Re: [PATCH 00/24] object_id part 10

On Mon, Oct 02, 2017 at 04:34:44PM -0700, Stefan Beller wrote: > On Sun, Oct 1, 2017 at 3:08 PM, brian m. carlson > wrote: > > I apologize for the unintended bounced emails that occurred in late > > August; my mail server (previously hosted at home) got knocked

Re: [PATCH 04/24] refs: convert update_ref and refs_update_ref to use struct object_id

On Mon, Oct 02, 2017 at 03:37:38PM -0700, Stefan Beller wrote: > > diff --git a/bisect.c b/bisect.c > > index 96beeb5d13..e8470a2e0f 100644 > > --- a/bisect.c > > +++ b/bisect.c > > @@ -685,11 +685,13 @@ static int bisect_checkout(const struct object_id > > *bisect_rev, int no_checkout) > >

Re: Updated to v2.14.2 on macOS; git add --patch broken

Jonathan Nieder writes: > Yet another alternative would be to treat color.ui=always as a > deprecated synonym for color.ui=auto. I think that's my preferred > fix. It is mine, too. And I do not think color.ui=absolutely-always for those who want to keep the current

Re: Security of .git/config and .git/hooks

Jonathan Nieder writes: > Proposed fix: because of case (1), I would like a way to tell Git to > stop trusting any files in .git. That is: > > 1. Introduce a (configurable) list of "safe" configuration items that > can be set in .git/config and don't respect any others.

Re: [PATCH v3] clang-format: add a comment about the meaning/status of the

On 02/10/17 18:21, Brandon Williams wrote: > On 10/02, Junio C Hamano wrote: >> From: Stephan Beyer >> >> Having a .clang-format file in a project can be understood in a way that >> code has to be in the style defined by the .clang-format file, i.e., you >> just have to run

Re: [idea] File history tracking hints

Jeff Hostetler writes: >> How do you know when a guid needs adaption? > > I'm not sure I know what you mean by "adaption". I think he meant adapting, and I think he is referring to what I wrote in the message upthread to explain why "file ID" would not help. It seems to

Re: [PATCH v16 1/6] bisect--helper: use OPT_CMDMODE instead of OPT_BOOL

On 02/10/17 14:44, Pranit Bauva wrote: [snip] >> Look for []-ed comments in the commit messages for a note of >> the changes I made to your original patches, in patches #2, >> #4, #7-9, #11-12 and #14. >> >> The commits I added, which are just WIP, are as follows: >> >> $ git log --oneline

Re: [idea] File history tracking hints

Stefan Beller writes: > I have rethought about the idea of GUIDs as proposed by Jeff and wanted > to give a reply. After rereading this message, I think my thoughts are > already included via: > > - you're doing the work at the wrong point for _another_ reason. You're >

Re: [PATCH v2] request-pull: capitalise "Git" to make it a proper noun

Ann T Ropea wrote: > Of the many ways to spell the three-letter word, the variant "Git" > should be used when referring to a repository in a description; or, in > general, when it is used as a proper noun. > > We thus change the pull-request template message so that it reads > >"...in the Git

Re: [PATCH v2] setup: update error message to be more meaningful

Kaartic Sivaraam writes: > Incorrect case, > > $ git grep "some random regex" -n > fatal: bad flag '-n' used after filename > > The above case is incorrect as "some random regex" isn't a filename > in this case. The command line rule is to have dashed

Re: [PATCH v2] branch: change the error messages to be more meaningful

Kaartic Sivaraam writes: > I was recently searching to find the patches have gone missing in to > the void for no obvious reason and found this. Should I consider this > to be "Dropped" in terms of the "What's cooking" emails? or has this > just not received the

Dearest

Dearest, I am Mrs. Asana Hajraf and I am married to Mr. Hassan Hajraf from kuwait for 19 years without a child and my husband died in 2014. I am contacting you to let you know my desire to donate the sum of $4.5 million to charities in your country which I inherited from my late husband. Due to

Re: [PATCH v2] request-pull: capitalise "Git" to make it a proper noun

Of the many ways to spell the three-letter word, the variant "Git" should be used when referring to a repository in a description; or, in general, when it is used as a proper noun. We thus change the pull-request template message so that it reads "...in the Git repository at:" Besides, this

Re: What means "git config bla ~/"?

Jonathan Nieder writes: >> what's with that "git config bla ~/"? is this some config keyword >> or something? > ... > > I agree with you that it is less clear than it could be. Ideas for > clarifying it? Yeah, if it were git config section.var ~/some/thing that

Re: [PATCH v2] ref-filter.c: pass empty-string as NULL to atom parsers

Jonathan Nieder writes: > The above does a nice job of explaining > > - what this change is going to do > - how it's good for the internal code structure / maintainability > > What it doesn't tell me about is why the user-facing effect won't > cause problems. Is there no

Re: [PATCH 0/3] Comment fixes

On 09/26, Han-Wen Nienhuys wrote: > follow more commit log conventions; verified it compiled (yay). > > (should I send patches that are in 'pu' again as well?) > > Han-Wen Nienhuys (3): > real_path: clarify return value ownership > read_gitfile_gently: clarify return value ownership. >

Re: [PATCH v2] oidmap: map with OID as key

On 09/29, Jonathan Tan wrote: > This is similar to using the hashmap in hashmap.c, but with an > easier-to-use API. In particular, custom entry comparisons no longer > need to be written, and lookups can be done without constructing a > temporary entry structure. > > This is implemented as a thin

Security of .git/config and .git/hooks

Hi, This topic has been mentioned on this mailing list before but I had trouble finding a relevant reference. Links welcome. Suppose that I add the following to .git/config in a repository on a shared computer: [pager] log = rm -fr / fsck = rm -fr /

Re: [PATCH v6 7/7] ref-filter.c: parse trailers arguments with %(contents) atom

Taylor Blau writes: > Thank you for pointing this out. I should have run "make test" on this > patch set (or, as you suggested, `git rebase -x "make test" HEAD~7`) > before sending it out. I appreciate you catching my mistake, and I'll > make sure to run "make test" more

Re: [PATCH 00/24] object_id part 10

On Sun, Oct 1, 2017 at 3:08 PM, brian m. carlson wrote: > This is the tenth in a series of patches to convert from unsigned char > [20] to struct object_id. This series mostly involves changes to the > refs code. After these changes, there are almost no references

Re: [PATCH 00/24] object_id part 10

On 10/01, brian m. carlson wrote: > This is the tenth in a series of patches to convert from unsigned char > [20] to struct object_id. This series mostly involves changes to the > refs code. After these changes, there are almost no references to > unsigned char in the main refs code. > > I've

Re: [PATCH 15/24] refs: convert read_ref_at to struct object_id

On 10/01, brian m. carlson wrote: > Convert the callers and internals, including struct read_ref_at_cb, of > read_ref_at to use struct object_id. > > Signed-off-by: brian m. carlson > --- > builtin/show-branch.c | 5 ++--- > refs.c| 34

Re: [PATCH 13/24] builtin/pack-objects: convert to struct object_id

> @@ -2520,17 +2521,17 @@ static void read_object_list_from_stdin(void) > continue; > } > if (line[0] == '-') { > - if (get_sha1_hex(line+1, sha1)) > + if (get_oid_hex(line+1, )) >

Re: [PATCH] PR msg: capitalise "Git" to make it a proper noun

Hi, Thanks for working to improve Git! Bedhanger wrote: > Subject: [PATCH] PR msg: capitalise "Git" to make it a proper noun nit: What is a PR msg? Looking with "git log git-request-pull.sh", I see that previous patches called the subsystem request-pull, so this could be

Re: [PATCH 04/24] refs: convert update_ref and refs_update_ref to use struct object_id

On 10/01, brian m. carlson wrote: > Convert update_ref, refs_update_ref, and write_pseudoref to use struct > object_id. Update the existing callers as well. Remove update_ref_oid, > as it is no longer needed. > > Signed-off-by: brian m. carlson > --- > bisect.c

Re: [PATCH 06/24] Convert check_connected to use struct object_id

On Sun, Oct 1, 2017 at 3:08 PM, brian m. carlson wrote: > Convert check_connected and the callbacks it takes to use struct > object_id. > > diff --git a/connected.c b/connected.c > index f416b05051..4a47f33270 100644 > --- a/connected.c > +++ b/connected.c > @@

Re: Updated to v2.14.2 on macOS; git add --patch broken

Hi, Toni Uebernickel wrote: > I updated to git version v2.14.2 on macOS using homebrew. > > Since then `git add --patch` and `git stash save --patch` are not > working anymore. It's just printing the complete diff without ever > stopping to ask for actions. This results in an unusable state, as

Re: hooks are ignored if there are not marked as executable

Hi Damien, Damien wrote: > If you do `echo my_script > .git/hooks/pre-commit` and then `git commit`, > The hook is just gonna be ignored. > But if you do `chmod +x .git/hooks/pre-commit`, then it's executed. This is intentional. > I think ignoring a hook is misleading and not newbie friendly,

Re: [PATCH v2] ref-filter.c: pass empty-string as NULL to atom parsers

Hi, Taylor Blau wrote: > Peff points out that different atom parsers handle the empty > "sub-argument" list differently. An example of this is the format > "%(refname:)". > > Since callers often use `string_list_split` (which splits the empty > string with any delimiter as a 1-ary string_list

Re: [PATCH 04/24] refs: convert update_ref and refs_update_ref to use struct object_id

> diff --git a/bisect.c b/bisect.c > index 96beeb5d13..e8470a2e0f 100644 > --- a/bisect.c > +++ b/bisect.c > @@ -685,11 +685,13 @@ static int bisect_checkout(const struct object_id > *bisect_rev, int no_checkout) > char bisect_rev_hex[GIT_MAX_HEXSZ + 1]; > > memcpy(bisect_rev_hex,

Re: git submodule add fails when using both --branch and --depth

Hi, Thadeus Fleming wrote: > I'm running git 2.14.2 on Ubuntu 16.04. > > Compare the behavior of > >> git clone --branch pu --depth 1 https://github.com/git/git git-pu > > which clones only the latest commit of the pu branch and Yes. >> mkdir tmp && cd tmp && git init >> git submodule add

Re: [idea] File history tracking hints

On 10/2/2017 3:18 PM, Stefan Beller wrote: On Mon, Oct 2, 2017 at 11:51 AM, Jeff Hostetler wrote: Sorry to re-re-...-re-stir up such an old topic. I wasn't really thinking about commit-to-commit hints. I think these have lots of problems. (If commit A->B does "t/*

Re: git submodule add fails when using both --branch and --depth

On Sat, Sep 30, 2017 at 10:20 AM, Thadeus Fleming wrote: > I'm running git 2.14.2 on Ubuntu 16.04. > > Compare the behavior of > >> git clone --branch pu --depth 1 https://github.com/git/git git-pu > > which clones only the latest commit of the pu branch and > >>

Re: [PATCH] ref-filter.c: pass empty-string as NULL to atom parsers

On Mon, Oct 02, 2017 at 09:12:58AM -0700, Taylor Blau wrote: > > I know this is getting _really_ subjective, but IMHO this is a lot more > > reasoning than the comment needs. The commit message goes into the > > details of the "why", but here I'd have just written something like: > > > > /*

Re: [PATCH v2] ref-filter.c: pass empty-string as NULL to atom parsers

On Mon, Oct 02, 2017 at 09:10:34AM -0700, Taylor Blau wrote: > Peff points out that different atom parsers handle the empty > "sub-argument" list differently. An example of this is the format > "%(refname:)". > > Since callers often use `string_list_split` (which splits the empty > string with

Re: [PATCH v4] technical doc: add a design doc for hash function transition

On Fri, Sep 29, 2017 at 10:34:13AM -0700, Jonathan Nieder wrote: > Junio C Hamano wrote: > > Jonathan Nieder writes: ... > > If it is a goal to eventually be able to lose SHA-1 compatibility > > metadata from the objects, then we might want to remove SHA-1 based > > signature

Re: RFC v3: Another proposed hash function transition plan

On Mon, Oct 02, 2017 at 10:18:02AM -0700, Linus Torvalds wrote: > On Mon, Oct 2, 2017 at 7:00 AM, Jason Cooper wrote: > > > > Ahhh, so if I understand you correctly, you'd prefer SHA-256 over > > SHA3-256 because it's more performant for your usecase? Well, that's a > >

Re: [PATCH v4] technical doc: add a design doc for hash function transition

Hi Jonathan, On Wed, Sep 27, 2017 at 09:43:21PM -0700, Jonathan Nieder wrote: > This document describes what a transition to a new hash function for > Git would look like. Add it to Documentation/technical/ as the plan > of record so that future changes can be recorded as patches. > > Also-by:

Re: [PATCH] tag: avoid NULL pointer arithmetic

On Mon, Oct 02, 2017 at 03:06:57PM +0200, René Scharfe wrote: > >> Avoid the ASan error by casting the results of the lookup functions to > >> struct object pointers. That works fine with NULL pointers as well. We > >> already rely on the object member being first in all object types in > >>

Re: [PATCH 2/2] run-command: use ALLOC_ARRAY

On Sun, Oct 1, 2017 at 8:14 AM, René Scharfe wrote: > Use the macro ALLOC_ARRAY to allocate an array. This is shorter and > eaasier, as it automatically infers the size of elements. easier Thanks, Stefan

Re: [idea] File history tracking hints

On Mon, Oct 2, 2017 at 11:51 AM, Jeff Hostetler wrote: > Sorry to re-re-...-re-stir up such an old topic. > > I wasn't really thinking about commit-to-commit hints. > I think these have lots of problems. (If commit A->B does > "t/* -> tests/*" and commit B->C does

Re: git add -p stops working when setting color.ui = always

Hi, On 10/02, Tsvi Mostovicz wrote: > Hi, > > When setting "color.ui = always" in the last few versions (not sure > exactly when this started, but definitely exists in 2.14.1 and > 2.14.2), git add -p stops working as expected. Instead of prompting > the user, it skips through the prompts and

Re: [idea] File history tracking hints

On 10/2/2017 1:41 PM, Stefan Beller wrote: It would be nice if every file (and tree) had a permanent GUID associated with it. Then the filename/pathname becomes a property of the GUIDs. Then you can exactly know about moves/renames with minimal effort (and no guessing). ...

Re: [idea] File history tracking hints

>> It would be nice if every file (and tree) had a permanent GUID >> associated with it. Then the filename/pathname becomes a property >> of the GUIDs. Then you can exactly know about moves/renames with >> minimal effort (and no guessing). > ... >

[PATCH v2] setup: update error message to be more meaningful

From: Kaartic Sivaraam The error message shown when a flag is found when expecting a filename wasn't clear as it didn't communicate what was wrong using the 'suitable' words in *all* cases. $ git ls-files README.md test-file Correct case,

Re: [PATCH v3] clang-format: add a comment about the meaning/status of the

On 10/02, Junio C Hamano wrote: > From: Stephan Beyer > > Having a .clang-format file in a project can be understood in a way that > code has to be in the style defined by the .clang-format file, i.e., you > just have to run clang-format over all code and you are set. > > This

Re: [PATCH v2/RFC] commit: change the meaning of an empty commit message

On Thu, 2017-08-31 at 19:06 +0530, Kaartic Sivaraam wrote: > On Thu, 2017-08-24 at 13:19 -0700, Junio C Hamano wrote: > > > > The latter is easier for me as we do not have to worry about > > breaking people's scripts and tools used in > > their established workflows at all. > > > > In that

Re: [PATCH v2] branch: change the error messages to be more meaningful

On Mon, 2017-08-21 at 19:06 +0530, Kaartic Sivaraam wrote: > The error messages shown when the branch command is misused > by supplying it wrong number of parameters wasn't meaningful. > That's because it used the the phrase "too many branches" > assuming all parameters to be "valid" branch names.

Re: RFC v3: Another proposed hash function transition plan

On Mon, Oct 2, 2017 at 7:00 AM, Jason Cooper wrote: > > Ahhh, so if I understand you correctly, you'd prefer SHA-256 over > SHA3-256 because it's more performant for your usecase? Well, that's a > completely different animal that cryptographic suitability. In almost all

Re: [PATCH v3] clang-format: add a comment about the meaning/status of the

Hi, On 10/02/2017 01:37 AM, Junio C Hamano wrote: > diff --git a/.clang-format b/.clang-format > index 56822c116b..7670eec8df 100644 > --- a/.clang-format > +++ b/.clang-format > @@ -1,4 +1,8 @@ > -# Defaults > +# This file is an example configuration for clang-format 5.0. > +# > +# Note that

Re: What means "git config bla ~/"?

Hi, rpj...@crashcourse.ca wrote: > i'm sure i'm about to embarrass myself but, in "man git-config", > OPTIONS, one reads: > > --path > > git-config will expand leading ~ to the value of $HOME, and ~user > to the home directory for the specified user. This option has no > effect when setting

Re: [PATCH 0/4] pre-merge hook

On Sun, Oct 1, 2017 at 10:54 PM, Junio C Hamano wrote: > Michael J Gruber writes: > >> Now that f8b863598c ("builtin/merge: honor commit-msg hook for merges", >> 2017-09-07) has landed, merge is getting closer to behaving like commit, >> which is important

Re: RFC v3: Another proposed hash function transition plan

On 10/02, Jason Cooper wrote: > Hi Jonathan, > > On Tue, Sep 26, 2017 at 04:51:58PM -0700, Jonathan Nieder wrote: > > Johannes Schindelin wrote: > > > On Tue, 26 Sep 2017, Jason Cooper wrote: > > >> For my use cases, as a user of git, I have a plan to maintain provable > > >> integrity of

Re: [PATCH] ref-filter.c: pass empty-string as NULL to atom parsers

On Mon, Oct 02, 2017 at 02:43:35AM -0400, Jeff King wrote: > On Sun, Oct 01, 2017 at 10:53:11PM -0700, Taylor Blau wrote: > > > Peff points out that different atom parsers handle the empty > > "sub-argument" list differently. An example of this is the format > > "%(refname:)". > > > > Since

[PATCH v2] ref-filter.c: pass empty-string as NULL to atom parsers

Peff points out that different atom parsers handle the empty "sub-argument" list differently. An example of this is the format "%(refname:)". Since callers often use `string_list_split` (which splits the empty string with any delimiter as a 1-ary string_list containing the empty string), this

Re: [PATCH v6 0/7] Support %(trailers) arguments in for-each-ref(1)

On Mon, Oct 02, 2017 at 09:15:00PM +0900, Junio C Hamano wrote: > Junio C Hamano writes: > > > Thanks. t6300 seems to show that %(contents:trailers:unfold) does > > not quite work, among other things. > > > > https://travis-ci.org/git/git/jobs/282126607#L3658 > > > > I

Re: [PATCH v6 7/7] ref-filter.c: parse trailers arguments with %(contents) atom

On Mon, Oct 02, 2017 at 02:51:00AM -0400, Jeff King wrote: > > diff --git a/ref-filter.c b/ref-filter.c > > index 43ed10a5e..6c26b4733 100644 > > --- a/ref-filter.c > > +++ b/ref-filter.c > > @@ -212,9 +212,10 @@ static void contents_atom_parser(const struct > > ref_format *format, struct used_at

Re: RFC v3: Another proposed hash function transition plan

Hi Jonathan, On Tue, Sep 26, 2017 at 04:51:58PM -0700, Jonathan Nieder wrote: > Johannes Schindelin wrote: > > On Tue, 26 Sep 2017, Jason Cooper wrote: > >> For my use cases, as a user of git, I have a plan to maintain provable > >> integrity of existing objects stored in git under sha1 while

[PATCH v3 0/5] Improve abbreviation disambituation

Thanks for the feedback on my previous versions, and for patience with my inexperience on the mailing list. I tried to respond to all feedback, but decided to not apply one suggestion: * Removed the "sort -R" from p0008-abbrev.sh, since it is a GNU- specific flag. The perf test now considers

[PATCH v3 3/5] sha1_name: Unroll len loop in find_unique_abbrev_r

Unroll the while loop inside find_unique_abbrev_r to avoid iterating through all loose objects and packfiles multiple times when the short name is longer than the predicted length. Instead, inspect each object that collides with the estimated abbreviation to find the longest common prefix.

[PATCH v3 4/5] sha1_name: Parse less while finding common prefix

Create get_hex_char_from_oid() to parse oids one hex character at a time. This prevents unnecessary copying of hex characters in extend_abbrev_len() when finding the length of a common prefix. p0008.1: find_unique_abbrev() for existing objects --

[PATCH v3 5/5] sha1_name: Minimize OID comparisons during disambiguation

Minimize OID comparisons during disambiguatiosn of packfile OIDs. Teach git to use binary search with the full OID to find the object's position (or insertion position, if not present) in the pack-index. The object before and immediately after (or the one at the insertion position) give the

[PATCH v3 2/5] p0008-abbrev.sh: Test find_unique_abbrev() perf

Create helper program test-abbrev to compute the minimum length of a disambiguating short-sha for an input list of object ids. Perf test p0008-abbrev.sh runs test-abbrev for 100,000 object ids. For test 0008.1, these objects exist. For test 0008.2 these objects do not exist in the repo (with high

[PATCH v3 1/5] test-list-objects: List a subset of object ids

Create test-list-objects helper program to output a random sample of OIDs present in the repo. If no command line arguments are provided, all OIDs are output. The last command line argument specifies how many samples to output. Samples are collected across the entire set of available OIDs to

Re: [PATCH v2 4/5] sha1_name: Parse less while finding common prefix

My v3 patch is incoming, but I wanted to respond directly to this message. On 9/25/2017 7:42 PM, Stefan Beller wrote: On Mon, Sep 25, 2017 at 2:54 AM, Derrick Stolee wrote: Create get_hex_char_from_oid() to parse oids one hex character at a time. This prevents

Re: [PATCH v6 09/40] Add initial external odb support

On 9/29/2017 4:36 PM, Jonathan Tan wrote: On Wed, 27 Sep 2017 18:46:30 +0200 Christian Couder wrote: I am ok to split the patch series, but I am not sure that 01/40 to 09/40 is the right range for the first patch series. I would say that 01/40 to 07/40 is better

Re: RFC v3: Another proposed hash function transition plan

Hi Joan, On Sun, 1 Oct 2017, Joan Daemen wrote: > On 30/09/17 00:33, Johannes Schindelin wrote: > > > As far as Git is concerned, we not only care about the source code of > > the hash algorithm we use, we need to care even more about what you > > call "executable": ready-to-use, high quality,

Re: [PATCH v6 00/40] Add initial experimental external ODB support

On 9/16/2017 4:06 AM, Christian Couder wrote: Highlevel view of the patches in the series ~~~ This is a massive patch series and IMO keeping it a single monolithic set of patches makes it difficult to review and unwieldy to make progress on as an

Re: What means "git config bla ~/"?

[When I try to reply to rpj...@crashcourse.ca then my SMTP server says "Requested action not taken: mailbox unavailable invalid DNS MX or A/ resource record.", so I'm replying only to the list.] Am 02.10.2017 um 12:13 schrieb rpj...@crashcourse.ca: > i'm sure i'm about to embarrass myself

Re: RFC v3: Another proposed hash function transition plan

Hi Johannes, Thanks for the response. Sorry for the delay. Had a large deadline for $dayjob. On Wed, Sep 27, 2017 at 12:11:14AM +0200, Johannes Schindelin wrote: > On Tue, 26 Sep 2017, Jason Cooper wrote: > > On Thu, Sep 14, 2017 at 08:45:35PM +0200, Johannes Schindelin wrote: > > > On Wed, 13

[PATCH 2/3] for-each-ref: let upstream/push optionally report merge name.

From: J Wyman There are times when scripts want to know not only the name of the push branch on the remote, but also the name of the branch as known by the remote repository. A useful example of this is with the push command where `branch..merge` is useful as the value.

[PATCH 3/3] for-each-ref: test :remote-name and :remote-ref

This not only prevents regressions, but also serves as documentation what this new feature is expected to do. Signed-off-by: Johannes Schindelin --- t/t6300-for-each-ref.sh | 32 1 file changed, 32 insertions(+) diff --git

[PATCH 1/3] for-each-ref: let upstream/push optionally report the remote name

There are times when e.g. scripts want to know not only the name of the upstream branch on the remote repository, but also the name of the remote. This patch offers the new suffix :remote for the upstream and for the push atoms, allowing to show exactly that. Example: $ cat .git/config

[PATCH 0/3] for-each-ref: add :remote-ref and :remote-name specifiers

This introduces support for git for-each-ref \ --format="%(merge:remote-name),%(merge:remote-ref)" git for-each-ref \ --format="%(push:remote-name),%(push:remote-ref)" to figure out the remote nickname as well as the name of the corresponding

Re: [PATCH v16 1/6] bisect--helper: use OPT_CMDMODE instead of OPT_BOOL

Hey Ramsay, On Sat, Sep 30, 2017 at 6:29 PM, Ramsay Jones wrote: > Hi Pranit, > > Just before Junio dropped your 'pb/bisect' branch from his > repository (and What's cooking), I fetched it locally with > the intention of finishing it off. (It would have been silly >

Re: [PATCH] tag: avoid NULL pointer arithmetic

Am 02.10.2017 um 07:08 schrieb Jeff King: > On Sun, Oct 01, 2017 at 04:45:13PM +0200, René Scharfe wrote: > >> lookup_blob() etc. can return NULL if the referenced object isn't of the >> expected type. In theory it's wrong to reference the object member in >> that case. In practice it's OK

Re: [PATCH v6 0/7] Support %(trailers) arguments in for-each-ref(1)

Junio C Hamano writes: > Thanks. t6300 seems to show that %(contents:trailers:unfold) does > not quite work, among other things. > > https://travis-ci.org/git/git/jobs/282126607#L3658 > > I didn't have a chance to look into it myself. Peff's "oops, your logic is backwards"

Re: What's cooking in git.git (Sep 2017, #06; Fri, 29)

Martin Ågren writes: > On 29 September 2017 at 06:34, Junio C Hamano wrote: >> >> * sd/branch-copy (2017-09-24) 4 commits >> (merged to 'next' on 2017-09-28 at a6eceefa02) >> + branch: fix "copy" to never touch HEAD >> + branch: add a --copy (-c)

Loan

UNSECURED BUSINESS/PERSONAL LOAN BY LOAN CAPITAL FINANCE - NO COLLATERAL - MINIMUM DOCUMENTATION - BUSINESS LOAN UP TO FIVE(5) MILLION US DOLLARS CONTACT US TODAY VIA EMAIL: financecapital...@mail.com

new contributors presentation

Hi all, me and my two other partner (Daniel and Timothee) have make the choice to contribute to gitHub for a university project supervised by Mattieu Moy. The principal project is to improve the git-send-email function, for example we will try to implement the possibility to answer to a email by

Inquiry

Sir/Madam, I've visited your website and I find your products very interested at the first sight to create its place. To go to the next step which concern the marketing Please kindly send me your latest catalogue's product and please send us your prices CIF, to start presentation in order to

git add -p stops working when setting color.ui = always

Hi, When setting "color.ui = always" in the last few versions (not sure exactly when this started, but definitely exists in 2.14.1 and 2.14.2), git add -p stops working as expected. Instead of prompting the user, it skips through the prompts and doesn't allow selecting a hunk. Don't know why I

Re: What's cooking in git.git (Sep 2017, #06; Fri, 29)

On 29 September 2017 at 06:34, Junio C Hamano wrote: > > * sd/branch-copy (2017-09-24) 4 commits > (merged to 'next' on 2017-09-28 at a6eceefa02) > + branch: fix "copy" to never touch HEAD > + branch: add a --copy (-c) option to go with --move (-m) > + branch: add test for

Re: [PATCH] builtin/: add UNLEAKs

On 2 October 2017 at 08:25, Jeff King wrote: > On Sun, Oct 01, 2017 at 07:42:08PM +0200, Martin Ågren wrote: > >> Add some UNLEAKs where we are about to return from `cmd_*`. UNLEAK the >> variables in the same order as we've declared them. While addressing >> `msg` in

Re: [PATCH 00/11] various lockfile-leaks and -fixes

On 2 October 2017 at 08:30, Junio C Hamano wrote: > Jeff King writes: > >> I've read through each and with the exception of patches 10 and 11, they >> all look good to me. >> >> For 10 and 11, I think you've convinced me that the current behavior is >> buggy. I

Re: [PATCH 09/11] read-cache: require flags for `write_locked_index()`

On 2 October 2017 at 06:14, Martin Ågren wrote: > On 2 October 2017 at 05:49, Junio C Hamano wrote: >> Martin Ågren writes: >> >>> ... Instead, require that one of the >>> flags is set. Adjust documentation and the assert we

Re: [PATCH 01/11] sha1_file: do not leak `lock_file`

On 2 October 2017 at 07:26, Jeff King wrote: > On Sun, Oct 01, 2017 at 04:56:02PM +0200, Martin Ågren wrote: > > The original code is actually a bit confusing/unsafe, as we set the > "found" flag early and rollback here: > >> @@ -481,17 +481,15 @@ void add_to_alternates_file(const

What means "git config bla ~/"?

i'm sure i'm about to embarrass myself but, in "man git-config", OPTIONS, one reads: --path git-config will expand leading ~ to the value of $HOME, and ~user to the home directory for the specified user. This option has no effect when setting the value (but you can use git config

hooks are ignored if there are not marked as executable

Hi, If you do `echo my_script > .git/hooks/pre-commit` and then `git commit`, The hook is just gonna be ignored. But if you do `chmod +x .git/hooks/pre-commit`, then it's executed. I think ignoring a hook is misleading and not newbie friendly, an error message to signal an incorrectly configured

  1   2   >