On Mon, 21 May 2018, Jonathan Nieder wrote:
Looking at the code here, this succeeds if enough memory is available.
There is no check if the given parameter is part of
Curl_all_content_encodings();
By "this" are you referring to the preimage or the postimage? Are you
suggesting a change in gi
On 05/21/2018 08:10 PM, Derrick Stolee wrote:
> [...]
> In the Discussion section of the `git merge-base` docs [1], we have the
> following:
>
> When the history involves criss-cross merges, there can be more than
> one best common ancestor for two commits. For example, with this topology:
>
Junio C Hamano writes:
> Martin Ågren writes:
>
>> I've taken the six patches that Junio has queued and rebuilt the series
>> to get rid of the new and possibly bug-prone function that no-one uses
>> once the series is over.
>
> Hmph, this unfortunately depends on 'next', which means we cannot
>
"Robert P. J. Day" writes:
> why is there no mention of files ignored via a user's
> core.excludesFile configuration?
IIUC, core.excludesFile is a much much later invention made long
after everybody lost interest in updating "git clean", let alone its
documentation. The support for the config
Martin Ågren writes:
> I've taken the six patches that Junio has queued and rebuilt the series
> to get rid of the new and possibly bug-prone function that no-one uses
> once the series is over.
Hmph, this unfortunately depends on 'next', which means we cannot
merge it down to 'maint' later to f
On Mon, May 21, 2018 at 2:43 PM, Stefan Beller wrote:
> On Sun, May 20, 2018 at 3:50 AM, Martin Ågren wrote:
>> It is apparently undefined behavior to call `regfree()` on a regex where
>> `regcomp()` failed. [...]
>>
>> diff --git a/diffcore-pickaxe.c b/diffcore-pickaxe.c
>> @@ -215,7 +215,6 @@ s
Jonathan Nieder writes:
> My understanding was the same as Elijah's.
>
> I would be in favor of a patch that replaces the phrase "known to Git"
> in Git's documentation with something less confusing.
One possible twist I recall was that normally we only pay attention
to the index (i.e. the term
Jeff King writes:
>> I haven't really been following all of the discussion but from what I
>> can tell the point of this command is to generate a diff based on two
>> different versions of a series, so why not call it 'series-diff'? :)
>
> That's OK with me, though I prefer "range" as I think we
Johannes Schindelin writes:
>> In the picture, the three pre-context lines that are all indented by
>> a HT are prefixed by a SP, and that is prefixed by a '+' sign of the
>> outer diff.
>
> Yep, that's exactly it.
>
> The way tbdiff did it was to parse the diff and re-roll the coloring on
> its
Hi,
Stefan Beller wrote:
> On Mon, May 21, 2018 at 4:40 PM, Brandon Williams wrote:
>> Configure curl to accept all encoding which curl supports instead of
>> only accepting gzip responses.
>
> This partially reverts aa90b9697f9 (Enable info/refs gzip decompression
> in HTTP client, 2012-09-19),
These functions were added because processing of these conflicts needed
to be deferred until process_entry() in order to get D/F conflicts and
such right. The number of these has grown over time, and now include
some whose name is misleading:
* conflict_rename_normal() is for handling normal fil
handle_change_delete() has a block of code displaying one of four nearly
identical messages. Each contains about half a dozen variable interpolations,
which use nearly identical variables as well. Someone trying to parse this
may be slowed down trying to parse the differences and why they are her
Signed-off-by: Elijah Newren
---
merge-recursive.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index 35df695fa4..c430fd72bc 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -531,7 +531,7 @@ static void record_df_conflict_files
Various refactorings throughout the code have left lots of alignment
issues that were driving me crazy; fix them.
Acked-by: Johannes Schindelin
Signed-off-by: Elijah Newren
---
merge-recursive.c | 47 ---
1 file changed, 24 insertions(+), 23 deletions
We had an enum of rename types which included RENAME_DIR; this name felt
misleading since it was not about an entire directory but was a status for
each individual file add that occurred within a renamed directory.
Since this type is for signifying that the files in question were being
renamed due
This patch series contains several small code cleanups for merge-recursive.
I have removed a couple small cleanup chunks in order to avoid conflicts
with any other in-flight topics in pu (namely, nd/commit-util-to-slab and
sb/submodule-merge-in-merge-recursive). I may resend those later
separately
On 22/05/18 00:59, Junio C Hamano wrote:
> Ramsay Jones writes:
>
>> I strongly suspect that I haven't followed the discussion on
>> the list closely enough, but your 'ma/unpack-trees-free-msgs'
>> branch in 'pu', seems to define string_list_appendf() but then
>> never call it. This is despite
On Mon, May 21, 2018 at 4:40 PM, Brandon Williams wrote:
> Configure curl to accept all encoding which curl supports instead of
> only accepting gzip responses.
This partially reverts aa90b9697f9 (Enable info/refs gzip decompression
in HTTP client, 2012-09-19), as that specifically called out def
Hi,
Brandon Williams wrote:
> Subject: remote-curl: accept all encoding supported by curl
nit: s/encoding/encodings
> Configure curl to accept all encoding which curl supports instead of
> only accepting gzip responses.
Likewise.
> This is necessary to fix a bug when using an installation of
Ramsay Jones writes:
> I strongly suspect that I haven't followed the discussion on
> the list closely enough, but your 'ma/unpack-trees-free-msgs'
> branch in 'pu', seems to define string_list_appendf() but then
> never call it. This is despite commit 40ebd6c7b0 ("string-list:
> provide `string_
Hi Martin,
I strongly suspect that I haven't followed the discussion on
the list closely enough, but your 'ma/unpack-trees-free-msgs'
branch in 'pu', seems to define string_list_appendf() but then
never call it. This is despite commit 40ebd6c7b0 ("string-list:
provide `string_list_appendf()`", 201
Configure curl to accept compressed responses when using protocol v2 by
setting `CURLOPT_ENCODING` to "", which indicates that curl should send
an "Accept-Encoding" header with all supported compression encodings.
Signed-off-by: Brandon Williams
---
remote-curl.c | 1 +
1 file changed, 1 inserti
Configure curl to accept all encoding which curl supports instead of
only accepting gzip responses.
This is necessary to fix a bug when using an installation of curl which
doesn't support gzip. Since curl doesn't do any checking to verify that
it supports the encoding set when calling 'curl_easy_
On Mon, May 21, 2018 at 09:17:39AM -0400, Ben Peart wrote:
> Do you plan to update those tests that hard code the SHA of the index file
> itself? For example, t1700-split-index.sh has hard coded values for the SHA
> and currently only supports different hard coded values for V4 indexes vs
> others
Hi Jonathan,
On Mon, May 21, 2018 at 1:43 PM, Jonathan Tan wrote:
> I was thinking about fetch negotiation in some non-ideal situations
> (specifically, when the client repo contains two or more independent
> branches that meet only somewhere far in the past) and thought about
> skipping over int
On Mon, May 21, 2018 at 2:50 PM, Jeff King wrote:
> On Mon, May 21, 2018 at 11:33:11AM -0700, Elijah Newren wrote:
>
>> > In t6024-recursive-merge.sh, we have the following commit structure:
>> >
>> > # 1 - A - D - F
>> > # \ X /
>> > # B X
>> > # X \
>> > #
On Mon, May 21, 2018 at 2:54 PM, Jeff King wrote:
> Yes, I think this is clearly a case where all of the single merge-bases
> we could show are equally good. And I don't think we should promise to
> show a particular one, but I _do_ think it's friendly for us to have
> deterministic tie-breakers (
On Tue, May 22, 2018 at 12:09 AM, Luke Diamand wrote:
> On 21 May 2018 at 22:39, SZEDER Gábor wrote:
>>> diff --git a/t/t9832-unshelve.sh b/t/t9832-unshelve.sh
>
> ...
> ...
>
>>> +'
>>
>> This test fails on my box and on Travis CI (in all four standard Linux
>> and OSX build jobs) with:
>>
>>
Hello
Greetings to you please i have a business proposal for you contact me
for more detailes asap thanks.
Best Regards,
Miss.Zeliha ömer faruk
Esentepe Mahallesi Büyükdere
Caddesi Kristal Kule Binasi
No:215
Sisli - Istanbul, Turkey
On 21 May 2018 at 23:09, Luke Diamand wrote:
> On 21 May 2018 at 22:39, SZEDER Gábor wrote:
>>> diff --git a/t/t9832-unshelve.sh b/t/t9832-unshelve.sh
>
> ...
> ...
>
>>> +'
>>
>> This test fails on my box and on Travis CI (in all four standard Linux
>> and OSX build jobs) with:
>>
>> + cd /hom
On 21 May 2018 at 22:39, SZEDER Gábor wrote:
>> diff --git a/t/t9832-unshelve.sh b/t/t9832-unshelve.sh
...
...
>> +'
>
> This test fails on my box and on Travis CI (in all four standard Linux
> and OSX build jobs) with:
>
> + cd /home/szeder/src/git/t/trash directory.t9832-unshelve/cli
> + p
On Mon, May 21, 2018 at 02:10:54PM -0400, Derrick Stolee wrote:
> In the Discussion section of the `git merge-base` docs [1], we have the
> following:
>
> When the history involves criss-cross merges, there can be more than one
> best common ancestor for two commits. For example, with this to
On Mon, May 21, 2018 at 02:40:57PM -0700, Brandon Williams wrote:
> > > > Most fellow German software engineers (who seem to have a knack for
> > > > idiotically long variable/function names) would now probably suggest:
> > > >
> > > > git compare-patch-series-with-revised-patch-series
> >
On Mon, May 21, 2018 at 11:33:11AM -0700, Elijah Newren wrote:
> > In t6024-recursive-merge.sh, we have the following commit structure:
> >
> > # 1 - A - D - F
> > # \ X /
> > # B X
> > # X \
> > # 2 - C - E - G
> >
> > When merging F to G, there are two "be
On Mon, May 21, 2018 at 2:40 PM, Brandon Williams wrote:
revised-compare
>> >
>> > diff-revise
>
> I haven't really been following all of the discussion but from what I
> can tell the point of this command is to generate a diff based on two
> different versions of a series, so why not call it 's
On 05/21, Jeff King wrote:
> On Mon, May 21, 2018 at 10:56:47AM -0700, Stefan Beller wrote:
>
> > > It is very much about
> > > comparing two *ranges of* revisions, and not just any ranges, no. Those
> > > ranges need to be so related as to contain mostly identical changes.
> >
> > range-diff, eh
> diff --git a/t/t9832-unshelve.sh b/t/t9832-unshelve.sh
> new file mode 100755
> index 00..cca2dec536
> --- /dev/null
> +++ b/t/t9832-unshelve.sh
> @@ -0,0 +1,153 @@
> +#!/bin/sh
> +
> +last_shelved_change() {
> + p4 changes -s shelved -m1 | cut -d " " -f 2
> +}
> +
> +test_description
On Mon, May 21, 2018 at 04:54:24PM +0200, Martin Ågren wrote:
> That is, I've replaced the `string_list_appendf()`-patch with Junio's
> `argv_push*()`-patch, then squashed Junio's "redoing the 4/4"-patch into
> patch 4/4 -- with the exception of keeping the `memset(opts->msgs, ...)`
> which I susp
On Mon, May 21, 2018 at 12:41 PM, Jeff King wrote:
> On Mon, May 21, 2018 at 11:11:51AM -0700, Stefan Beller wrote:
>
>> Hi Jeff,
>>
>> On Fri, May 18, 2018 at 6:56 PM, Jeff King wrote:
>>
>> > @@ -2421,4 +2426,5 @@ void release_http_object_request(struct
>> > http_object_request *freq)
>> ..
>>
I was thinking about fetch negotiation in some non-ideal situations
(specifically, when the client repo contains two or more independent
branches that meet only somewhere far in the past) and thought about
skipping over intermediate commits, using exponentially larger skips as
we proceed, when gene
On Mon, May 21, 2018 at 10:56:47AM -0700, Stefan Beller wrote:
> > It is very much about
> > comparing two *ranges of* revisions, and not just any ranges, no. Those
> > ranges need to be so related as to contain mostly identical changes.
>
> range-diff, eh?
>
> > Most fellow German software engi
On Mon, May 21, 2018 at 11:11:51AM -0700, Stefan Beller wrote:
> Hi Jeff,
>
> On Fri, May 18, 2018 at 6:56 PM, Jeff King wrote:
>
> > @@ -2421,4 +2426,5 @@ void release_http_object_request(struct
> > http_object_request *freq)
> ..
> > + strbuf_release(&freq->tmpfile);
>
> Do we need an
On Sun, May 20, 2018 at 10:51 PM, Christian Couder
wrote:
> From: David Turner
>
> So that they work under alternate ref storage backends.
Sometimes I have a disconnect between the subject and the commit
message, (e.g. in an email reader the subject is not displayed accurately on
top of the mess
Hi Brandon,
>> One of the reviewers of the series questioned the overall goal of the
>> series as we want to move away from _die() in top level code but this
>> series moves more towards it.
>
> I've heard every once in a while that we want to move toward this but I
> don't believe there is an act
On Sun, May 20, 2018 at 2:12 PM, Thomas Gummerer wrote:
> We have multiple different variants of the error message we show to
> the user if 'read_cache' fails. The "Could not read index" variant we
> are using in 'rerere.c' is currently not used anywhere in translated
> form.
>
> As a subsequent
Derrick Stolee writes:
> Add test cases to t5318-commit-graph.sh that corrupt the commit-graph
> file and check that the 'git commit-graph verify' command fails. These
> tests verify the header and chunk information is checked carefully.
>
> Helped-by: Martin Ågren
> Signed-off-by: Derrick Stole
On 05/21, Stefan Beller wrote:
> On Fri, May 18, 2018 at 11:37 PM, Duy Nguyen wrote:
> > On Wed, May 16, 2018 at 03:21:09PM -0700, Stefan Beller wrote:
> >> A common pattern with the repo_read_index function is to die if the return
> >> of repo_read_index is negative. Move this pattern into a fun
Hi Thomas,
On Sun, May 20, 2018 at 10:45 AM, Thomas Gummerer wrote:
> On 05/16, Stefan Beller wrote:
>> By switching to repo_read_index_or_die, we'll get a slightly different
>> error message ("index file corrupt") as well as localization of it.
>
> Apart from the slightly different error message
On Sun, May 20, 2018 at 3:50 AM, Martin Ågren wrote:
> It is apparently undefined behavior to call `regfree()` on a regex where
> `regcomp()` failed. The language in [1] is a bit muddy, at least to me,
> but the clearest hint is this (`preg` is the `regex_t *`):
>
> Upon successful completion,
On Fri, May 18, 2018 at 11:37 PM, Duy Nguyen wrote:
> On Wed, May 16, 2018 at 03:21:09PM -0700, Stefan Beller wrote:
>> A common pattern with the repo_read_index function is to die if the return
>> of repo_read_index is negative. Move this pattern into a function.
>>
>> This patch replaces the ca
Hi,
On Mon, May 21, 2018 at 11:10 AM, Derrick Stolee wrote:
> Hello all,
>
> While working on the commit-graph feature, I made a test commit that sets
> core.commitGraph and gc.commitGraph to true by default AND runs 'git
> commit-graph write --reachable' after each 'git commit' command. This hel
On Mon, 21 May 2018, Elijah Newren wrote:
> > can anyone refresh my memory if that happened here, and whether
> > that was the consensus after the discussion was over?
>
> Perhaps this:
> https://public-inbox.org/git/EEC5BA1D5F274F02AE20FC269868FDEF@PhilipOakley/
> ?
yup, that's it, thanks.
r
On Mon, May 21, 2018 at 10:40 AM, Robert P. J. Day
wrote:
> On Mon, 21 May 2018, Elijah Newren wrote:
>
>> Hi Robert,
>>
>> I had always assumed prior to your email that 'known to Git' meant
>> 'tracked' or 'recorded in the index'...
>
> i *know* i've been in this discussion before,
https://pub
Hi,
Robert P. J. Day wrote:
> i did a quick search for that phrase in the current code base and
> came up with:
>
> builtin/difftool.c: /* The symlink is unknown to Git so read from
> the filesystem */
> dir.c:error("pathspec '%s' did not match any file(s) known to
>
On Mon, May 21, 2018 at 10:40 AM, Robert P. J. Day
wrote:
> On Mon, 21 May 2018, Elijah Newren wrote:
>
>> I had always assumed prior to your email that 'known to Git' meant
>> 'tracked' or 'recorded in the index'...
>
> i *know* i've been in this discussion before, but i don't remember
> where,
Hi Jeff,
On Fri, May 18, 2018 at 6:56 PM, Jeff King wrote:
> @@ -2421,4 +2426,5 @@ void release_http_object_request(struct
> http_object_request *freq)
..
> + strbuf_release(&freq->tmpfile);
Do we need an equivalent in release_http_pack_request as well?
Hello all,
While working on the commit-graph feature, I made a test commit that
sets core.commitGraph and gc.commitGraph to true by default AND runs
'git commit-graph write --reachable' after each 'git commit' command.
This helped me find instances in the test suite where the commit-graph
fea
On Mon, 21 May 2018, Jonathan Nieder wrote:
> Robert P. J. Day wrote:
> > On Mon, 21 May 2018, Elijah Newren wrote:
>
> >> Hi Robert,
> >>
> >> I had always assumed prior to your email that 'known to Git'
> >> meant 'tracked' or 'recorded in the index'...
> >
> > i *know* i've been in this discu
Hi Johannes,
>> (2) git diff --branch topic-v1...topic-v2
>
> From my point of view, `git diff --branch` indicates that I diff
> *branches*. Which is not really something that makes sense, and definitely
> not what this command is about.
>
> We are not comparing branches.
>
> We are comparing vers
Robert P. J. Day wrote:
> On Mon, 21 May 2018, Elijah Newren wrote:
>> Hi Robert,
>>
>> I had always assumed prior to your email that 'known to Git' meant
>> 'tracked' or 'recorded in the index'...
>
> i *know* i've been in this discussion before, but i don't remember
> where, i *assume* it was
On Mon, 21 May 2018, Elijah Newren wrote:
> Hi Robert,
>
> I had always assumed prior to your email that 'known to Git' meant
> 'tracked' or 'recorded in the index'...
i *know* i've been in this discussion before, but i don't remember
where, i *assume* it was on this list, and i recall someone
I've noticed the following text in the documentation pages for the
`update-index` command:
Files to act on. Note that files beginning with . are discarded.
This includes ./file and
dir/./file. If you don't want this, then use cleaner names. The same
applies to di
>> Many tests hardcode the raw object names, which would change once
>> we migrate away from SHA-1. While some of them must test against
>> exact object names, most of them do not have to use hardcoded
>> constants in the test. The latter kind of tests have been updated
>> to test the moral
Hi Dscho,
On Mon, May 21, 2018 at 6:41 AM, Johannes Schindelin
wrote:
> On Sat, 19 May 2018, Elijah Newren wrote:
>> On Sat, May 19, 2018 at 12:32 AM, Johannes Sixt wrote:
>> >
>> > Oh, there is a reason for the repeated message text: translations! Please
>> > do
>> > not play sentence Lego wi
On Mon, 21 May 2018, Jonathan Nieder wrote:
> Hi,
>
> Robert P. J. Day wrote:
> > On Mon, 21 May 2018, Jonathan Nieder wrote:
>
> >> The packager should be able to find out whether it's an issue in
> >> git-lfs upstream and report it to that project if it is. Git-lfs is
> >> not part of git.git;
Hi,
Robert P. J. Day wrote:
> On Mon, 21 May 2018, Jonathan Nieder wrote:
>> The packager should be able to find out whether it's an issue in
>> git-lfs upstream and report it to that project if it is. Git-lfs is
>> not part of git.git; it's a separate project:
>> https://github.com/git-lfs/git-
On Mon, 21 May 2018, Jonathan Nieder wrote:
> Robert P. J. Day wrote:
>
> > $ sudo dnf install git-lfs
> [...]
> > Running transaction
> > Preparing:
> > Installing : git-lfs-2.4.0-1.fc28.x86_64
> > Running scriptlet: git-lfs-2.4.0-1.fc28.x86_64
> > Error: Failed to
Robert P. J. Day wrote:
> $ sudo dnf install git-lfs
[...]
> Running transaction
> Preparing:
> Installing : git-lfs-2.4.0-1.fc28.x86_64
> Running scriptlet: git-lfs-2.4.0-1.fc28.x86_64
> Error: Failed to call git rev-parse --git-dir --show-toplevel: "fatal:
> not
Hi Dscho,
On Mon, May 21, 2018 at 6:42 AM, Johannes Schindelin
wrote:
> Hi Elijah,
>
> On Fri, 18 May 2018, Elijah Newren wrote:
>
>> Various refactorings throughout the code have left lots of alignment
>> issues that were driving me crazy; fix them.
>
> I hope you did not do that manually. What
sort of related to my previous post, but in "man git-clean", one
reads:
-e , --exclude=
In addition to those found in .gitignore (per directory)
and $GIT_DIR/info/exclude, also consider these patterns to
be in the set of the ignore rules in effect.
-x
Don’t use the stan
On Tue, May 22, 2018 at 12:09 AM, Elijah Newren wrote:
>
> I had always assumed prior to your email that 'known to Git' meant
> 'tracked' or 'recorded in the index'.
That's been my intention as well ;-)
> From Documentation/git-clean.txt:
>
> Normally, only files unknown to Git are removed,
On Mon, 21 May 2018, Elijah Newren wrote:
> Hi Robert,
> I had always assumed prior to your email that 'known to Git' meant
> 'tracked' or 'recorded in the index'. However, a quick `git grep -i
> known.to.git` shows that we're actually not consistent by what we
> mean with this phrase. A little
On Mon, 21 May 2018, Elijah Newren wrote:
> Hi Robert,
>
> On Mon, May 21, 2018 at 4:18 AM, Robert P. J. Day
> wrote:
> >
> > updating my git courseware and, since some man pages refer to files
> > "known to git", i just want to make sure i understand precisely which
> > files those are. AIUI,
On Mon, May 21, 2018 at 5:09 PM, Elijah Newren wrote:
> Robert, since you're working on documentation of sorts anyway, would
> you like to propose some patches to fix things here? I'm not entirely
> sure what to suggest, and we might need a random suggestion to get the
> discussion started before
Hi Robert,
On Mon, May 21, 2018 at 4:18 AM, Robert P. J. Day wrote:
>
> updating my git courseware and, since some man pages refer to files
> "known to git", i just want to make sure i understand precisely which
> files those are. AIUI, they would include:
>
> * tracked files
> * ignored fi
On 21 May 2018 at 08:07, Junio C Hamano wrote:
> SZEDER Gábor writes:
>
>>> diff --git a/t/t9832-unshelve.sh b/t/t9832-unshelve.sh
>>> new file mode 100755
>>> index 00..cca2dec536
>
> ... in short, I'd queue a fix-up on top like this to be later
> squashed after getting an ack?
That loo
From: Junio C Hamano
Such an API change allows us to use an argv_array this way:
struct argv_array to_free = ARGV_ARRAY_INIT;
const char *msg;
if (some condition) {
msg = "constant string message";
... other logic ...
} else {
From: Elijah Newren
Rename `git_merge_trees()` to `unpack_trees_start()` and extract the
call to `discard_index()` into a new function `unpack_trees_finish()`.
As a result, these are called early resp. late in `merge_trees()`,
making the resource handling clearer. A later commit will expand on
th
The strings allocated in `setup_unpack_trees_porcelain()` are never
freed. Provide a function `clear_unpack_trees_porcelain()` to do so and
call it where we use `setup_unpack_trees_porcelain()`. The only
non-trivial user is `unpack_trees_start()`, where we should place the
new call in `unpack_trees
After we initialize the various fields in `opts` but before we actually
use them, we might return early. Move the initialization further down,
to immediately before we use `opts`.
This limits the scope of `opts` and will help a later commit fix a
memory leak without having to worry about those ear
On 21 May 2018 at 02:25, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> I have a feeling that argv_array might be a better fit for the
>> purpose of keeping track of to_free[] strings in the context of this
>> series. Moving away from string_list would allow us to sidestep the
>> storage ow
Hi Elijah,
On Fri, 18 May 2018, Elijah Newren wrote:
> These functions were added because processing of these conflicts needed
> to be deferred until process_entry() in order to get D/F conflicts and
> such right. The number of these has grown over time, and now include
> some whose name is mis
Hi Elijah,
On Fri, 18 May 2018, Elijah Newren wrote:
> We had an enum of rename types which included RENAME_DIR; this name felt
> misleading since it was not about an entire directory but was a status for
> each individual file add that occurred within a renamed directory. Since
> this type is f
On May 21, 2018 7:19 AM, Robert P. J. Day:
> updating my git courseware and, since some man pages refer to files
> "known to git", i just want to make sure i understand precisely which
files
> those are. AIUI, they would include:
>
> * tracked files
> * ignored files
> * new files which ha
Hi Elijah,
On Fri, 18 May 2018, Elijah Newren wrote:
> Various refactorings throughout the code have left lots of alignment
> issues that were driving me crazy; fix them.
I hope you did not do that manually. What is your code formatting tool of
choice?
The patch looks obviously good to me.
Cia
Hi Elijah,
On Sat, 19 May 2018, Elijah Newren wrote:
> On Sat, May 19, 2018 at 12:32 AM, Johannes Sixt wrote:
> > Am 19.05.2018 um 04:07 schrieb Elijah Newren:
> >>
> >> There is really no need for four branches of nearly identical messages
> >> when we can store the differences into small varia
On 5/20/2018 10:01 PM, brian m. carlson wrote:
This is part 2 in the series to make tests hash independent.
Do you plan to update those tests that hard code the SHA of the index
file itself? For example, t1700-split-index.sh has hard coded values
for the SHA and currently only supports di
Hi,
of course I messed up and did not fix the Cc: list... now fixed ;-)
On Mon, 21 May 2018, Johannes Schindelin wrote:
> Hi Chris,
>
> On Mon, 21 May 2018, Christian Couder wrote:
>
> > From: David Turner
>
> I vaguely remember that Dave suggested using a different email address
> these da
On 5/19/2018 4:27 AM, René Scharfe wrote:
Am 19.05.2018 um 03:57 schrieb Jeff King:
These formatted integers should always fit into their
64-byte buffers. Let's use xsnprintf() to add an assertion
that this is the case, which makes auditing for other
unchecked snprintfs() easier.
How about t
Hi Dscho,
On Mon, May 21, 2018 at 11:41 AM, Johannes Schindelin
wrote:
>
> On Mon, 21 May 2018, Christian Couder wrote:
>
>> From: David Turner
>
> I vaguely remember that Dave suggested using a different email address
> these days...
>
> *clicketyclick*
>
> ah, yes:
> https://public-inbox.org/g
Hi Junio,
On Mon, 21 May 2018, Johannes Schindelin wrote:
> On Fri, 18 May 2018, SZEDER Gábor wrote:
>
> > > > So, I think for v2 I will rewrite these tests to call
> > > > __git_complete_index_file() directly instead of using
> > > > 'test_completion', and will include a test with spaces in pat
Hi Gábor,
On Fri, 18 May 2018, SZEDER Gábor wrote:
> The tests added in 2f271cd9cf (t9902-completion: add tests
> demonstrating issues with quoted pathnames, 2018-05-08) and in
> 2ab6eab4fe (completion: improve handling quoted paths in 'git
> ls-files's output, 2018-03-28) have a few shortcomings
> > diff --git a/t/t9903-bash-prompt.sh b/t/t9903-bash-prompt.sh
> > index 8f5c811dd7..c3b89ae783 100755
> > --- a/t/t9903-bash-prompt.sh
> > +++ b/t/t9903-bash-prompt.sh
> > @@ -148,7 +148,7 @@ test_expect_success 'prompt - inside .git directory' '
> > test_expect_success 'prompt - deep inside .g
Hi Gábor,
On Fri, 18 May 2018, SZEDER Gábor wrote:
> > > So, I think for v2 I will rewrite these tests to call
> > > __git_complete_index_file() directly instead of using
> > > 'test_completion', and will include a test with spaces in path
> > > names.
> >
> > Quite well thought-out reasoning.
updating my git courseware and, since some man pages refer to files
"known to git", i just want to make sure i understand precisely which
files those are. AIUI, they would include:
* tracked files
* ignored files
* new files which have been staged but not yet committed
is that it? are th
Hi Junio,
On Tue, 8 May 2018, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > It would be easy to introduce, but I am wary about its usefulness.
> > Unless you re-generate the branch from patches (which I guess you do a
> > lot, but I don't), you are likely to compare incomplete patch
Hi Buga,
On Mon, 7 May 2018, Igor Djordjevic wrote:
> On 07/05/2018 09:48, Jeff King wrote:
> >
> > > > Let's, please, not fall into the trap of polluting git-branch with
> > > > utterly unrelated functionality, as has happened a few times with
> > > > other Git commands. Let's especially not do
first, i realize this is almost entirely a fedora packaging issue
and i'm planning on reporting it there, but i just want to make sure
i'm not doing something stupid.
knowing nothing about the git-lfs package, i thought i would install
it and just poke around out of sheer curiosity, so on my
"Hi there,
Hope this mail finds you well.
I am writing this email to inform you that we have fresh updated Managed
Service Providers-(MSPs) contacts to increase your 2018 sales.
You can use these database for direct mailing campaigns, email campaigns,
cold calling, and to share newsletter.
Hi Duy,
On Sun, 13 May 2018, Duy Nguyen wrote:
> On Thu, May 3, 2018 at 5:30 PM, Johannes Schindelin
> wrote:
> > + /* reduction transfer */
> > + free_row = xmalloc(sizeof(int) * row_count);
> > + for (int i = 0; i < row_count; i++) {
>
> travis complains about this
>
>
> h
1 - 100 of 105 matches
Mail list logo
