On Fri, Sep 06, 2019 at 02:35:03AM -0400, Jeff King wrote:
> > Fair enough. Forcing later users to reattempt parsing (and failing
> > the same way) would be safer and it should also be sufficient as we
> > are talking about how to handle a broken repository, i.e. an error
> > case.
>
> One of th
On Thu, Sep 05, 2019 at 03:19:48PM -0700, Junio C Hamano wrote:
> > Here an earlier parsing error could cause (*list)->object.parsed to be
> > true, but with (*list)->maybe_tree still NULL. Our call to
> > parse_commit_no_graph() here would silently return "yep, already tried
> > to parse this", a
On Thu, Sep 05, 2019 at 06:04:57PM -0400, Taylor Blau wrote:
> @@ -846,7 +847,11 @@ static void write_graph_chunk_data(struct hashfile *f,
> int hash_len,
> if (parse_commit_no_graph(*list))
> die(_("unable to parse commit %s"),
>
I should've noted earlier that this patch applies cleanly on top of the
"jc/tests-use-lf-from-test-lib" branch.
On Thu, Sep 05, 2019 at 03:10:05PM -0700, Denton Liu wrote:
> In many test scripts, there are bespoke definitions of the single quote
> that are some variation of this:
>
> SQ="'"
>
On Thu, Sep 05, 2019 at 09:24:30PM -0400, Jeff King wrote:
> Running on linux.git, I got:
>
> [before]
> Benchmark #1: git pack-objects --stdout --delta-base-offset >/dev/null 2>&1
> Time (mean ± σ): 26.225 s ± 0.233 s[User: 24.089 s, System:
> 4.867 s]
> Range (min … max):
On Fri, Sep 06, 2019 at 01:10:46AM +0200, Stephan Beyer wrote:
> I took a quick glance at yours. I also noticed the issue you address in
> [PATCH 2/6], but I was unsure if this is the way to go (I'm only
> occasionally reading on this list). I would prefer your patch series,
> with maybe one excep
On 9/6/19 12:58 AM, Jeff King wrote:
> On Fri, Sep 06, 2019 at 12:53:49AM +0200, Stephan Beyer wrote:
>
>> On 9/6/19 12:48 AM, Jeff King wrote:
>>> On Thu, Sep 05, 2019 at 10:24:59AM +0200, Stephan Beyer wrote:
>>>
Compiler heuristics for detection of potentially uninitialized variables
m
On Fri, Sep 06, 2019 at 12:53:49AM +0200, Stephan Beyer wrote:
> On 9/6/19 12:48 AM, Jeff King wrote:
> > On Thu, Sep 05, 2019 at 10:24:59AM +0200, Stephan Beyer wrote:
> >
> >> Compiler heuristics for detection of potentially uninitialized variables
> >> may change between compiler versions and e
Once upon a time, the code to add an object to our packing list in
pack-objects all lived in a single function. It computed the position
within the hash table once, then used it to check if the object was
already present, and if not, to add it.
Later, in 2834bc27c1 (pack-objects: refactor the pack
On 9/6/19 12:48 AM, Jeff King wrote:
> On Thu, Sep 05, 2019 at 10:24:59AM +0200, Stephan Beyer wrote:
>
>> Compiler heuristics for detection of potentially uninitialized variables
>> may change between compiler versions and enabling link-time optimization
>> may find new warnings. Indeed, compilin
Early in the function we set "namelen = strlen(name)" if "name" is
non-NULL. Later, we use "namelen" only if "name" is non-NULL. However,
it's hard to immediately see this, and it seems to confuse gcc 9.2.1
(with "-flto" interestingly, though all of the involved logic is in
inline functions; it als
When we cannot generate a delta, we return NULL but leave delta_size
untouched. This is generally OK, as callers rely on NULL to decide if
the output is usable or not. But it can confuse compilers; in
particular, gcc 9.2.1 with "-flto -O3" complains in fast-import's
store_object() that delta_len ma
We declare a "struct hashfile_checkpoint" but only sometimes actually
call hashfile_checkpoint() on it. That makes it not immediately obvious
that it's valid when we later access its members.
In fact, the code is fine: we fill it in unconditionally in the while(1)
loop as long as "idx" is non-NULL
The only caller of packlist_alloc() already has a "struct object_id",
and we immediately copy the hash they pass us into our own object_id.
Let's avoid the unnecessary round-trip to a raw sha1 pointer.
Signed-off-by: Jeff King
---
Just noticed since I was touching that function.
This is the seco
We try to parse the "author" line out of a commit buffer. We handle the
case that split_ident_line() doesn't work, but we don't do any error
checking that we found an "author" line in the first place! This would
cause us to segfault on such a corrupt object.
Let's put in an explicit NULL check (we
This is done by removing namelen at all. It is only used once
and simply strlen(name), hence we use strlen(name) directly.
Suggested-by: Jeff King
Signed-off-by: Stephan Beyer
---
t/helper/test-read-cache.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/t/helper/test-r
gcc 9.2.1 with -flto shows a maybe-uninitialized warning for index_pos
in builtin/pack-objects.c's add_object_entry(). Tracking it down,
the variable should be initialized in pack_objects.c's packlist_find().
The return value of locate_object_entry_hash(), which becomes index_pos,
is either (in c
On Thu, Sep 05, 2019 at 10:24:59AM +0200, Stephan Beyer wrote:
> Compiler heuristics for detection of potentially uninitialized variables
> may change between compiler versions and enabling link-time optimization
> may find new warnings. Indeed, compiling with gcc 9.2.1 and enabled
> link-time op
This prevents a potential segmentation fault.
Signed-off-by: Stephan Beyer
---
builtin/am.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/builtin/am.c b/builtin/am.c
index 1aea657a7f..71da34913c 100644
--- a/builtin/am.c
+++ b/builtin/am.c
@@ -1272,7 +1272,8 @@ static voi
gcc 9.2.1 with -flto flag suspects some uninitialized variables which become
initialized in every code path where they are used. These false positives
are "fixed" by this patch in the most naïve way.
This allows to compile git with gcc 9, link-time optimization, and using the
DEVELOPER=1 switch (
On Thu, Sep 05, 2019 at 06:25:26PM -0400, Taylor Blau wrote:
> On Thu, Sep 05, 2019 at 03:10:05PM -0700, Denton Liu wrote:
> > In many test scripts, there are bespoke definitions of the single quote
> > that are some variation of this:
> >
> > SQ="'"
> >
> > Define a common $SQ variable in test
On Thu, Sep 05, 2019 at 03:10:05PM -0700, Denton Liu wrote:
> In many test scripts, there are bespoke definitions of the single quote
> that are some variation of this:
>
> SQ="'"
>
> Define a common $SQ variable in test-lib.sh and replace all usages of
> these bespoke variables with the common
Jeff King writes:
> I don't think parse_commit_no_graph() returning 0 assures us that
> get_commit_tree() and friends will return non-NULL.
>
> This is similar to the case discussed recently where a failed parse of a
> tag may leave "tag->tagged == NULL" even though "tag->obj.parsed" is
> set.
>
In many test scripts, there are bespoke definitions of the single quote
that are some variation of this:
SQ="'"
Define a common $SQ variable in test-lib.sh and replace all usages of
these bespoke variables with the common one.
This change was done by running `git grep =\"\'\" t/` and
`git gr
Hi,
This patch series is a polished version of a series I posed in [1],
based on the subsequent discussion starting in [2]. It hardens the 'git
commit-graph write' code to handle two new types of object corruption
that previously resulted in a SIGSEGV, which are:
- a commit which lists a parent
To write a commit graph chunk, 'write_graph_chunk_data()' takes a list
of commits to write and parses each one before writing the necessary
data, and continuing on to the next commit in the list.
Since the majority of these commits are not parsed ahead of time (an
exception is made for the *last*
When invoking 'git commit-graph' in a corrupt repository, one can cause
a segfault when ancestral commits are corrupt in one way or another.
This is due to two function calls in the 'commit-graph.c' code that may
return NULL, but are not checked for NULL-ness before dereferencing.
Before fixing th
Apply similar treatment as in the previous commit to handle an unchecked
call to 'get_commit_tree_oid()'. Previously, a NULL return value from
this function would be immediately dereferenced with '->hash', and then
cause a segfault.
Before dereferencing to access the 'hash' member, check the retur
Thomas Gummerer writes:
> Getting the lock for the index, refreshing it and then writing it is a
> pattern that happens more than once throughout the codebase, and isn't
> trivial to get right. Factor out the refresh_and_write_cache function
> from builtin/am.c to read-cache.c, so it can be re-u
On Thu, Sep 05, 2019 at 12:56:06PM -0700, Junio C Hamano wrote:
> Denton Liu writes:
>
> > Hi Junio,
> >
> > I see that "dl/format-patch-doc-test-cleanup" currently has the comment
> > "Expecting a reroll." This should be the reroll that you're expecting ;)
> >
> > Also, since there haven't been
On Thu, Sep 05, 2019 at 08:47:33AM -0700, Elijah Newren wrote:
> Users expect files in a nested git repository to be left alone unless
> sufficiently forced (with two -f's). Unfortunately, in certain
> circumstances, git would delete both tracked (and possibly dirty) files
> and untracked files wi
Jeff King writes:
> I wonder if there's a name that could more clearly distinguish the two.
> Or if it's sufficient to just become Git jargon that "pathspec" is the
> command-line one and "path_pattern" is the file-based one (we're at
> least pretty consistent about the former already).
>
> I thi
Jeff King writes:
> Do we want to to have fetch.writeCommitGraph, receive.writeCommitGraph,
> and then a master transfer.writeCommitGraph?
If anything, it may be good for consistency.
I am not sure if it is a good idea to trigger writing the commit
graph when accepting a push, though. It tends
Hi Bert,
I have some _very_ busy few days coming up, so I won't be able to devote
much time to this right now. I will take a look at the series and your
other patches by the coming Wednesday. Thanks.
[snip]
--
Regards,
Pratyush Yadav
On Wed, Sep 4, 2019 at 8:00 PM Birger Skogeng Pedersen
wrote:
>
> Selecting whether to do a "New Commit" or "Amend Last Commit" does not have
> a hotkey.
>
> With this patch, the user may toggle between the two options with
> CTRL/CMD+e.
>
> Signed-off-by: Birger Skogeng Pedersen
> Signed-off-by:
From: Birger Skogeng Pedersen
Selecting whether to "Amend Last Commit" or not does not have a hotkey.
With this patch, the user may toggle between the two options with
CTRL/CMD+e.
Signed-off-by: Birger Skogeng Pedersen
Rebased-by: Bert Wesarg
---
git-gui.sh | 8
1 file changed, 8 in
Signed-off-by: Bert Wesarg
---
git-gui.sh | 36 +---
lib/checkout_op.tcl | 6 +++---
lib/commit.tcl | 4 ++--
lib/index.tcl | 8
4 files changed, 18 insertions(+), 36 deletions(-)
diff --git a/git-gui.sh b/git-gui.sh
index 5bc21b8..
Avoid derefencing ->tagged without checking for NULL by using the
convenience wrapper for getting the ID of the tagged object. It die()s
when encountering a broken tag instead of segfaulting.
Signed-off-by: René Scharfe
---
builtin/describe.c | 2 +-
builtin/log.c | 5 +++--
builtin/replac
Add a function for accessing the ID of the object referenced by a tag
safely, i.e. without causing a segfault when encountering a broken tag
where ->tagged is NULL.
Signed-off-by: René Scharfe
---
pack-bitmap.c | 4 +---
revision.c| 4 +---
tag.c | 7 +++
tag.h | 1 +
4 f
Denton Liu writes:
> Hi Junio,
>
> I see that "dl/format-patch-doc-test-cleanup" currently has the comment
> "Expecting a reroll." This should be the reroll that you're expecting ;)
>
> Also, since there haven't been any comments on the topic in a while, I
> propose that it should be ready for in
René Scharfe writes:
> The loop count is either 1 or argv[1] interpreted as a number, i.e. it could
> be very high. Its body consists of an index load and writing a number to a
> file, though -- a strlen() call on the name of that file should go unnoticed
> amid that activity. (I didn't measure
On Wed, Sep 04, 2019 at 03:41:15PM -0400, Jeff King wrote:
> On Tue, Aug 27, 2019 at 01:17:57AM -0400, Jeff King wrote:
>
> > Do we have interested mentors for the next round of Outreachy?
> >
> > The deadline for Git to apply to the program is September 5th. The
> > deadline for mentors to have
Am 05.09.19 um 21:25 schrieb Junio C Hamano:
> René Scharfe writes:
>
>> Am 05.09.19 um 19:53 schrieb Jeff King:
> int cmd__read_cache(int argc, const char **argv)
> {
> - int i, cnt = 1, namelen;
> + int i, cnt = 1, namelen = 0;
>>>
>>> I actually saw this one the othe
On Wed, 4 Sep 2019 at 05:26, Jeff King wrote:
>
> On Tue, Sep 03, 2019 at 08:51:19PM +0200, Martin Ågren wrote:
>
> > When I posted v1, it turned into quite a thread [1] on AsciiDoc vs
> > Asciidoctor vs Asciidoctor 2.0 and differences in rendering. (I am on
> > Asciidoctor 1.5.5.)
>
> Yes, sadly
Jeff King writes:
> On Thu, Sep 05, 2019 at 11:17:57AM -0700, Junio C Hamano wrote:
>
>> Somebody may want to go clean-up the use of various $sq and $SQ
>> locally defined by giving a unified $SQ in test-lib.sh, by the way.
>
> Maybe good #leftoverbits material, since we may have Outreachy
> appl
On Wed, 4 Sep 2019 at 01:16, brian m. carlson
wrote:
>
> I looked at this series and it seems sane. I agree that adding a
> dependency on nokogiri isn't really desirable. It is an extremely
> common Ruby package, but it has native extensions, which causes problems
> for some people if their dist
On Thu, Sep 05, 2019 at 08:47:35AM -0700, Elijah Newren wrote:
> cmd_clean() had the following code structure:
>
> struct strbuf abs_path = STRBUF_INIT;
> for_each_string_list_item(item, &del_list) {
> strbuf_addstr(&abs_path, prefix);
> strbuf_addstr(&abs_path, item->strin
René Scharfe writes:
> Am 05.09.19 um 19:53 schrieb Jeff King:
int cmd__read_cache(int argc, const char **argv)
{
- int i, cnt = 1, namelen;
+ int i, cnt = 1, namelen = 0;
>>
>> I actually saw this one the other day, because it triggered for me when
>> compiling wi
Am 05.09.19 um 19:53 schrieb Jeff King:
>>> int cmd__read_cache(int argc, const char **argv)
>>> {
>>> - int i, cnt = 1, namelen;
>>> + int i, cnt = 1, namelen = 0;
>
> I actually saw this one the other day, because it triggered for me when
> compiling with SANITIZE=address. AFAICT it's
On Thu, Sep 05, 2019 at 08:47:23AM -0700, Elijah Newren wrote:
> This patch series fixes a few issues with git-clean:
> * Failure to preserve both tracked and untracked files within a nested
> Git repository reported a few weeks ago by SZEDER[3].
Wow, I didn't expect a 12 patch series to fi
Jeff King writes:
> So these patches are punting on the greater question of why we want to
> parse so early, and are not making anything worse. AFAICT, "clone
> --filter=sparse:oid" has never worked (even though our tests did cover
> the underlying rev-list and pack-objects code paths).
> ...
> T
Dear,i am Peace Maurice,it would be great to know you,i have a very
important and confidential matter that i want to discuss with
you,reply me back for more discus.
Regards,
Peace.
On Thu, Sep 05, 2019 at 11:17:57AM -0700, Junio C Hamano wrote:
> Taylor Blau writes:
>
> > - t/t3005: this script calls the variable '$new_line', but could be
> > renamed to LF and then removed in a second patch
>
> It is worse than that, isn't it?
>
> If it used $new_line, then it would pr
On Thu, Sep 05, 2019 at 11:17:57AM -0700, Junio C Hamano wrote:
> Somebody may want to go clean-up the use of various $sq and $SQ
> locally defined by giving a unified $SQ in test-lib.sh, by the way.
Maybe good #leftoverbits material, since we may have Outreachy
applications coming up soon.
-Pef
> I'm not really opposed to what you're doing here, but I did recently
> think of another possible use for .promisor files. So it seems like a
> good time to bring it up, since presumably we'd have to choose one or
> the other.
Thanks for bringing it up - yes, we should discuss this.
> I noticed
Jeff King writes:
> I said earlier that I wouldn't mind seeing "namelen = 0" here. But I
> think there is a much more direct solution: keeping the assignment and
> point of use closer together. That makes it more clear both to the
> compiler and to a human when we expect the variable to be valid.
Taylor Blau writes:
> - t/t3005: this script calls the variable '$new_line', but could be
> renamed to LF and then removed in a second patch
It is worse than that, isn't it?
If it used $new_line, then it would probably have been a good idea
to somehow make a separate patch related to this
On Thu, Sep 05, 2019 at 10:56:12AM -0700, Junio C Hamano wrote:
> Stephan Beyer writes:
>
> > diff --git a/t/helper/test-read-cache.c b/t/helper/test-read-cache.c
> > index 7e79b555de..ef0963e2f4 100644
> > --- a/t/helper/test-read-cache.c
> > +++ b/t/helper/test-read-cache.c
> > @@ -4,7 +4,7 @@
On Thu, Sep 05, 2019 at 10:13:24AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > But I wonder if it would make sense to keep a cache of these "cut
> > points" in the partial clone. That's potentially smaller than the
> > complete set of objects (especially for tree-based partial cloning
Stephan Beyer writes:
> diff --git a/t/helper/test-read-cache.c b/t/helper/test-read-cache.c
> index 7e79b555de..ef0963e2f4 100644
> --- a/t/helper/test-read-cache.c
> +++ b/t/helper/test-read-cache.c
> @@ -4,7 +4,7 @@
>
> int cmd__read_cache(int argc, const char **argv)
> {
> - int i, cnt
On Thu, Sep 05, 2019 at 07:08:49PM +0200, René Scharfe wrote:
> Anyway, my points are that simply initializing might not always be the
> best fix, and that more context would help reviewers of such a patch,
> but only if functions are reasonably short and it's not necessary to
> follow the rabbit
On Thu, Sep 5, 2019 at 8:50 AM Birger Skogeng Pedersen
wrote:
>
> On Thu, Sep 5, 2019 at 12:48 AM Pratyush Yadav wrote:
> > I'll chime in with what I think would be a great solution: auto word
> > wrapping. This way, the users can set the text width, and not have to
> > worry about manually forma
"Johannes Schindelin via GitGitGadget"
writes:
> ...
> Further reading on auto-generated `.manifest` files:
> https://docs.microsoft.com/en-us/cpp/build/manifest-generation-in-visual-studio
>
> Signed-off-by: Johannes Schindelin
> ---
> .gitignore | 1 -
> 1 file changed, 1 deletion(-)
Thanks.
On Thu, Sep 5, 2019 at 8:22 AM Johannes Sixt wrote:
>
> Am 04.09.19 um 22:43 schrieb Bert Wesarg:
> > these people did not saw the entered text anyway. they would have
> > needed to change the option (default to 75 characters) to see what
> > they have typed. which could have been garbage to begin
Stephan Beyer writes:
> diff --git a/fast-import.c b/fast-import.c
> index b44d6a467e..58f73f9105 100644
> --- a/fast-import.c
> +++ b/fast-import.c
> @@ -903,7 +903,8 @@ static int store_object(
> struct object_entry *e;
> unsigned char hdr[96];
> struct object_id oid;
> -
Jeff King writes:
> But I wonder if it would make sense to keep a cache of these "cut
> points" in the partial clone. That's potentially smaller than the
> complete set of objects (especially for tree-based partial cloning), and
> it seems clear we're willing to store it in memory anyway.
That s
Am 05.09.19 um 10:24 schrieb Stephan Beyer:
> Compiler heuristics for detection of potentially uninitialized variables
> may change between compiler versions and enabling link-time optimization
> may find new warnings. Indeed, compiling with gcc 9.2.1 and enabled
> link-time optimization feature r
Alexandr Miloslavskiy writes:
> Johannes, thanks for working on this problem!
>
> In the previous discussion, there was a suggestion to change
> '--stdin' to '--paths-file', where '--paths-file -' would mean stdin:
> https://public-inbox.org/git/066cfd61-9700-e154-042f-fc9cffbd6...@web.de/
>
> I
Johannes, thanks for working on this problem!
In the previous discussion, there was a suggestion to change
'--stdin' to '--paths-file', where '--paths-file -' would mean stdin:
https://public-inbox.org/git/066cfd61-9700-e154-042f-fc9cffbd6...@web.de/
I believe that was a good suggestion for a fe
Signed-off-by: Elijah Newren
---
builtin/clean.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/builtin/clean.c b/builtin/clean.c
index 3a7a63ae71..6030842f3a 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -158,7 +158,8 @@ static int remove_dirs(struct strbuf *path,
Users expect files in a nested git repository to be left alone unless
sufficiently forced (with two -f's). Unfortunately, in certain
circumstances, git would delete both tracked (and possibly dirty) files
and untracked files within a nested repository. To explain how this
happens, let's contrast
cmd_clean() had the following code structure:
struct strbuf abs_path = STRBUF_INIT;
for_each_string_list_item(item, &del_list) {
strbuf_addstr(&abs_path, prefix);
strbuf_addstr(&abs_path, item->string);
PROCESS(&abs_path);
strbuf_reset(&abs_path);
}
whe
The -d flag pre-dated git-clean's ability to have paths specified. As
such, the default for git-clean was to only remove untracked files in
the current directory, and -d existed to allow it to recurse into
subdirectories.
The interaction of paths and the -d option appears to not have been
careful
The way match_pathspec_item() handles names and pathspecs with trailing
slash characters, in conjunction with special options like
DO_MATCH_DIRECTORY and DO_MATCH_LEADING_PATHSPEC were non-obvious, and
broken until this patch series. Add a table in a comment explaining the
intent of how these work
For git clean, if a directory is entirely untracked and the user did not
specify -d (corresponding to DIR_SHOW_IGNORED_TOO), then we usually do
not want to remove that directory and thus do not recurse into it.
However, if the user manually specified specific (or even globbed) paths
somewhere under
Someone brought me a testcase where multiple git-clean invocations were
required to clean out unwanted files:
mkdir d{1,2}
touch d{1,2}/ut
touch d1/t && git add d1/t
With this setup, the user would need to run
git clean -ffd */ut
twice to delete both ut files.
A little testing showed some
It appears that the wrong option got included in the list of what will
cause git-clean to actually take action. Correct the list.
Signed-off-by: Elijah Newren
---
Documentation/git-clean.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/git-clean.txt b/Docume
NOTE: This series builds on sg/clean-nested-repo-with-ignored, as it
(among other things) modifies his testcase from expect_failure
to expect_success. Also, Peff is probably the only one who
remembers v1 (and even he may have forgotten it): v1 was posted
a year and a half a
Even if a directory doesn't match a pathspec, it is possible, depending
on the precise pathspecs, that some file underneath it might. So we
special case and recurse into the directory for such situations. However,
we previously always added any untracked directory that we recursed into
to the lis
Signed-off-by: Elijah Newren
---
dir.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dir.c b/dir.c
index d021c908e5..a9168bed96 100644
--- a/dir.c
+++ b/dir.c
@@ -139,7 +139,7 @@ static size_t common_prefix_len(const struct pathspec
*pathspec)
* ":(icase)path" is t
For a pathspec like 'foo/bar' comparing against a path named "foo/",
namelen will be 4, and match[namelen] will be 'b'. The correct location
of the directory separator is namelen-1.
The reason the code worked anyway was that the following code immediately
checked whether the first matchlen charac
The specific checks done in match_pathspec_item for the DO_MATCH_SUBMODULE
case are useful for other cases which have nothing to do with submodules.
Rename this constant; a subsequent commit will make use of this change.
Signed-off-by: Elijah Newren
---
dir.c | 6 +++---
1 file changed, 3 insert
Thanks Jeff!
Completely solved the problem for me.
On Wed, Sep 4, 2019 at 5:14 AM Jeff King wrote:
>
> On Tue, Sep 03, 2019 at 05:30:02PM +0200, Grigory Yakushev wrote:
>
> > $ git --version
> > git version 2.17.1
> >
> > Repro:
> > $ git clone https://github.com/PX4/Firmware.git
> > $ cd Firmwa
On 04/09/19 04:38PM, Junio C Hamano wrote:
> Pratyush Yadav writes:
>
> > On 04/09/19 11:39PM, Johannes Sixt wrote:
> >> Am 04.09.19 um 21:20 schrieb Birger Skogeng Pedersen:
> >> > On Wed, Sep 4, 2019 at 8:59 PM Johannes Sixt wrote:
> >> >> Many keyboards do not have a right Alt-key. That means
As reported in
https://public-inbox.org/git/20190825120741.gm20...@szeder.dev/, we added a
line to ignore .manifest files, but that is a left-over from a long time
ago, before we added and used compat/win32/git.manifest.
This fixes that left-over.
Johannes Schindelin (1):
.gitignore: stop igno
From: Johannes Schindelin
On Windows, it is possible to embed additional metadata into an
executable by linking in a "manifest", i.e. an XML document that
describes capabilities and requirements (such as minimum or maximum
Windows version). These XML documents are expected to be stored in
`.manif
Compiler heuristics for detection of potentially uninitialized variables
may change between compiler versions and enabling link-time optimization
may find new warnings. Indeed, compiling with gcc 9.2.1 and enabled
link-time optimization feature resulted in a few hits that are fixed by
this patch i
On Wed, Sep 4, 2019 at 9:41 PM Jeff King wrote:
>
> Funding is still up in the air, but in the meantime I've tentatively
> signed us up (we have until the 24th to have the funding committed).
> Next we need mentors to submit projects, as well as first-time
> contribution micro-projects.
Great! Th
On Mon, Aug 26, 2019 at 02:47:37PM -0700, Jonathan Tan wrote:
> The specification of promisor packfiles (in partial-clone.txt) states
> that the .promisor files that accompany packfiles do not matter (just
> like .keep files), so whenever a packfile is fetched from the promisor
> remote, Git has b
89 matches
Mail list logo
