Hi Junio,
On Wed, 24 Oct 2018, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget"
> writes:
>
> > +...
> > + d="$(git -C shallow-server rev-parse --verify D)" &&
> > + git -C shallow-server checkout master &&
> > +
> > +...
> > + ! grep $d shallow-client/.git/shallow &&
>
>
Stefan Beller writes:
>> You would want to be able to remove a submodule and replace it with
>> a directory, but you can probably do it in two steps, i.e.
>>
>> git reset --hard
>> git rm --cached sha1collisiondetection
>> echo Now a regular dir
"Johannes Schindelin via GitGitGadget"
writes:
> From: Johannes Schindelin
>
> A `git fetch --prune` can turn previously-reachable objects unreachable,
> even commits that are in the `shallow` list. A subsequent `git repack
> -ad` will then unceremoniously drop those unreachable commits, and
This bug report came in via Git for Windows (already with version 2.19.0,
but I misread the reporter's enthusiasm to take matters into his own hands).
The culprit is, in a nutshell, that the built-in rebase tries to run git
stash only when the worktree is dirty, but it includes submodules
From: Johannes Schindelin
A `git fetch --prune` can turn previously-reachable objects unreachable,
even commits that are in the `shallow` list. A subsequent `git repack
-ad` will then unceremoniously drop those unreachable commits, and the
`shallow` list will become stale. This means that when
On Sun, Oct 21, 2018 at 7:52 PM Junio C Hamano wrote:
>
> Jonathan Nieder writes:
>
> > Stefan Beller wrote:
> >
> >> Maybe for now we can do with just an update of the documentation/bugs
> >> section and say we cannot move files in and out of submodules?
> >
> > I think we have some existing
Jonathan Nieder writes:
> Stefan Beller wrote:
>
>> Maybe for now we can do with just an update of the documentation/bugs
>> section and say we cannot move files in and out of submodules?
>
> I think we have some existing logic to prevent "git add"-ing a file
> within a submodule to the
On 20 Oct 2018, at 01:03, Duy Nguyen wrote:
>foo**bar would match foobar as well as foo/bar, foo/x/bar and
>foo/x/y/bar... Its behavior is error prone in my opinion. There's also
>some concerns in early iterations of this "**" support that we would
>need to revisit if we want 'rsync' behavior.
On Sat, Oct 20, 2018 at 7:53 AM dana wrote:
>
> On 20 Oct 2018, at 00:26, Duy Nguyen wrote:
> >Which way should we go? I'm leaning towards the second one...
>
> Not sure how much my opinion is worth, but the second option does feel more
> friendly (from a usage perspective) as well as more
On 20 Oct 2018, at 00:26, Duy Nguyen wrote:
>Which way should we go? I'm leaning towards the second one...
Not sure how much my opinion is worth, but the second option does feel more
friendly (from a usage perspective) as well as more straight-forward (from a
re-implementation perspective).
in these files is based on
> git's official documentation, as seen here:
>
> https://git-scm.com/docs/gitignore
>
> One of the most common reports on the ripgrep bug tracker is that it does not
> allow patterns like the following real-world examples, where a ** is used
> along
&g
Stefan Beller wrote:
> Maybe for now we can do with just an update of the documentation/bugs
> section and say we cannot move files in and out of submodules?
I think we have some existing logic to prevent "git add"-ing a file
within a submodule to the superproject, for example.
So "git mv"
remote(s):
> origing...@github.com:---/wiki-public.git
> If you want to reuse this local git directory instead of cloning again from
> g...@github.com:---/wiki-public.git
> use the '--force' option. If the local git directory is not the correct repo
> or y
. If the local git directory is not the correct repo
or you are unsure what this means choose another name with the '--name'
option.
Therefore, it's in a undefined, broken state.
Another bug I've got by testing upper line:
* --force will be used as folder name * when used in `git submodule add
g
On Mon, Oct 15, 2018 at 12:57 AM Junio C Hamano wrote:
>
> Duy Nguyen writes:
>
> >> Our matching function comes from rsync originally, whose manpage says:
> >>
> >> use ’**’ to match anything, including slashes.
> >>
> >> I believe this is accurate as far as the implementation goes.
> >
> >
Duy Nguyen writes:
>> Our matching function comes from rsync originally, whose manpage says:
>>
>> use ’**’ to match anything, including slashes.
>>
>> I believe this is accurate as far as the implementation goes.
>
> No. "**" semantics is not the same as from rsync. The three cases
> "**/",
epo (or any other
> > directory tree). ripgrep's support for the patterns in these files is based
> > on
> > git's official documentation, as seen here:
> >
> > https://git-scm.com/docs/gitignore
> >
> > One of the most common reports on the ripgrep b
;using. I.e. ask git given its .gitignore and .gitattributes what thing
>matches one of its pathspecs instead of carrying your own bug-compatible
>implementation.
My impression is that it probably isn't practical to use something like that as
ripgrep's main pattern-matching facility — for one
Ok,
my bad. I had a global pre-commit hook which had a lingering etckeeper command
for another repository.
Not quite sure why it only runs when commit has the '-a' option...
Thanks for pointing to the hooks possibility.
Naja Melan
Lily Ballard writes:
> I haven’t checked any other commands that the glossary lists as
> taking pathspecs (except `git add`, which does properly list it as
> taking pathspecs), so I don’t know if any of the other commands
> incorrectly list themselves as taking files when they take
> pathspecs.
In some cases in this file, BUG makes more sense than die. In such
cases, a we get there from a coding error rather than a user error.
'return' has been removed following some instances of BUG since BUG does
not return.
Signed-off-by: Matthew DeVore
---
list-objects-filter.c | 11
ased on
> git's official documentation, as seen here:
>
> https://git-scm.com/docs/gitignore
>
> One of the most common reports on the ripgrep bug tracker is that it does not
> allow patterns like the following real-world examples, where a ** is used
> along
> with ot
On 11 Oct 2018, at 05:19, dana wrote:
>git itself happily accepts these patterns, however, apparently treating the **
>like a single * without fnmatch(3)'s FNM_PATHNAME flag set (in other words, it
>matches / as a regular character, thus crossing directory boundaries).
Sorry for replying to
-scm.com/docs/gitignore
One of the most common reports on the ripgrep bug tracker is that it does not
allow patterns like the following real-world examples, where a ** is used along
with other text within the same path component:
**/**$$*.java
**.orig
**local.properties
!**.sha1
The reason
index.
If a cache entry were to refer to a non-existing entry in the shared
index, then that's a sign of something being wrong in the index state,
either as a result of a bug in dealing with the split/shared index
entries, or perhaps a (potentially unrelated) memory corruption issue
`git ls-files` takes zero or more s, but the manpage (and the `-h`
output) lists it as taking zero or more s instead. This is confusing as
is documented in `man git` as a filename, without any magic. But a
pathspec has a lot of special handling. The gitglossary entry for pathspec does
say
Hello,
Am 10.10.2018 um 01:38 schrieb Артем Семенов:
> Hello.
>
> Git svn bug on merging svn branches:
>
> Svn repository (branches tag trunk).
>
> 1. Add a some file by svn tools.
> 2. Create a new branch by svn tools (e.g. br1) .
> 3. Create a new branch by svn to
/etc/.git/hooks/pre-commit is installed by etckeeper and runs
etckeeper pre-commit, which deals with /etc/.etckeeper, including
running "git add .etckeeper". Why that file would match a gitignore
seems much less important than why git would run that hook in an
entirely different git repository.
On Wed, Oct 10, 2018 at 09:33:00AM +, Naja Melan wrote:
> I ran into a strange bug. In the following script the commit at the end will
> fail with:
>
> > The following paths are ignored by one of your .gitignore files:
> > .etckeeper
> > Use -f if you really
I am running:
Linux 4.18.12-arch1-1-ARCH #1 SMP PREEMPT Thu Oct 4 01:01:27 UTC 2018 x86_64
GNU/Linux
git version 2.19.1
etckeeper Version: 1.18.8
I ran into a strange bug. In the following script the commit at the end will
fail with:
> The following paths are ignored by one of y
> This whole version looks good to me. "git am" is supposed to understand
> attachments, but it seems to want to apply our whole conversation as the
> commit message.
>
> You may want to repost one more time with this subject in the email
> subject line to fix that and to get the maintainer's
Hello.
Git svn bug on merging svn branches:
Svn repository (branches tag trunk).
1. Add a some file by svn tools.
2. Create a new branch by svn tools (e.g. br1) .
3. Create a new branch by svn tools on branch br1 (e.g. br2).
4. Add some changes to file f1 in branch br1. Commit by svn tools.
5
y enough to set the colors explicitly. After doing this
> I noticed that green seems to be skipped. Not sure if that's a bug or
> not.
Hmm, yeah, that is weird. I think it's an artifact of the way we
increment the color selector, though, and not related to your patch (the
same thing happens before yo
In some cases in this file, BUG makes more sense than die. In such
cases, a we get there from a coding error rather than a user error.
'return' has been removed following some instances of BUG since BUG does
not return.
Signed-off-by: Matthew DeVore
---
list-objects-filter.c | 11
On Fri, Oct 05, 2018 at 09:17:54AM -0300, Eneas Queiroz wrote:
> Em qui, 4 de out de 2018 às 18:45, SZEDER Gábor
> escreveu:
> >
> > On Thu, Oct 04, 2018 at 06:01:11PM -0300, Eneas Queiroz wrote:
> > > I've sent this to the list 2 days ago, but I can't find it in the list
> > > archives, so I'm
Em qui, 4 de out de 2018 às 18:45, SZEDER Gábor escreveu:
>
> On Thu, Oct 04, 2018 at 06:01:11PM -0300, Eneas Queiroz wrote:
> > I've sent this to the list 2 days ago, but I can't find it in the list
> > archives, so I'm sending it again without files attached. I apologize
> > if this is a
On Thu, Oct 04, 2018 at 06:01:11PM -0300, Eneas Queiroz wrote:
> I've sent this to the list 2 days ago, but I can't find it in the list
> archives, so I'm sending it again without files attached. I apologize
> if this is a duplicate. One should be able to reproduce this with the
> current PR
I've sent this to the list 2 days ago, but I can't find it in the list
archives, so I'm sending it again without files attached. I apologize
if this is a duplicate. One should be able to reproduce this with the
current PR files, but if not, I can provide them.
I've hit a strange error while
> This seems to break 5520 and 5616 when merged to 'pu'.
>
> It seems that merging master to md/filter-trees and then applying
> this is sufficient to break 5616.
I verified that 5616 is broken on [master + md/filter-trees + my patch],
and after investigation, found a bug in th
he exact sequence of default
> colors, but I suspect it's not the first time. And it wouldn't be too
> hard to update it if that default changes.
Well, it's easy enough to set the colors explicitly. After doing this
I noticed that green seems to be skipped. Not sure if that's a bug or
not.
In some cases in this file, BUG makes more sense than die. In such
cases, a we get there from a coding error rather than a user error.
'return' has been removed following some instances of BUG since BUG does
not return.
Signed-off-by: Matthew DeVore
---
list-objects-filter.c | 11
On Mon, Sep 24, 2018 at 08:27:47PM -0400, Noam Postavsky wrote:
> > So I think this is doing the right thing. I'm not sure if there's a
> > better way to explain "dashless" or not.
>
> I've updated the comments and renamed a few variables, see if that helps.
Yeah, I really like your
On Mon, 24 Sep 2018 at 20:27, Noam Postavsky
wrote:
>
> On Sat, 8 Sep 2018 at 12:13, Jeff King wrote:
>
> > Great (and sorry for the delayed response).
>
> No problem, I know it's not the most urgent bug ever :)
Ping. :)
> I managed to recast my script into the framew
I instructed downstream to update their repository.
On Mon, Oct 1, 2018 at 2:31 PM Raymond Jennings wrote:
>
> Yes, git 2.16.4 to be exact.
>
> I upgraded to 2.19 after ~arch keywording the package on gentoo and
> that fixed it.
> On Mon, Oct 1, 2018 at 12:19 PM Stefan Beller wrote:
> >
> > On
Yes, git 2.16.4 to be exact.
I upgraded to 2.19 after ~arch keywording the package on gentoo and
that fixed it.
On Mon, Oct 1, 2018 at 12:19 PM Stefan Beller wrote:
>
> On Sat, Sep 29, 2018 at 9:43 AM Raymond Jennings wrote:
> >
> > I have a repo, but it appears to be specific to staging area
On Sat, Sep 29, 2018 at 9:43 AM Raymond Jennings wrote:
>
> I have a repo, but it appears to be specific to staging area state.
> It only segfaults when I have a certain file deleted.
>
> Where do you want me to upload it?
> On Sat, Sep 29, 2018 at 8:34 AM Duy Nguyen wrote:
> >
> > On Sat, Sep
I have a repo, but it appears to be specific to staging area state.
It only segfaults when I have a certain file deleted.
Where do you want me to upload it?
On Sat, Sep 29, 2018 at 8:34 AM Duy Nguyen wrote:
>
> On Sat, Sep 29, 2018 at 5:31 PM Ævar Arnfjörð Bjarmason
> wrote:
> > > #1
On Sat, Sep 29, 2018 at 5:31 PM Ævar Arnfjörð Bjarmason
wrote:
> > #1 refs_resolve_ref_unsafe (refs=0x0,
> > refname=refname@entry=0x55e863062253 "HEAD",
> > resolve_flags=resolve_flags@entry=1, oid=oid@entry=0x7ffdc834b1c0,
> > flags=flags@entry=0x7ffdc834b1bc) at refs.c:1493
refs is NULL. It
On Sat, Sep 29 2018, Raymond Jennings wrote:
> [New LWP 19644]
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib64/libthread_db.so.1".
> Core was generated by `git submodule--helper status'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0
[New LWP 19644]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `git submodule--helper status'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 refs_read_raw_ref (type=, referent=,
oid=, refname=,
Jonathan Nieder wrote:
> Junio C Hamano wrote:
>> OK. This unfortunately came a bit too late for today's integration
>> cycle, so I'll leave this in my inbox and replace what is queued
>> with it later.
>>
>> Unless there is another one to supersede this proposal comes before
>> that happens,
Junio C Hamano wrote:
> OK. This unfortunately came a bit too late for today's integration
> cycle, so I'll leave this in my inbox and replace what is queued
> with it later.
>
> Unless there is another one to supersede this proposal comes before
> that happens, that is.
>
> Thanks.
Sounds
Jonathan Nieder writes:
> My experience is that bug reporters are very sensitive to hints the
> project gives about what kind of bugs they want to receive. I'd
> rather make use of that lesson now instead of waiting to relearn it in
> the wild. Here goes.
OK. This unfortunatel
Subject: git doc: direct bug reporters to mailing list archive
The mailing list archive can help a user encountering a bug to tell
whether a recent regression has already been reported and whether a
longstanding bug has already had some discussion to start their
thinking.
Based-on-patch
builtin/commit.c:prepare_to_commit() can call run_status() twice if
using the editor, including status, and the user attempts to record a
non-merge empty commit without explicit --allow-empty. If there is also
a rename involved as well (due to using 'git add -N'), then a BUG in
wt-status.c
On Thu, Sep 27, 2018 at 9:20 AM Elijah Newren wrote:
> Subject: [PATCH] commit: fix erroneous BUG, 'multiple renames on the same
> target? how?'
>
> builtin/commit.c:prepare_to_commit() can call run_status() twice if
> using the editor, including status, and the user attempts to
On Thu, Sep 27, 2018 at 3:20 AM Elijah Newren wrote:
> Subject: [PATCH] commit: fix erroneous BUG, 'multiple renames on the same
> target? how?'
> [...]
> Signed-off-by: Elijah Newren
> ---
> diff --git a/t/t7500-commit.sh b/t/t7500-commit.sh
> @@ -359,4 +359,27 @@ test_exp
On Wed, Sep 26, 2018 at 9:20 PM Elijah Newren wrote:
> On Wed, Sep 26, 2018, 2:27 PM Ævar Arnfjörð Bjarmason
> wrote:
> > On Wed, Sep 26 2018, Andrea Stacchiotti wrote:
> >
> > > I'm very sorry, I indeed forgot the `diff.renames=copies`.
> > >
> > &g
On Wed, Sep 26, 2018, 2:27 PM Ævar Arnfjörð Bjarmason wrote:
>
> On Wed, Sep 26 2018, Andrea Stacchiotti wrote:
>
> > I'm very sorry, I indeed forgot the `diff.renames=copies`.
> >
> > The following script can reproduce the bug even with a blank config:
Thanks for th
I'm very sorry, I indeed forgot the `diff.renames=copies`.
The following script can reproduce the bug even with a blank config:
-
# Make a test repo
git init testrepo
cd testrepo
git config user.name A
git config user.email B
git config diff.renames copies
# Add a file
On Wed, Sep 26 2018, Andrea Stacchiotti wrote:
> Dear maintainer(s),
>
> the following script, when executed with git 2.19 triggers the bug in
> the subject line.
> The problem seems to be the interaction between add -N and rename detection.
>
> The git binary used is the o
Dear maintainer(s),
the following script, when executed with git 2.19 triggers the bug in
the subject line.
The problem seems to be the interaction between add -N and rename detection.
The git binary used is the one currently packaged in Debian unstable.
I have searched the list for the bug
On Tue, Sep 25, 2018 at 6:05 PM Duy Nguyen wrote:
>
> On Tue, Sep 25, 2018 at 5:41 PM Sebastian Kuzminsky wrote:
> > That behavior seems to me to be different from what the (2.11) manpage says:
>
> Good opportunity to improve the man page anyway even if Junio is
> right. I agree that the section
On Tue, Sep 25, 2018 at 5:41 PM Sebastian Kuzminsky wrote:
> That behavior seems to me to be different from what the (2.11) manpage says:
Good opportunity to improve the man page anyway even if Junio is
right. I agree that the section about "search strategy" is a bit
misleading because it does
On 9/24/18 4:24 PM, Junio C Hamano wrote:
Sebastian Kuzminsky writes:
I've got two tiny git repos whose commit graphs are identical, but
where 'git describe' gives different results. ... The histories
differ only in the timestamps of the commits...
describe does take the commit timestamps
On Sat, 8 Sep 2018 at 12:13, Jeff King wrote:
> Great (and sorry for the delayed response).
No problem, I know it's not the most urgent bug ever :)
> So I think this is doing the right thing. I'm not sure if there's a
> better way to explain "dashless" or not.
I've u
Sebastian Kuzminsky writes:
> I've got two tiny git repos whose commit graphs are identical, but
> where 'git describe' gives different results.
> ...
> The histories differ only in the timestamps of the commits...
describe does take the commit timestamps into account, so it is
expected you
I think I've run in to a bug in 'git describe' (reproduced with git
2.11.0, 2.16.1, and 2.19.0.221.g150f307af).
I've got two tiny git repos whose commit graphs are identical, but where
'git describe' gives different results.
* merge 1.1 into 2.0 (HEAD -> release-
d to:
>
> super_sub_len = strlen(super_sub);
>
> then only the first returned entry is used, and the bug is resolved.
>
> strlen() should be safe to use here because strbuf_read ensures the result
> buffer is null-terminated.
This is good analysis of the is
b_len:
super_sub_len = sb.buf + sb.len - super_sub - 1;
will only work when there is exactly one entry returned. If this line is
changed to:
super_sub_len = strlen(super_sub);
then only the first returned entry is used, and the bug is resolved.
strlen() should be safe to use
In some cases in this file, BUG makes more sense than die. In such
cases, a we get there from a coding error rather than a user error.
'return' has been removed following some instances of BUG since BUG does
not return.
Signed-off-by: Matthew DeVore
---
list-objects-filter.c | 11
Junio C Hamano writes:
> Well, reading builtin/merge-base.c::handle_fork_point(), I think the
> intended behaviour is:
>
> - die() when input is not well formed (e.g. bad commit object,
>ambigous ref name, etc.); there is an error worth reporting in
>this case.
>
> - show one that used
Eric Sunshine writes:
> On Wed, Sep 19, 2018 at 6:25 PM Alexander Mills
> wrote:
>> The following command sequence exits with 1, and no stderr
>>
>> base='remotes/origin/dev';
>> fork_point="$(git merge-base --fork-point "$base")";
>>
>> I cannot figure out why it's exiting with 1, but there is
On Wed, Sep 19, 2018 at 6:25 PM Alexander Mills
wrote:
> The following command sequence exits with 1, and no stderr
>
> base='remotes/origin/dev';
> fork_point="$(git merge-base --fork-point "$base")";
>
> I cannot figure out why it's exiting with 1, but there is no stdout/stderr
Unable to
The following command sequence exits with 1, and no stderr
base='remotes/origin/dev';
fork_point="$(git merge-base --fork-point "$base")";
I cannot figure out why it's exiting with 1, but there is no stdout/stderr
-alex
--
Alexander D. Mills
¡¡¡ New cell phone number: (415)730-1805 !!!
pathspec
is not consumed only by match_pathspec() then it should reject 'attr',
otherwise we'll get this "BUG" again.
--
Duy
The following:
git add -u :\(glob,attr:-someAttr\):src/**
Produces an error that, according to the source code, should never be visible
to the user. This attribute/pathspec *should* be supported according to the
documentation provided by git:
fatal: BUG:builtin/add.c:498: unsupported magic 40
On Fri, Sep 14, 2018 at 10:20 PM Niko Dzhus wrote:
> Looks like the issue appeared after updating git from brew.
>
> A quick search revealed that brew changed how it builds git recently.
> I think, it just didn't include i18n by default before, so I never
> noticed this.
>
> Anybody here familiar
Looks like the issue appeared after updating git from brew.
I tried it on a different mac laptop, git 2.18 still used English, but
after updating to 2.19 it started using secondary language.
A quick search revealed that brew changed how it builds git recently.
I think, it just didn't include
Tried what you suggested - it seems, it only ignores English. In you
example, with Swedish as primary and German as secondary, git uses
Swedish.
With more that one secondary language, the one with a higher priority
is being used, as expected. I also tried using non-generic English
(English-UK and
On Fri, Sep 14 2018, Niko Dzhus wrote:
> It doesn't use English when other language is available as a secondary
> language.
>
> Reproducing:
>
> 1. Open "Language & Region" in macos settings
> 2. In "Preferred languages" box, set English as a primary language.
> 3. Add another language, that
It doesn't use English when other language is available as a secondary language.
Reproducing:
1. Open "Language & Region" in macos settings
2. In "Preferred languages" box, set English as a primary language.
3. Add another language, that git is translated to, as a secondary
language, for
In some cases in this file, BUG makes more sense than die. In such
cases, a we get there from a coding error rather than a user error.
'return' has been removed following some instances of BUG since BUG does
not return.
Signed-off-by: Matthew DeVore
---
list-objects-filter.c | 11
"Eckhard Maaß" writes:
> On Mon, Sep 10, 2018 at 09:03:10AM -0700, Junio C Hamano wrote:
>> It is neither but if I have to pick one between the two, it is much
>> closer to the former than the latter. The primary source of this is
>> that we have only *one* pathspec given to the diff machinery,
On Mon, Sep 10, 2018 at 09:03:10AM -0700, Junio C Hamano wrote:
> It is neither but if I have to pick one between the two, it is much
> closer to the former than the latter. The primary source of this is
> that we have only *one* pathspec given to the diff machinery, but in
> order to implement
Jeff King writes:
> Your explanation is correct. To be fair, though, it seems like
> --find-copies-harder is made a lot less useful by the not considering
> the larger set of sources, since that's kind of its point. I'm not sure
> if this behavior actually is intentional, or simply what happens
On Sun, Sep 09, 2018 at 12:04:58PM -0700, Bryan Turner wrote:
> Here, though, you've _explicitly limited_ Git to only the copied file.
> It's not allowed to consider any others, which means it can't "see"
> the source path anymore. As a result, the copy is detected as a
> straight add. Note that
On Sun, Sep 9, 2018 at 6:31 AM Dylan Young wrote:
>
> Works:
>
> git show -C --find-copies-harder 055f6c89fa4506037d1621761f13430f469b8029
>
> git show -C --find-copies-harder
> 055f6c89fa4506037d1621761f13430f469b8029 --name-status
Here, because you didn't provide _any_ paths, Git is allowed
Works:
git show -C --find-copies-harder 055f6c89fa4506037d1621761f13430f469b8029
git show -C --find-copies-harder
055f6c89fa4506037d1621761f13430f469b8029 --name-status
Doesn’t Work:
git show -C --find-copies-harder
055f6c89fa4506037d1621761f13430f469b8029 -- PATH_TO_MY_COPIED_FILE
On Sat, Sep 01, 2018 at 08:34:41PM -0400, Noam Postavsky wrote:
> On 6 August 2018 at 17:26, Jeff King wrote:
>
> > I suspect it still has a bug, which is that it is handling this
> > first-parent-goes-left case, but probably gets the straight-parent case
> > wrong. But
Matthew DeVore writes:
> In some cases in this file, BUG makes more sense than die. In such
> cases, a we get there from a coding error rather than a user error.
>
> 'return' has been removed following some instances of BUG since BUG does
> not return.
>
> Signed-o
In some cases in this file, BUG makes more sense than die. In such
cases, a we get there from a coding error rather than a user error.
'return' has been removed following some instances of BUG since BUG does
not return.
Signed-off-by: Matthew DeVore
---
list-objects-filter.c | 11
en_lock_file() I guess it's even ok to just
> stick O_TRUNC in there and worry about O_APPEND when a new caller
> needs that.
That's the way I'm leaning to. The fix is obviously a one-liner, but I
was hoping to construct a minimal test case. I just haven't gotten
around to it yet.
The bug is ancient, so I don't think it's important for v2.19.
-Peff
On Tue, Sep 4, 2018 at 5:57 PM Junio C Hamano wrote:
>
> Jeff King writes:
>
> >> diff --git a/builtin/commit.c b/builtin/commit.c
> >> index 2be7bdb331..60f30b3780 100644
> >> --- a/builtin/commit.c
> >> +++ b/builtin/commit.c
> >> @@ -432,6 +432,7 @@ static const char *prepare_index(int argc,
Jeff King writes:
>> diff --git a/builtin/commit.c b/builtin/commit.c
>> index 2be7bdb331..60f30b3780 100644
>> --- a/builtin/commit.c
>> +++ b/builtin/commit.c
>> @@ -432,6 +432,7 @@ static const char *prepare_index(int argc, const char
>> **argv, const char *prefix
>> if
On Sun, Sep 02, 2018 at 09:53:53AM +0200, Luc Van Oostenryck wrote:
> > At any rate, I think this perfectly explains the behavior we're seeing.
>
> Yes, this certainly make sense.
>
> For fun (and testing) I tried to take the problem in the other direction:
> * why hasn't this be detected
On Sun, Sep 02, 2018 at 03:24:09AM -0400, Jeff King wrote:
> On Sun, Sep 02, 2018 at 09:12:04AM +0200, Duy Nguyen wrote:
> > diff --git a/builtin/commit.c b/builtin/commit.c
> > index 2be7bdb331..60f30b3780 100644
> > --- a/builtin/commit.c
> > +++ b/builtin/commit.c
> > @@ -432,6 +432,7 @@ static
On Sun, Sep 02, 2018 at 09:12:04AM +0200, Duy Nguyen wrote:
> > diff --git a/builtin/commit.c b/builtin/commit.c
> > index 0d9828e29e..779c5e2cb5 100644
> > --- a/builtin/commit.c
> > +++ b/builtin/commit.c
> > @@ -359,13 +359,6 @@ static const char *prepare_index(int argc, const char
> >
> The 'extension' pattern '$?+?', can vary a bit, sometimes
> > > it's just '', but always seems 4 chars.
> > > If the commit command doesn't use the '-p' flag, there is no
> > > problem. The repository itself is not corrupted, it's only
> > > th
> If the commit command doesn't use the '-p' flag, there is no
> > problem. The repository itself is not corrupted, it's only
> > the index. It happends with git 2.18.0 and 2.17.0
>
> Yeah this is a bug, I didn't dig much but testing with this script down
> to 2.8.0
101 - 200 of 4422 matches
Mail list logo
