On Mon, Mar 26, 2018 at 3:14 AM, Joel Teichroeb wrote:
> Signed-off-by: Joel Teichroeb
The commit message in this patch and the following ones could be a bit
more verbose. It could at least tell that the end goal is to convert
git-stash.sh to a C builtin.
> +static void destroy_stash_info(struc
This small patch series makes it easy to spot big performance
regressions, so that they can later be investigated.
For example:
$ ./aggregate.perl --sort-by=regression --subsection "without libpcre" v2.14.3
v2.15.1 v2.16.2 p4220-log-grep-engines.sh
+5.0% p4220-log-grep-engines.2 0.60(0.58+0.02)
One of the most interesting thing one can be interested in when
looking at performance test results is possible performance
regressions.
This new option makes it easy to spot such possible regressions.
This new option is named '--sort-by=regression' to make it
possible and easy to add other ways
On Sun, Mar 25, 2018 at 12:15:42AM -0700, Jacob Keller wrote:
> > 3. Drop "-l" (probably with a deprecation period); it seems unlikely
> > to me that anybody uses it for branch creation, and this would at
> > least reduce the confusion (then it would just be "so why don't we
> > h
This new helper function will be reused in a subsequent
commit.
Signed-off-by: Christian Couder
---
t/perf/aggregate.perl | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/t/perf/aggregate.perl b/t/perf/aggregate.perl
index 821cf1498b..890d85fa7b 100755
--- a/t/perf
This test checks that the "-l" option creates a reflog. But
in fact we'd create one even without it, since the default
in a non-bare repository is to do so. Let's unset the config
so we can be sure our "-l" option is kicking in.
Note that we can't do this with test_config, since that
would leave t
In preparation for deprecating "-l", let's make sure we're
using the recommended option ourselves.
This patch just mechanically converts "branch -l" to "branch
--create-reflog". Note that with the exception of the
actual "--create-reflog" test, we could actually remove "-l"
entirely from most of
We marked the "-l" option as deprecated back in . Now that sufficient time has passed, let's follow
through and get rid of it.
Signed-off-by: Jeff King
---
I'll need some help from the maintainer on the commit message. :)
builtin/branch.c | 15 ---
1 file changed, 15 deletions(-)
d
The "-l" option is short for "--create-reflog". This has
caused much confusion over the years. Most people expect it
to work as "--list", because that would match the other
"mode" options like -d/--delete and -m/--move, as well as
the similar -l/--list option of git-tag.
Adding to the confusion, u
The other "mode" options of git-branch have short-option
aliases that are easy to type (e.g., "-d" and "-m"). Let's
give "--list" the same treatment.
This also makes it consistent with the similar "git tag -l"
option.
We didn't do this originally because "--create-reflog" was
squatting on the "-l
Am Wes ze Stanów Zjednoczonych, ale obecnie przebywa w Syrii na misji
pokojowej. Obecnie szukam przyjaźni, która doprowadzi do związku, w którym
znowu czuję się kochana ...
Chcę cię lepiej poznać, jeśli mogę być odważny. Uważam się za łatwego człowieka
..
Proszę wybaczyć moje manie
On Mon, Mar 26, 2018 at 3:25 AM, Jeff King wrote:
> OK, so here's some patches. We could do the first three now, wait a
> while before the fourth, and then wait a while (or never) on the fifth.
>
> [1/5]: t3200: unset core.logallrefupdates when testing reflog creation
> [2/5]: t: switch "branc
Am Wes ze Stanów Zjednoczonych, ale obecnie przebywa w Syrii na misji
pokojowej. Obecnie szukam przyjaźni, która doprowadzi do związku, w którym
znowu czuję się kochana ...
Chcę cię lepiej poznać, jeśli mogę być odważny. Uważam się za łatwego człowieka
..
Proszę wybaczyć moje manie
On Fri, Mar 23, 2018 at 10:40:34PM +, Aaron Greenberg wrote:
> I updated the commit message to include my first email's cover letter
> and cleaned up the test.
Thanks. This one looks good to me.
> I can appreciate Matthieu's points on the use of "-" in destructive
> commands. As of this writ
On Fri, Mar 23, 2018 at 08:55:53PM -0400, Taylor Blau wrote:
> This commit (and those following it in this series) aim to eventually
> replace `--get-color` with a consistent alternative. By introducing
> `--default`, we allow the `--get-color` action to be promoted to a
> `--color` type specifier
On Fri, Mar 23, 2018 at 08:55:54PM -0400, Taylor Blau wrote:
> The documentation for the `git-config(1)` builtin has not been recently
> updated to include new types, such as `--bool-or-int`, and
> `--expiry-date`. To ensure completeness when adding a new type
> specifier, let's update the existin
On Fri, Mar 23, 2018 at 08:55:56PM -0400, Taylor Blau wrote:
> As of this commit, the canonical way to retreive an ANSI-compatible
> color escape sequence from a configuration file is with the
> `--get-color` action.
s/retreive/retrieve/
> This is to allow Git to "fall back" on a default value f
On Fri, Mar 23, 2018 at 08:55:52PM -0400, Taylor Blau wrote:
> Attached is 'v2' of my patch series to add a `--default` option to `git
> config`.
Thanks, this is looking much better. I did come up with a few
suggestions/fixes. Some minor which would make v3 easy, and some that
would require expa
Add a tlsv1.3 option to http.sslVersion in addition to the existing
tlsv1.[012] options. libcurl has supported this since 7.52.0.
Signed-off-by: Loganaden Velvindron
---
Documentation/config.txt | 1 +
http.c | 3 +++
2 files changed, 4 insertions(+)
diff --git a/Documentation
If I have a .mailmap file containing
Me brendanator
And I run
git log --author=Me
I see all my commits
However if I run
git shortlog --author=Me
my commits are not shown
Hi Git team,
I have a query.
Scenario:
Currently there are two main branches that we are utilizing A(master) and
B(branch of A). Branch is utilised for individual stories(as per delivery).
When branch is utilised since the team size is huge the number of changes/
branches created for differen
On Mon, Mar 26, 2018 at 10:12:04AM +, shirlin.jos...@bt.com wrote:
[...]
> Currently there are two main branches that we are utilizing A(master)
> and B(branch of A). Branch is utilised for individual stories(as per
> delivery).
[...]
Cross-posted to [1] as well.
1. https://groups.google.com
Hi Sergey,
On Mon, 12 Mar 2018, Sergey Organov wrote:
> [...]
>
> Yet another consequence is that my approach will likely result in better
> code reuse.
This is a purely academic speculation. At least until somebody implements
Phillip's method. Oh wait, I already started to implement it, and it
Hi Sergey,
On Mon, 12 Mar 2018, Sergey Organov wrote:
> Johannes Schindelin writes:
> >
> > On Wed, 7 Mar 2018, Sergey Organov wrote:
> >
> >> Johannes Schindelin writes:
> >>
> >> > How can your approach -- which relies *very much* on having the
> >> > original parent commits -- not *require*
Hi Sergey,
On Mon, 12 Mar 2018, Sergey Organov wrote:
> Johannes Schindelin writes:
> > Hi Sergey,
>
> [...]
>
> > That is misrepresenting what happened.
>
> No, it's you who are spreading misinformation, probably unintentional,
> but still.
Way to go, Sergey. Way to go.
> [... more of the
On Fri, Mar 23, 2018 at 6:35 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>> I'd say we should just add !GETTEXT_POISON prereq to the problematic
>> tests.
> IOW, this is the minumum required.
Thanks for already committing the fix, I couldn't get around to it.
> By the way, shouldn't we
Commit ea3c87d0b7 (test_must_be_empty: make sure the file exists, not
just empty, 2018-02-27) basically duplicated the 'test_path_is_file'
helper function in 'test_must_be_empty'.
Just call 'test_path_is_file' to avoid this code duplication.
Signed-off-by: SZEDER Gábor
---
t/test-lib-functions.
Hi Buga,
On Tue, 13 Mar 2018, Igor Djordjevic wrote:
> On 12/03/2018 13:56, Sergey Organov wrote:
> >
> > > > I agree with both of you that `pick ` is inflexible
> > > > (not to say just plain wrong), but I never thought about it like
> > > > that.
> > > >
> > > > If we are to extract further me
Thanks for Cc-ing me, and sorry for not being very responsive these
days :-\.
Jeff King writes:
> On Fri, Mar 23, 2018 at 10:40:34PM +, Aaron Greenberg wrote:
>
>> I can appreciate Matthieu's points on the use of "-" in destructive
>> commands. As of this writing, git-merge supports the "-" s
Prior to
9308b7f3ca read_packed_refs(): die if `packed-refs` contains bogus data,
2017-07-01
we silently ignored pretty much any bogus data in a `packed-refs`
file. I think that was pretty clearly a bad policy. The above commit
made parsing quite a bit stricter, calling `die()` if it found a
Prior to
9308b7f3ca read_packed_refs(): die if `packed-refs` contains bogus data,
2017-07-01
we silently ignored any lines in a `packed-refs` file that we didn't
understand. That policy was clearly wrong.
But at the time, unrecognized header lines were processed by the same
code as referenc
Hi Sergey,
On Mon, 12 Mar 2018, Sergey Organov wrote:
> Johannes Schindelin writes:
>
> > [...]
> >
> > Where "easy" meant that I had to spend 1h still to figure out why
> > using the unrebased merge parents as merge bases.
>
> That's because you try to figure out something that is not there i
On Mon, Mar 26, 2018 at 01:58:15PM +0200, SZEDER Gábor wrote:
> Commit ea3c87d0b7 (test_must_be_empty: make sure the file exists, not
> just empty, 2018-02-27) basically duplicated the 'test_path_is_file'
> helper function in 'test_must_be_empty'.
>
> Just call 'test_path_is_file' to avoid this c
On Mon, Mar 26, 2018 at 2:01 AM Junio C Hamano wrote:
> When testing the non-relocatable (i.e. traditional) Git, we use
> GIT_EXEC_PATH and bin-wrappers/ trick to ensure that we test the
> version we just have built, not a random version that happen to be
> on the $PATH, without requiring the bui
On Sun, Mar 25, 2018 at 5:15 PM Ævar Arnfjörð Bjarmason
wrote:
> This looks good to me this time around, couple of small nits (maybe
> Junio can amend while queuing):
> * You add a dependnecy typo in 2/3 but fix it again in 3/3. Should be
> squashed.
d'oh, I'll fix that in my local copy s
Hi Buga,
On Tue, 13 Mar 2018, Igor Djordjevic wrote:
> On 12/03/2018 11:46, Johannes Schindelin wrote:
> >
> > > Sometimes one just needs to read the manual, and I don`t really
> > > think this is a ton complicated, but just something we didn`t really
> > > have before (real merge rebasing), so
On 3/26/2018 8:42 AM, Michael Haggerty wrote:
[...]
But there might be some tools out in the wild that have been writing
broken headers. In that case, users who upgrade Git might suddenly
find that they can't read repositories that they could read before. In
fact, a tool that we wrote and use in
On Mon, Mar 26, 2018 at 2:48 PM, Jeff King wrote:
> On Mon, Mar 26, 2018 at 01:58:15PM +0200, SZEDER Gábor wrote:
>
>> Commit ea3c87d0b7 (test_must_be_empty: make sure the file exists, not
>> just empty, 2018-02-27) basically duplicated the 'test_path_is_file'
>> helper function in 'test_must_be_e
Commit 11395a3b4b (test_must_be_empty: make sure the file exists, not
just empty, 2018-02-27) basically duplicated the 'test_path_is_file'
helper function in 'test_must_be_empty'.
Just call 'test_path_is_file' to avoid this code duplication.
Signed-off-by: SZEDER Gábor
---
The only change is to
Hi Junio,
On Tue, 13 Mar 2018, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > If so, what tooling do you have to identify quickly what to
> > cherry-pick, given merge conflicts?
>
> It exactly is the issue I've been trying to find ideal solution for
> quite a while and not successfu
Hi Sergey,
On Wed, 14 Mar 2018, Sergey Organov wrote:
> Igor Djordjevic writes:
>
> > On 07/03/2018 08:26, Johannes Schindelin wrote:
>
> [...]
>
> >> Second side note: if we can fast-forward, currently we prefer that,
> >> and I think we should keep that behavior with -R, too.
> >
> > I agre
Am Wes ze Stanów Zjednoczonych, ale obecnie przebywa w Syrii na misji
pokojowej. Obecnie szukam przyjaźni, która doprowadzi do związku, w którym
znowu czuję się kochana ...
Chcę cię lepiej poznać, jeśli mogę być odważny. Uważam się za łatwego człowieka
..
Proszę wybaczyć moje manie
Hi Buga,
On Tue, 13 Mar 2018, Igor Djordjevic wrote:
> On 12/03/2018 11:20, Johannes Schindelin wrote:
> >
> > > > [...] and cannot introduce ambiguities when rebasing the
> > > > changes introduced by M (i.e. the "amendmendts" we talked about).
> > >
> > > Hmm, not following here, which ambigui
On Mon, Mar 26 2018, Daniel Jacques wrote:
> On Sun, Mar 25, 2018 at 5:15 PM Ævar Arnfjörð Bjarmason
> wrote:
>
>> This looks good to me this time around, couple of small nits (maybe
>> Junio can amend while queuing):
>
>> * You add a dependnecy typo in 2/3 but fix it again in 3/3. Should be
>
Hi Buga,
On Fri, 16 Mar 2018, Igor Djordjevic wrote:
> [...]
>
> Yes, having more steps would mean more power/options to the user, but
> more complexity to explain to and guide him through as well, not really
> sure where the line should be drawn - for the first time, at least.
If you want to av
From: Jeff Hostetler
This is version 4 of my JSON data format routines.
This version adds a "pretty" formatted output. I consider this to be
mainly for debugging, but worth keeping available in release builds.
I simplified the stack-level tracing as suggested by René Scharfe and
hinted at by P
From: Jeff Hostetler
Add a series of jw_ routines and "struct json_writer" structure to compose
JSON data. The resulting string data can then be output by commands wanting
to support a JSON output format.
The json-writer routines can be used to generate structured data in a
JSON-like format. W
On Mon, Mar 26, 2018 at 09:08:04AM -0400, Derrick Stolee wrote:
> Since most heavily-used tools that didn't spawn Git processes use LibGit2 to
> interact with Git repos, I added Ed Thomson to CC to see if libgit2 could
> ever write these bad header comments.
Ed can probably answer more definitive
On Mon, Mar 26, 2018 at 2:08 PM, Derrick Stolee wrote:
> Since most heavily-used tools that didn't spawn Git processes use
> LibGit2 to interact with Git repos, I added Ed Thomson to CC to see
> if libgit2 could ever write these bad header comments.
We added the `sorted` capability to our `packed
On Mon, Mar 26, 2018 at 10:08 AM Ævar Arnfjörð Bjarmason
wrote:
> > Oh sorry, I must have missed that. I have a personal preference for
adding
> > brackets for clarity; it leaked into this patch set. I did implement
most
> > of the suggestion, which was to use the escaped Q/E instead of equals.
>
On Sat, Mar 24, 2018 at 07:33:40AM +0100, Nguyễn Thái Ngọc Duy wrote:
> +unsigned long oe_get_size_slow(struct packing_data *pack,
> +const struct object_entry *e)
> +{
> + struct packed_git *p;
> + struct pack_window *w_curs;
> + unsigned char *buf;
> +
Hi Duy,
On Sat, 24 Mar 2018, Nguyễn Thái Ngọc Duy wrote:
> diff --git a/t/helper/test-tool.c b/t/helper/test-tool.c
> new file mode 100644
> index 00..c730f718ca
> --- /dev/null
> +++ b/t/helper/test-tool.c
> @@ -0,0 +1,27 @@
> +#include "git-compat-util.h"
> +#include "test-tool.h"
> +
>
Wink Saville writes:
> json-writer.c:123:38: error: format specifies type 'uintmax_t' (aka
> 'unsigned long') but the argument has type 'uint64_t' (aka 'unsigned
> long long') [-Werror,-Wformat]
>
> strbuf_addf(&jw->json, ":%"PRIuMAX, value);
> ~~
Hi Bryan,
On Fri, 23 Mar 2018, Bryan Turner wrote:
> On Fri, Mar 23, 2018 at 10:47 AM, Johannes Schindelin
> wrote:
> >
> > On Wed, 21 Mar 2018, Junio C Hamano wrote:
> >
> >> A release candidate Git v2.17.0-rc1 is now available for testing
> >> at the usual places. It is comprised of 493 non-m
g...@matthieu-moy.fr writes:
>> That said, I'd still be OK with it.
>
> I don't have objection either.
FWIW, I do not even buy the "destructive commands should force
spelling things out even more" argument in the first place.
$ git checkout somelongtopicname
$ work work work
$ git ch
This is pretty rough but I'd like to see how people feel about this
first.
I notice we have two places for command classification. One in
command-list.txt, one in __git_list_porcelain_commands() in
git-completion.bash. People who are following nd/parseopt-completion
probably know that I'm try to r
common-cmds.h is used to extract the list of common commands (by
group) and a one-line summary of each command. Some information is
dropped, for example command category or summary of other commands.
Update generate-cmdlist.sh to keep all the information. The extra info
will be used shortly.
Signe
Even if this is a hidden option, let's make it a bit more generic
since we're introducing more listing types.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
git.c | 7 +--
t/t0012-help.sh | 2 +-
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/git.c b/git.c
index ceaa58ef40
Signed-off-by: Nguyễn Thái Ngọc Duy
---
contrib/completion/git-completion.bash | 2 +-
git.c | 2 ++
help.c | 15 +++
help.h | 1 +
4 files changed, 19 insertions(+), 1 deletion(-)
dif
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/git-help.txt | 4 ++-
builtin/help.c | 6
help.c | 61 ++
help.h | 1 +
4 files changed, 71 insertions(+), 1 deletion(-)
diff --git a/Documentatio
This is useful for git-completion.bash because it needs this set of
commands. Right now we have to maintain a separate command category in
there.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
contrib/completion/git-completion.bash | 94 ++
git.c
On 3/26/2018 11:56 AM, Junio C Hamano wrote:
Wink Saville writes:
json-writer.c:123:38: error: format specifies type 'uintmax_t' (aka
'unsigned long') but the argument has type 'uint64_t' (aka 'unsigned
long long') [-Werror,-Wformat]
strbuf_addf(&jw->json, ":%"PRIuMAX, value);
This moves the reusable parts of the memory pool logic used by
fast-import.c into its own file for use by other components.
Signed-off-by: Jameson Miller
---
Makefile | 1 +
fast-import.c | 70 +--
mem-pool.c| 55 +
Ramsay Jones writes:
>>> @@ -120,7 +120,7 @@ void jw_object_uint64(struct json_writer *jw, const
>>> char *key, uint64_t value)
>>> maybe_add_comma(jw);
>>>
>>> append_quoted_string(&jw->json, key);
>>> - strbuf_addf(&jw->json, ":%"PRIuMAX, value);
>>> + strbuf_addf(&jw->json, ":%"
Changes from v2:
- Code Review Reactions
- Lifetime management functions for mem_pool will be included in
future patch series
This patch series extracts the memory pool implementation, currently
used by fast-import, into a generalized component. This memory pool
can then be generally u
On Mon, Mar 26, 2018 at 5:13 PM, Jeff King wrote:
> On Sat, Mar 24, 2018 at 07:33:40AM +0100, Nguyễn Thái Ngọc Duy wrote:
>
>> +unsigned long oe_get_size_slow(struct packing_data *pack,
>> +const struct object_entry *e)
>> +{
>> + struct packed_git *p;
>> + stru
This is part of a patch series to extract the memory pool logic in
fast-import into a more generalized version. The existing mem_pool type
maps more closely to a "block of memory" (mp_block) in the more
generalized memory pool. This commit renames the mem_pool to mp_block to
reduce churn in future
Introduce the mem_pool type which encapsulates all the information
necessary to manage a pool of memory.This change moves the existing
variables in fast-import used to support the global memory pool to use
this structure.
These changes allow for the multiple instances of a memory pool to
exist and
On Mon, Mar 26, 2018 at 5:27 PM, Johannes Schindelin
wrote:
> Hi Duy,
>
> On Sat, 24 Mar 2018, Nguyễn Thái Ngọc Duy wrote:
>
>> diff --git a/t/helper/test-tool.c b/t/helper/test-tool.c
>> new file mode 100644
>> index 00..c730f718ca
>> --- /dev/null
>> +++ b/t/helper/test-tool.c
>> @@ -0,0
On 3/25/2018 6:58 PM, Ævar Arnfjörð Bjarmason wrote:
On Sat, Mar 10 2018, Alex Vandiver wrote:
New hash (Stefan, etc)
--
- discussed on the mailing list
- actual plan checked in to
Documentation/technical/hash-function-transition.txt
- lots of work renaming
- any
On Mon, Mar 26, 2018 at 1:03 PM, Jameson Miller wrote:
> Introduce the mem_pool type which encapsulates all the information
> necessary to manage a pool of memory.This change moves the existing
s/memory\.This/memory. This/
> variables in fast-import used to support the global memory pool to use
On 3/24/2018 2:38 PM, Wink Saville wrote:
Correct a compile error on Mac OSX by adding a cast to uintmax_t
in calls to strbuf_addf.
Helped-by: Ramsay Jones
Tested-by: travis-ci
Signed-off-by: Wink Saville
---
json-writer.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --
On 3/26/2018 1:04 PM, Junio C Hamano wrote:
Ramsay Jones writes:
@@ -120,7 +120,7 @@ void jw_object_uint64(struct json_writer *jw, const char
*key, uint64_t value)
maybe_add_comma(jw);
append_quoted_string(&jw->json, key);
- strbuf_addf(&jw->json, ":%"PRIuMAX, value);
+
On Fri, Mar 23, 2018 at 10:31 PM Duy Nguyen wrote:
> I got too excited when searching and replacing. Here's the fixup
> patch.
Thanks for picking up the series that I left unattended over the last weeks.
I have reviewed nd/remove-ignore-env-field as well as sb/object-store
as currently queued an
On Mon, Mar 26, 2018 at 10:33 AM Jeff Hostetler
wrote:
> On 3/25/2018 6:58 PM, Ævar Arnfjörð Bjarmason wrote:
> >
> > On Sat, Mar 10 2018, Alex Vandiver wrote:
> >
> >> New hash (Stefan, etc)
> >> --
> >> - discussed on the mailing list
> >> - actual plan checked in to
D
Jeff Hostetler writes:
> I defined that routine to take a uint64_t because I wanted to
> pass a nanosecond value received from getnanotime() and that's
> what it returns.
Hmph, but the target format does not have different representation
of inttypes in different sizes, no?
I personally doubt
Jeff Hostetler writes:
> I am concerned that the above compiler error message says that uintmax_t
> is defined as an "unsigned long" (which is defined as *at least* 32 bits,
> but not necessarily 64. But a uint64_t is defined as a "unsigned long long"
> and guaranteed as a 64 bit value.
On a pl
On 03/26, Jeff Hostetler wrote:
>
>
> On 3/25/2018 6:58 PM, Ævar Arnfjörð Bjarmason wrote:
> >
> > On Sat, Mar 10 2018, Alex Vandiver wrote:
> >
> > > New hash (Stefan, etc)
> > > --
> > > - discussed on the mailing list
> > > - actual plan checked in to
> > > Documenta
Stefan Beller writes:
> Thanks for driving this when I was away!
>
> With the fixup patch, both series are
> Reviewed-by: Stefan Beller
I think everybody involved agrees that these two you cited above are
already in good shape. Let's have them in 'next' for the remainder
of this cycle and go i
On 3/26/2018 1:57 PM, Junio C Hamano wrote:
Jeff Hostetler writes:
I defined that routine to take a uint64_t because I wanted to
pass a nanosecond value received from getnanotime() and that's
what it returns.
Hmph, but the target format does not have different representation
of inttypes in
Attempt to clarify what the SHAttered attack means in practice for
Git. The previous version of the text made no mention whatsoever of
Git already having a mitigation for this specific attack, which the
SHAttered researchers claim will detect cryptanalytic collision
attacks.
I may have gotten some
Change the "Repository format extension" to accurately describe what
happens with different versions of Git when they encounter NewHash
repositories, instead of only saying what happens with versions v2.7.0
and later.
See ab9cb76f66 ("Repository format version check.", 2005-11-25) and
00a09d57eb (
Having read through the hash-function-transition.txt again, a couple
of things jumped out at me:
Ævar Arnfjörð Bjarmason (2):
doc hash-function-transition: clarify how older gits die on NewHash
We weren't accurately describing how "git status" would die on NewHash
repos on new versions.
doc
On Sat, Mar 24, 2018 at 4:15 AM Christian Couder
wrote:
> Hi,
> On Sat, Mar 24, 2018 at 9:41 AM, Pratik Karki
wrote:
> >
> > Hi Christian and Johannes,
> >
> > Though I sent a mail earlier, saying I would like to submit another
> > proposal, I am now skeptical on re-writing another proposal as
On 3/26/2018 2:00 PM, Junio C Hamano wrote:
Jeff Hostetler writes:
I am concerned that the above compiler error message says that uintmax_t
is defined as an "unsigned long" (which is defined as *at least* 32 bits,
but not necessarily 64. But a uint64_t is defined as a "unsigned long long"
a
On Mon, Mar 26, 2018 at 11:27 AM Ævar Arnfjörð Bjarmason
wrote:
> Having read through the hash-function-transition.txt again, a couple
> of things jumped out at me:
> Ævar Arnfjörð Bjarmason (2):
>doc hash-function-transition: clarify how older gits die on NewHash
> We weren't accurately de
On Mon, Mar 26, 2018 at 12:44 AM, Eric Sunshine wrote:
> On Mon, Mar 26, 2018 at 3:25 AM, Jeff King wrote:
>> OK, so here's some patches. We could do the first three now, wait a
>> while before the fourth, and then wait a while (or never) on the fifth.
>>
>> [1/5]: t3200: unset core.logallrefup
> I was just going by what the reported compiler error message was.
> It said that "unsigned long" didn't match the uint64_t variable.
> And that made me nervous.
>
> If all of the platforms we build on define uintmax_t >= 64 bits,
> then it doesn't matter.
>
> If we do have a platform where uintma
On 3/26/2018 1:56 PM, Stefan Beller wrote:
On Mon, Mar 26, 2018 at 10:33 AM Jeff Hostetler
wrote:
On 3/25/2018 6:58 PM, Ævar Arnfjörð Bjarmason wrote:
On Sat, Mar 10 2018, Alex Vandiver wrote:
New hash (Stefan, etc)
--
- discussed on the mailing list
- actual
On Sun, Mar 25, 2018 at 9:46 AM Junio C Hamano wrote:
> prashant Nidgunde writes:
> [cc: stefan, for his interest in improving 'git submodules']
> > Hello,
> >
> > I am new to this community ,so please ignore if I am asking anything
silly.
> >
> > Case :
> > Today when I built my submodule , a
On Mon, Mar 26, 2018 at 2:27 PM, Ævar Arnfjörð Bjarmason
wrote:
> Attempt to clarify what the SHAttered attack means in practice for
> Git. The previous version of the text made no mention whatsoever of
> Git already having a mitigation for this specific attack, which the
> SHAttered researchers c
Hi Eric,
On Sun, 25 Mar 2018, Eric Sunshine wrote:
> On Sat, Mar 24, 2018 at 2:23 PM, Paul-Sebastian Ungureanu
> wrote:
> > Currently, because git stash is not fully converted to C, I
> > introduced a new helper that will hold the converted commands.
> > ---
> > diff --git a/builtin/stash--helpe
Hi Joel,
On Sun, 25 Mar 2018, Joel Teichroeb wrote:
> Signed-off-by: Joel Teichroeb
I could imagine that the commit message would benefit from this body:
In preparation for converting the stash command incrementally to
a builtin command, this patch improves test coverage of the
Junio C Hamano writes:
> Stefan Beller writes:
>
>> Thanks for driving this when I was away!
>>
>> With the fixup patch, both series are
>> Reviewed-by: Stefan Beller
>
> I think everybody involved agrees that these two you cited above are
> already in good shape. Let's have them in 'next' for
Wink Saville writes:
> Should we add a "_Static_assert" that sizeof(uintmax_t) >= sizeof(uint64_t) ?
If that expression compiles, then both types are understood by the
platform. Because
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/stdint.h.html
tells us:
Greatest-width intege
Hi,
sorry for the late review, as I am pointed here indirectly via
https://public-inbox.org/git/xmqqy3iebpsw@gitster-ct.c.googlers.com/
On Fri, Mar 16, 2018 at 11:33 AM Nguyễn Thái Ngọc Duy
wrote:
> +LIMITATIONS
> +---
> +
> +This command could only handle 16384 existing pack files
Hi Ævar,
Ævar Arnfjörð Bjarmason wrote:
> It occurred to me recently that once we have such a layer it could be
> (ab)used with some relatively minor changes to do any arbitrary
> local-to-remote object content translation, unless I've missed something
> (but I just re-read hash-function-transiti
On 03/26, Johannes Schindelin wrote:
> Hi Eric,
>
> On Sun, 25 Mar 2018, Eric Sunshine wrote:
>
> > On Sat, Mar 24, 2018 at 2:23 PM, Paul-Sebastian Ungureanu
> > wrote:
> > > Currently, because git stash is not fully converted to C, I
> > > introduced a new helper that will hold the converted co
Ævar Arnfjörð Bjarmason writes:
> + * Doing `git log` on paths matching '*--helper.c' will show
> + incremental effort in the direction of moving existing shell
> + scripts to C.
It may be benefitial to remind readers of "--full-diff", e.g.
$ git log --full-diff --stat -p -- "${foo}--he
1 - 100 of 152 matches
Mail list logo
