Jeff King writes:
> Out of curiosity, do you frequently test with GETTEXT_POISON, or did you
> just guess at a potential problem after reading the tests? Proper use
> of test_i18ncmp is definitely something we ought to be looking for
> during review, but I confess it's something I often miss.
I
On Tue, Oct 03, 2017 at 03:24:41PM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > Since that's the only thing I noticed, let's hold off on a reroll for
> > the moment to see if there are any more comments (and I won't be
> > surprised if Junio just picks it up with the tweak, but we'll s
On Mon, Oct 2, 2017 at 4:18 PM, Ben Peart wrote:
>
> On 9/16/2017 4:06 AM, Christian Couder wrote:
>
> - Patch 1/40 is a small code cleanup that I already sent to the
>>
>>mailing list but may be removed in the end due to ongoing work
>>on "git clone".
>>
>> - Patches 02
On Mon, Oct 02, 2017 at 04:48:48PM -0700, Brandon Williams wrote:
> > Some replies to v1 [1] [2] seem to indicate that simpler non-duplicated
> > code should be preferred over optimizing away the storage of the 4-byte
> > hash code, and I have no objection to that, so I have updated this code
> >
Jeff King writes:
> Since that's the only thing I noticed, let's hold off on a reroll for
> the moment to see if there are any more comments (and I won't be
> surprised if Junio just picks it up with the tweak, but we'll see).
>
> Please do make sure that "make test" runs clean before posting (I
Martin Ågren writes:
> On 2 October 2017 at 08:30, Junio C Hamano wrote:
> ...
>> Thanks, both. Let's merge this to 'next' soonish.
>
> Thanks both of you for your comments. Based on them, I have made the
> following notes:
> ...
> Especially 9-11 make me feel like wanting to re-roll this, for
Martin Ågren writes:
>> Seeing hunks like this makes me happy with the UNLEAK() solution. It
>> would have been a real pain to do this via actual freeing.
>
> Yes, I was very happy to have it handy. :-)
OK, let's merge this to 'next', then.
On Fri, Sep 29, 2017 at 10:11 PM, Jonathan Tan wrote:
> These patches are also available online:
> https://github.com/jonathantanmy/git/commits/partialclone3
>
> (I've announced it in another e-mail, but am now sending the patches to the
> mailing list too.)
>
> Here's an update of my work so far.
On Tue, Oct 03, 2017 at 11:25:44AM +0900, Junio C Hamano wrote:
> 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, t
Junio C Hamano writes:
> Michael J Gruber writes:
>
>> I'm still trying to understand what the original intent was: If we
>> abstract from the implementation (as we should, as you rightly
>> emphasize) and talk about historical tips then we have to ask ourselves:
>> - What is "historical"?
>> -
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
> +SIGNATURE-" del
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 that function.
>>
>> Note, that wasn't the only bu
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, as I'll tweak them when
queuing.
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 template message so th
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
default
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 (
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 atte
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, but look at 964f4e2b0, for exam
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 tell me about is why the
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 git_default_config()", 2017-07-13) fr
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 color.ui=absolutely-always for
> those who want to keep the
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 offline
> > because I was without In
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)
> >
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 behaviour is unneeded.
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.
The list of "safe"
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 clang-format over all
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 me, from reading the rem
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 bise
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
> freezing your (crap
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
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 options first and then other
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 required attention?
I do not even
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
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
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 would be far clearer th
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 atom where %(atom:) wa
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.
> stri
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
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 /
("rm
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 diligently in the future
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 to
> unsigned char in the main
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 tr
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 +-
> refs.
> @@ -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, &oid))
>
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
request-pull:
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 | 6 --
>
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
> @@ -16,13 +16,13 @@
> *
> * Return
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
>
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, a
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 con
> 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,
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 --bra
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/* -> tests/*" and commit B-
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
>
>> mkdir tmp && cd tmp && git init
>>
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:
> >
> > /* trea
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 an
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 bits (e.g. PGP traile
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
> > completely different anim
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: B
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
> >> oth
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
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 "test/*.c -> xyx/*",
> then you
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 doe
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).
...
https://publi
>> 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).
>
...
> https://public-inbox.org/git/pine.lnx.4.58.05041
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,
$ git rev-parse README.
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 unfortunately is n
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 case
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.
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 loads I've seen, zlib inf
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 this
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 t
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 because both are used to complete merges
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 existing
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 callers
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 make
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 didn't have a chance to l
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
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 migr
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 obj
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.
p0008.
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
--
Fo
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 maximu
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
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 avoi
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 unnecessary copying of hex charac
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 as it can be seen as a
separa
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, w
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 "a
[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 b
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
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. Example:
$ git
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 a/t/t6300-for-each-ref.sh b/t/t6300-for
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
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
branch
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
> to waste all your good work).
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 becau
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" fixes the above fai
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) option to go with --move (-m)
>> + branch: a
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
1 - 100 of 119 matches
Mail list logo
