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
> @@
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,
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
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
> @@ -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, ))
>
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
>
>>
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
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/*
> 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 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,
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
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
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
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 /
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
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.
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
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
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.
>
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
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
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)
> >
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
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,
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
>
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
>
On Sun, Oct 01, 2017 at 04:56:10PM +0200, Martin Ågren wrote:
> `write_locked_index()` takes two flags: `COMMIT_LOCK` and `CLOSE_LOCK`.
> At most one is allowed. But it is also possible to use no flag, i.e.,
> `0`. But when `write_locked_index()` calls `do_write_index()`, the
> temporary file,
On Sun, Oct 01, 2017 at 04:56:11PM +0200, Martin Ågren wrote:
> If `do_write_index(..., struct tempfile *, ...)` fails to close the
> temporary file, it deletes it. This resets the pointer to NULL, but only
> the pointer which is local to `do_write_index()`, not the pointer that
> the caller
On Sun, Oct 01, 2017 at 04:56:01PM +0200, Martin Ågren wrote:
> A recent series allowed `struct lock_file`s to be freed [1], so I wanted
> to get rid of the "simple" leaks of this kind. I found a couple of
> lock-related cleanups along the way and it resulted in this series. It
> feels a bit
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 often use `string_list_split` (which splits the empty
> string with
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 do wonder if the subtleties might be easier to understand as a
> single patch,
On Mon, Oct 02, 2017 at 02:15:30AM -0400, Jeff King wrote:
> I'm not sure I follow here. It seems like write_locked_index() has three
> outcomes:
>
> - if there was an error, the lock is rolled back
>
> - if we were successful and the caller asked for CLOSE_LOCK, we remain
> locked
>
>
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 builtin/tag.c, convert the existing `strbuf_release()` calls as
> well.
It
Taylor Blau writes:
> Attached is the sixth revision of my patch-set "Support %(trailers)
> arguments in for-each-ref(1)".
>
> In includes the following changes since v5:
>
> * Added an additional patch to change t4205 to harden `unfold()`
> against multi-line trailer
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
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
Hi,
I installed git for windows 2.14.2 (64bit) and was trying to clone a
repository from a command terminal (cmd.exe):
git clone https://netzeb...@bitbucket.org/Netzeband/deep-speeddreams.git
First everything went well, but after the repository was downloaded the
LFS download started. At
Jonathan Nieder writes:
> +Reading an object's sha1-content
> +
> +The sha1-content of an object can be read by converting all newhash-names
> +its newhash-content references to sha1-names using the translation table.
Sure.
> +Fetch
> +~
Dear Sir
Please find the attached copy of Purchase order with the item details
and confirm with us immediately
Thank you
Aldaz
<>
On Sat, Sep 30, 2017 at 09:09:11PM +0300, Оля Тележная wrote:
> I added "v2" after "PATCH", but it does not appeared. Actually it was
> written automatically and it was "PATCH Outreachy v2". I rearranged it
> in the middle of the phrase.
That looks fine.
> > I'm not sure what you mean about
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
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
On Sun, Oct 01, 2017 at 10:23:26PM -0700, Taylor Blau wrote:
> Attached is the sixth revision of my patch-set "Support %(trailers)
> arguments in for-each-ref(1)".
>
> In includes the following changes since v5:
>
> * Added an additional patch to change t4205 to harden `unfold()`
>
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
>> Simplify mru.[ch] and related code by reusing the double-linked list
>> implementation from list.h instead of a custom one.
>> This commit is an intermediate step. Our final goal is to get rid of
>> mru.[ch] at all and inline all logic.
>
> Thanks, this version looks correct to me.
Great! What
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
Jonathan Nieder writes:
>>> +6. Skip fetching some submodules of a project into a NewHash
>>> + repository. (This also depends on NewHash support in Git
>>> + protocol.)
>>
>> It is unclear what this means. Around submodule support, one thing
>> I can think of is that a
Jeff King writes:
>> atom->u.contents.option = C_SUB;
>> -else if (!strcmp(arg, "trailers"))
>> -atom->u.contents.option = C_TRAILERS;
>> -else if (skip_prefix(arg, "lines=", )) {
>> +else if (skip_prefix(arg, "trailers", )) {
>> +
On Sun, Oct 01, 2017 at 10:25:24PM -0700, Taylor Blau wrote:
> The %(contents) atom takes a contents "field" as its argument. Since
> "trailers" is one of those fields, extend contents_atom_parser to parse
> "trailers"'s arguments when used through "%(contents)", like:
>
>
On Sat, Sep 30, 2017 at 05:51:01PM +, Olga Telezhnaya wrote:
> Simplify mru.[ch] and related code by reusing the double-linked list
> implementation from list.h instead of a custom one.
> This commit is an intermediate step. Our final goal is to get rid of
> mru.[ch] at all and inline all
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
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
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.
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
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
>
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
[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
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,
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
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
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
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
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
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"
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
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)
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
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 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
--
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
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
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
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
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.
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
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
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).
...
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
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
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
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
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
1 - 100 of 118 matches
Mail list logo