In a rather complex setup with deep directory structure it happens
every now and then, that files get ignored when trying to add them.
As these files are _not_ shown in `git status` but in `git status
--ignored` so I guess the culprit is some misconfigured `.gitignore`.
Trying to ad the specific
Am Fr., 7. Dez. 2018 um 13:45 Uhr schrieb Eric Sunshine
:
>
> On Fri, Dec 7, 2018 at 7:36 AM Victor Toni wrote:
> > I'm wondering if there is any way to show which rules (ideally with
> > the .gitignore file they are coming from) are causing a specific file
> > to get ignored so I could easily
On 12/6/2018 3:20 PM, Josh Steadmon wrote:
+
+# usage: corrupt_and_zero_graph_then_verify
+# Manipulates the commit-graph file at by inserting the
data,
+# then zeros the file starting at . Finally, runs
+# 'git commit-graph verify' and places the output in the file 'err'. Tests
'err'
+#
On Fri, Dec 7, 2018 at 7:36 AM Victor Toni wrote:
> I'm wondering if there is any way to show which rules (ideally with
> the .gitignore file they are coming from) are causing a specific file
> to get ignored so I could easily fix the .gitignore file?
Perhaps the "git check-ignore" command would
On 12/6/2018 6:36 PM, Jonathan Tan wrote:
AFAICT oid_object_info doesn't take advantage of the commit graph,
but just looks up the object header, which is still less than completely
parsing it. Then lookup_commit is overly strict, as it may return
NULL as when there still is a type mismatch (I
From: Elijah Newren
In commit 6aba117d5cf7 ("am: avoid directory rename detection when
calling recursive merge machinery", 2018-08-29), the git-rebase manpage
probably should have also been updated to note the stronger
incompatibility between git-am and directory rename detection. Update
it
From: Torsten Bögershausen
Change the return value for offset_1st_component(),
has_dos_drive_prefix() and skip_dos_drive_prefix from int into size_t,
which is the natural type for length of data in memory.
While at it, remove possible "parameter not used" warnings in for the
non-Windows builds
From: Torsten Bögershausen
The Windows version of offset_1st_component() needs to hande 3 cases:
- The path is an UNC path, starting with "//" or "".
Skip the servername and the name of the share.
- The path is a DOS drive, starting with e.g. "X:"
The driver letter and the ':' must be
From: Torsten Bögershausen
A regression for cygwin users was introduced with commit 05b458c,
"real_path: resolve symlinks by hand".
In the the commit message we read:
The current implementation of real_path uses chdir() in order to resolve
symlinks. Unfortunately this isn't thread-safe
On Fri, Dec 07 2018, Konstantin Ryabitsev wrote:
> Hi, all:
>
> Every now and again I come across a patch sent to LKML without a leading
> "diff a/foo b/foo" -- usually produced by quilt. E.g.:
>
> https://lore.kernel.org/lkml/20181125185004.151077...@linutronix.de/
>
> I am guessing quilt does
Signed-off-by: Brandon Williams
---
.mailmap | 1 +
1 file changed, 1 insertion(+)
diff --git a/.mailmap b/.mailmap
index eb7b5fc7b..247a3deb7 100644
--- a/.mailmap
+++ b/.mailmap
@@ -27,6 +27,7 @@ Ben Walton
Benoit Sigoure
Bernt Hansen
Brandon Casey
+Brandon Williams
brian m.
Hi, all:
Every now and again I come across a patch sent to LKML without a leading
"diff a/foo b/foo" -- usually produced by quilt. E.g.:
https://lore.kernel.org/lkml/20181125185004.151077...@linutronix.de/
I am guessing quilt does not bother including the leading "diff a/foo
b/foo" because it's
On Fri, Dec 7, 2018 at 9:51 AM Johannes Sixt wrote:
>
> From: Elijah Newren
>
> In commit 6aba117d5cf7 ("am: avoid directory rename detection when
> calling recursive merge machinery", 2018-08-29), the git-rebase manpage
> probably should have also been updated to note the stronger
>
Reported-by: Phillip Szelat
Signed-off-by: Ralf Thielow
---
Hi Phillip,
Good catches. Thanks for the review!
Ralf
po/de.po | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/po/de.po b/po/de.po
index eb213d742..d5113434a 100644
--- a/po/de.po
+++ b/po/de.po
@@ -3421,7
On Thu, Dec 6, 2018 at 5:23 PM Yaroslav Halchenko wrote:
> > There was a proposal to "re-attach HEAD" in the submodule, i.e.
> > if the branch branch points at the same commit, we don't need
> > a detached HEAD, but could go with the branch instead.
>
> if I got the idea right, if we are talking
Hi Torsten,
On Fri, 7 Dec 2018, tbo...@web.de wrote:
> diff --git a/compat/mingw-cygwin.c b/compat/mingw-cygwin.c
> index 5552c3ac20..c379a72775 100644
> --- a/compat/mingw-cygwin.c
> +++ b/compat/mingw-cygwin.c
> @@ -10,10 +10,8 @@ size_t mingw_cygwin_skip_dos_drive_prefix(char **path)
>
On Fri, Dec 07 2018, Jonathan Nieder wrote:
> Hi,
>
> Konstantin Ryabitsev wrote:
>
>> Every now and again I come across a patch sent to LKML without a leading
>> "diff a/foo b/foo" -- usually produced by quilt. E.g.:
>>
>> https://lore.kernel.org/lkml/20181125185004.151077...@linutronix.de/
>>
Hi,
Stefan Beller wrote:
> What would be more of interest is why we'd be interested in this patch
> as there is no commit/patch sent by Brandon with this email in gits history.
I think there's an implicit assumption in this question that isn't
spelled out. Do I understand correctly that you're
When a user runs "git commit" without specifying a message, an editor
appears with advice:
Please enter the commit message for your changes. Lines starting
with '#' will be ignored, and an empty message aborts the commit.
However, if the user supplies an empty message and has a
Ad a new fuzz test for the commit graph and fix a buffer read-overflow
that it discovered. Additionally, fix the Makefile instructions for
building fuzzers.
Changes since V2:
* Avoid pointer arithmetic overflow when checking the graph's chunk
count.
* Merge the corrupt_graph_and_verify
Breaks load_commit_graph_one() into a new function,
parse_commit_graph(). The latter function operates on arbitrary buffers,
which makes it suitable as a fuzzing target. Since parse_commit_graph()
is only called by load_commit_graph_one() (and the fuzzer described
below), we omit error messages
Signed-off-by: Josh Steadmon
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index 6b72f37c29..bbcfc2bc9f 100644
--- a/Makefile
+++ b/Makefile
@@ -3104,7 +3104,7 @@ cover_db_html: cover_db
# An example command to build against libFuzzer from
fuzz-commit-graph identified a case where Git will read past the end of
a buffer containing a commit graph if the graph's header has an
incorrect chunk count. A simple bounds check in parse_commit_graph()
prevents this.
Signed-off-by: Josh Steadmon
---
commit-graph.c | 14
On Fri, Dec 7, 2018 at 11:04 AM wrote:
> The solution is to implement has_dos_drive_prefix(), skip_dos_drive_prefix()
> is_dir_sep(), offset_1st_component() and convert_slashes() for cygwin
> in the same way as it is done in 'Git for Windows' in compat/mingw.[ch]
>
> Instead of duplicating the
On Thu, Dec 6, 2018 at 11:26 PM Jeff King wrote:
>>
>> On Thu, Dec 06, 2018 at 11:07:00PM -0800, biswaranjan panda wrote:
>>
> >> Thanks! Strangely git log --follow does work.
>>
>> I suspect it would work even without --follow. When you limit a log
>> traversal with a pathspec, like:
>>
>> git
Hi,
Konstantin Ryabitsev wrote:
> Every now and again I come across a patch sent to LKML without a leading
> "diff a/foo b/foo" -- usually produced by quilt. E.g.:
>
> https://lore.kernel.org/lkml/20181125185004.151077...@linutronix.de/
>
> I am guessing quilt does not bother including the
Hi Johannes,
On Thu, Dec 06, 2018 at 11:20:07PM +0100, Johannes Schindelin wrote:
> Hi William,
>
>[...]
>
> There *is* a way to get what you want that is super easy and will
> definitely work: if you sit down and do it ;-)
>
> Please let us know if you need any additional information before
Ævar Arnfjörð Bjarmason wrote:
> On Fri, Dec 07 2018, Jonathan Nieder wrote:
>> The patch-id appears to only care about the diff text, so it should be
>> able to handle this. So if we have a better heuristic for where the
>> diff starts, it would be good to use it.
>
> No, the patch-id doesn't
Hi,
Jonathan Tan wrote:
> (The implementation in this commit reads the commit message twice even
> if there is no commit-msg hook. I think that this is fine, since this is
> for interactive use - an alternative would be to plumb information about
> the absence of the hook from run_hook_ve()
Hello, I have a rather elaborate diff highlighter that I have implemented as a
post-processor to regular git output. I am writing to discuss some difficult
aspects of git diff's color output that I am observing with version 2.19.2.
This is not a regression report; I am trying to implement a new
The documentation for the feature 'snapshot' claimed
"This feature can be configured on a per-repository basis via
repository's `gitweb.blame` configuration variable"
Fixed to specify `gitweb.snapshot` as the variable name.
---
Documentation/gitweb.conf.txt | 2 +-
1 file changed, 1
Hi Torsten,
On Fri, 7 Dec 2018, tbo...@web.de wrote:
> compat/mingw-cygwin.c | 28
> compat/mingw-cygwin.h | 20
Please use compat/win32/path.c (or .../path-utils.c) instead. This is not
so much about MINGW or Cygwin or MSys or MSYS2 or Visual
Hi,
Frank Dana wrote:
> The documentation for the feature 'snapshot' claimed
> "This feature can be configured on a per-repository basis via
> repository's `gitweb.blame` configuration variable"
>
> Fixed to specify `gitweb.snapshot` as the variable name.
> ---
> Documentation/gitweb.conf.txt |
Brandon Williams wrote:
> Signed-off-by: Brandon Williams
> ---
> .mailmap | 1 +
> 1 file changed, 1 insertion(+)
I can confirm that this is indeed the same person.
Reviewed-by: Jonathan Nieder
Welcome back!
When fetching into a repository, a connectivity check is first made by
check_exist_and_connected() in builtin/fetch.c that runs:
git rev-list --objects --stdin --not --all --quiet <(list of objects)
If the client repository has many refs, this command can be slow,
regardless of the nature of
On Fri, Dec 7, 2018 at 1:40 PM Jonathan Nieder wrote:
>
> Brandon Williams wrote:
>
> > Signed-off-by: Brandon Williams
> > ---
> > .mailmap | 1 +
> > 1 file changed, 1 insertion(+)
>
> I can confirm that this is indeed the same person.
What would be more of interest is why we'd be interested
William Hubbs wrote:
> On Thu, Dec 06, 2018 at 11:20:07PM +0100, Johannes Schindelin wrote:
>> There *is* a way to get what you want that is super easy and will
>> definitely work: if you sit down and do it ;-)
>>
>> Please let us know if you need any additional information before you can
>>
On Sun, Oct 21, 2018 at 7:21 PM Junio C Hamano wrote:
>
> Matthew DeVore writes:
>
> >> It is more like "this is a set operation across commits. We also
> >> show objects that are reachable from the commits in the resulting
> >> set and are not reachable from the commits in the set that were
>
As f178c13fda (Revert "Merge branch 'sb/submodule-core-worktree'",
2018-09-07) was produced shortly before a release, nobody asked for
a regression test to be included. Add a regression test that makes sure
that the invocation of `git submodule update` on old setups doesn't
produce errors as
This re-introduces 984cd77ddb (submodule deinit: unset core.worktree,
2018-06-18), which was reverted as part of f178c13fda (Revert "Merge
branch 'sb/submodule-core-worktree'", 2018-09-07)
The whole series was reverted as the offending commit e98317508c
(submodule: ensure core.worktree is set
This reintroduces 4fa4f90ccd (submodule: unset core.worktree if no working
tree is present, 2018-06-12), which was reverted as part of f178c13fda
(Revert "Merge branch 'sb/submodule-core-worktree'", 2018-09-07).
4fa4f90ccd was reverted as its followup commit was faulty, but without
the
Shortly after f178c13fda (Revert "Merge branch
'sb/submodule-core-worktree'", 2018-09-07), we had another series
that implemented partially the same, ensuring that core.worktree was
set in a checked out submodule, namely 74d4731da1 (submodule--helper:
replace connect-gitdir-workingtree by
A couple days before the 2.19 release we had a bug report about
broken submodules[1] and reverted[2] the commits leading up to them.
The behavior of said bug fixed itself by taking a different approach[3],
specifically by a weaker enforcement of having `core.worktree` set in a
submodule [4].
The
On Fri, Dec 7, 2018 at 7:45 PM Jonathan Nieder wrote:
>
>
> Thanks for fixing it. May we forge your sign-off?
Yes please, guess I didn't read far enough down that document. My apologies.
Consider the previous patch email:
Signed-off-by: FeRD (Frank Dana)
Jonathan Tan writes:
> When a user runs "git commit" without specifying a message, an editor
> appears with advice:
>
> Please enter the commit message for your changes. Lines starting
> with '#' will be ignored, and an empty message aborts the commit.
>
> However, if the user supplies
On Fri, Dec 07, 2018 at 07:09:58PM -0500, George King wrote:
> My goal is to detect SGR color sequences, e.g. '\x1b[32m', that exist
> in the source text, and have my highlighter print escaped
> representations of those. For example, I have checked in files that
> are expected test outputs for
Stefan Beller writes:
> A couple days before the 2.19 release we had a bug report about
> broken submodules[1] and reverted[2] the commits leading up to them.
>
> The behavior of said bug fixed itself by taking a different approach[3],
> specifically by a weaker enforcement of having
Matthew DeVore writes:
> $ git -C pc1 fetch-pack --stdin "file://$(pwd)/srv.bare"
> Where observed.oids contains all the blobs that were missing. It tells
> the remote that it already has the "refs/heads/master" commit, which
> means it is excluded. Before, this worked fine, since it didn't
On Fri, Dec 7, 2018 at 10:08 PM Junio C Hamano wrote:
>
> Stefan Beller writes:
>
> > On Fri, Dec 7, 2018 at 1:40 PM Jonathan Nieder wrote:
> >>
> >> Brandon Williams wrote:
> >>
> >> > Signed-off-by: Brandon Williams
> >> > ---
> >> > .mailmap | 1 +
> >> > 1 file changed, 1 insertion(+)
>
git version 2.19.1
steps to reproduce:
# start in a brand new repo
git init
# create lots of unreachable loose objects
for i in {1..1}; do git commit-tree -m "$(head -c 12 /dev/urandom
| base64)" "$(git mktree <&-)" <&-; done
# this prints a lot of output and takes a minute or so to run
#
On Fri, 07 Dec 2018, Yaroslav Halchenko wrote:
> On Fri, 07 Dec 2018, Stefan Beller wrote:
> > > the initial "git submodule update --reset-hard" is pretty much a
> > > crude workaround for some of those cases, so I would just go earlier in
> > > the history, and redo some things, whenever I
Jonathan Nieder writes:
>> So it seems most sensible to me if this is going to be supported that we
>> go a bit beyond the call of duty and fake up the start of it, namely:
>>
>> --- a/arch/x86/kernel/process.c
>> +++ b/arch/x86/kernel/process.c
>>
>> To be:
>>
>> diff --git
Stefan Beller writes:
> This re-introduces 984cd77ddb (submodule deinit: unset core.worktree,
> 2018-06-18), which was reverted as part of f178c13fda (Revert "Merge
> branch 'sb/submodule-core-worktree'", 2018-09-07)
>
> The whole series was reverted as the offending commit e98317508c
>
On Fri, 07 Dec 2018, Stefan Beller wrote:
> > the initial "git submodule update --reset-hard" is pretty much a
> > crude workaround for some of those cases, so I would just go earlier in
> > the history, and redo some things, whenever I could just drop or revert
> > some selected set of commits.
On Fri, Dec 7, 2018 at 6:14 PM Josh Wolfe wrote:
>
> git version 2.19.1
> steps to reproduce:
>
> # start in a brand new repo
> git init
>
> # create lots of unreachable loose objects
> for i in {1..1}; do git commit-tree -m "$(head -c 12 /dev/urandom
> | base64)" "$(git mktree <&-)" <&-;
Stefan Beller writes:
> On Fri, Dec 7, 2018 at 1:40 PM Jonathan Nieder wrote:
>>
>> Brandon Williams wrote:
>>
>> > Signed-off-by: Brandon Williams
>> > ---
>> > .mailmap | 1 +
>> > 1 file changed, 1 insertion(+)
>>
>> I can confirm that this is indeed the same person.
>
> What would be more
Stefan Beller writes:
> This reintroduces 4fa4f90ccd (submodule: unset core.worktree if no working
> tree is present, 2018-06-12), which was reverted as part of f178c13fda
> (Revert "Merge branch 'sb/submodule-core-worktree'", 2018-09-07).
>
> 4fa4f90ccd was reverted as its followup commit was
Stefan Beller writes:
> Shortly after f178c13fda (Revert "Merge branch
> 'sb/submodule-core-worktree'", 2018-09-07), we had another series
> that implemented partially the same, ensuring that core.worktree was
> set in a checked out submodule, namely 74d4731da1 (submodule--helper:
> replace
On Fri, Dec 07, 2018 at 01:50:57PM -0800, biswaranjan panda wrote:
> Thanks Jeff and Bryan! However, I am curious that if there were a way
> to tell git blame to skip a commit (the one which added the file again
> and maybe the one which deleted it originally) while it walks back
> through
With Due Respect,
I know that this mail will come to you as a surprise as we have never
met before, but need not to worry as I am contacting you independently
of my investigation and no one is informed of this communication. I
need your urgent assistance in transferring the sum of $11.3million
On Thu, Dec 06, 2018 at 03:54:46PM -0800, Jonathan Tan wrote:
> This makes sense - I thought I shouldn't mention the commit graph in the
> code since it seems like a layering violation, but I felt the need to
> mention commit graph in a comment, so maybe the need to mention commit
> graph in the
Hello; kindly see the attached my proposal Charities donation.
Mrs. Joy Smith Johnson.rtf
Description: RTF file
On Thu, Dec 06, 2018 at 12:20:54PM -0800, Josh Steadmon wrote:
> diff --git a/commit-graph.c b/commit-graph.c
> index 07dd410f3c..224a5f161e 100644
> --- a/commit-graph.c
> +++ b/commit-graph.c
> @@ -165,10 +165,20 @@ struct commit_graph *parse_commit_graph(void
> *graph_map, int fd,
>
63 matches
Mail list logo
