wanted to
> replay the series on top of it to reach the goal of having `core.worktree`
> correctly set when the submodules worktree is present, and unset when the
> worktree is not present.
>
> The replay resulted in a strange merge conflict highlighting that
> the BUG m
c` does not fix the problem, and appears to do
> nothing in this situation:
> git gc
>
>
> According to the `git fetch` output, the `git help gc` docs, and the
> `git help prune` docs, I don't think I shouldn't ever have to run `git
> prune` manually, so this behavior see
ver have to run `git
prune` manually, so this behavior seems like a bug to me. Please
correct me if this is expected behavior.
In case anyone's wondering why I'm creating unreachable loose objects,
here's the usecase: https://stackoverflow.com/a/50403179/367916 . I
would love a first-class sol
of having `core.worktree`
correctly set when the submodules worktree is present, and unset when the
worktree is not present.
The replay resulted in a strange merge conflict highlighting that
the BUG message was not changed in 74d4731da1 (submodule--helper:
replace connect-gitdir-workingtree by ensure-cor
which calls
`bisect_next` which calls `git bisect--helper --next-all` which checks
the merge bases.
I think it is a bug.
`git bisect replay` is right to only update the references
(ref/bisect/*) and not to compute and checkout the best commit to test
at each step except at the end, but it sh
0 -0800 150)
DECL|function|tpm_common_open (struct file * file,struct tpm_chip
* chip,struct file_priv * priv)
now blame assigns the lines 29, 30, 53 and 54 to commit 391adba4
refactor!!! This is what I think is a bug.
(by the way, the changes made in this last commit were between 28
and 150)
than
Am 06.12.18 um 01:58 schrieb Junio C Hamano:
> Frank Schäfer writes:
>
>> Just to be sure that I'm not missing anything here:
>> What's your definition of "LF in repository, CRLF in working tree" in
>> terms of config parameters ?
> :::Documentation/config/core.txt:::
>
> core.autocrlf::
>
On Thu, 2018-12-06 at 17:31 +0100, Christian Couder wrote:
> > When Git replays the bisect log, it only updates refs/bisect/bad,
> > refs/bisect/good-*, refs/bisect/skip-* and reconstructs the log in
> > .git/BISECT_LOG. After that check_good_are_ancestors_of_bad() verifies
> > that all good
Hi,
On Thu, Dec 6, 2018 at 3:43 PM Lukáš Krejčí wrote:
>
> Hello again,
>
> after looking into this today, I'm not sure if this can be considered a
> bug - it's just that I expected Git to check out the exact commit to
> test that was there before resetting the bisect. That
Hello again,
after looking into this today, I'm not sure if this can be considered a
bug - it's just that I expected Git to check out the exact commit to
test that was there before resetting the bisect. That made me uncertain
whether Git restored the correct state.
When I looked at what Git
Hi,
When running "git add -p" on git version 2.19.2 and "diff.noprefix" set
to true, it still shows the "a/" and "b/" prefixes.
This issue has been reported in 2016 already[1], but is still there in
2.19.2.
[1]
https://public-inbox.org/git/e1d7329a-a54b-4d09-a72a-62eca8005...@gmail.com/T/
--
Frank Schäfer writes:
> Just to be sure that I'm not missing anything here:
> What's your definition of "LF in repository, CRLF in working tree" in
> terms of config parameters ?
:::Documentation/config/core.txt:::
core.autocrlf::
Setting this variable to "true" is the same as setting
Am 05.12.18 um 20:29 schrieb Frank Schäfer:
Am 02.12.18 um 22:22 schrieb Johannes Sixt:
Am 02.12.18 um 20:31 schrieb Frank Schäfer:
With other words:
"If CR comes immediately before a LF, do the following with *all* lines:
after the CR if eol=lf but do not after the CR if
eol=crlf."
Why?
Am 03.12.18 um 02:15 schrieb Junio C Hamano:
> Frank Schäfer writes:
>
>> Hi Junio,
>>
>> Am 29.11.18 um 03:11 schrieb Junio C Hamano:
>> [...]
>>> This was misspoken a bit. Let's revise it to
>>>
>>> When producing a colored output (not limited to whitespace
>>> error coloring of diff
Am 02.12.18 um 22:22 schrieb Johannes Sixt:
> Am 02.12.18 um 20:31 schrieb Frank Schäfer:
>> With other words:
>> "If CR comes immediately before a LF, do the following with *all* lines:
>> after the CR if eol=lf but do not after the CR if
>> eol=crlf."
>
> Why? It is the pager's duty to
On Tue, 2018-12-04 at 13:01 +0100, Christian Couder wrote:
> To debug I think it would be interesting to see the output of the
> following commands just before we get different results:
>
> git for-each-ref 'refs/bisect/*'
>
> and
>
> git log -1 --format=oneline
>
I placed the following
On Tue, Dec 4, 2018 at 12:20 PM Lukáš Krejčí wrote:
>
> On Tue, 2018-12-04 at 12:04 +0100, Christian Couder wrote:
> >
> > Could you try to check that? And first could you give us the output of:
> >
> > git merge-base 5b394b2ddf0347bef56e50c69a58773c94343ff3
> >
(I'm sorry about the formatting, here's the message again.)
Executing git bisect replay reaches a different commit than
the one that is obtained by running the commands from the bisect log manually.
Distribution: Arch Linux
git: 2.19.2-1
perl: 5.28.1-1
pcre2: 10.32-1
expat: 2.2.6-1
perl-error:
On Tue, 2018-12-04 at 12:04 +0100, Christian Couder wrote:
>
> Could you try to check that? And first could you give us the output of:
>
> git merge-base 5b394b2ddf0347bef56e50c69a58773c94343ff3
> 94710cac0ef4ee177a63b5227664b38c95bbf703
$ git merge-base 5b394b2ddf0347bef56e50c69a58773c94343ff3
On Tue, Dec 4, 2018 at 10:53 AM Lukáš Krejčí wrote:
>
> Executing git bisect replay reaches a different commit than
> the one that is obtained by running the commands from the bisect log manually.
> $ git bisect replay /var/tmp/git-bisect.log
> We are not bisecting.
> Bisecting: a merge base
Executing git bisect replay reaches a different commit than
the one that is obtained by running the commands from the bisect log manually.
Distribution: Arch Linux
git: 2.19.2-1
perl: 5.28.1-1
pcre2: 10.32-1
expat: 2.2.6-1
perl-error: 0.17027-1
grep: 3.1-2
bash: 4.4.023-1
no system
Frank Schäfer writes:
> Hi Junio,
>
> Am 29.11.18 um 03:11 schrieb Junio C Hamano:
> [...]
>> This was misspoken a bit. Let's revise it to
>>
>> When producing a colored output (not limited to whitespace
>> error coloring of diff output) for contents that are not
>> marked as
Am 02.12.18 um 20:31 schrieb Frank Schäfer:
Am 29.11.18 um 03:11 schrieb Junio C Hamano:
[...]
This was misspoken a bit. Let's revise it to
When producing a colored output (not limited to whitespace
error coloring of diff output) for contents that are not
marked as
Hi Junio,
Am 29.11.18 um 03:11 schrieb Junio C Hamano:
[...]
> This was misspoken a bit. Let's revise it to
>
> When producing a colored output (not limited to whitespace
> error coloring of diff output) for contents that are not
> marked as eol=crlf (and other historical
gt; > > v2.19.2, installed from brew on macOS Mojave 14.2.1.
> > >
> > > `git-gui` is my much beloved go-to tool for everything git.
> > > Unfortunately, on my new Macbook Air it seems to have a bug. When I
> > > first load the program, the parent window popula
On Wed, Nov 28, 2018 at 2:29 PM Stefan Beller wrote:
> On Wed, Nov 28, 2018 at 6:13 AM Kenn Sebesta wrote:
> > v2.19.2, installed from brew on macOS Mojave 14.2.1.
> >
> > `git-gui` is my much beloved go-to tool for everything git.
> > Unfortunately, on my new Macbook
Johannes Sixt writes:
> Am 27.11.18 um 00:31 schrieb Junio C Hamano:
>> Johannes Sixt writes:
>>> Am 26.11.18 um 04:04 schrieb Junio C Hamano:
>>> ... this goes too far, IMO. It is the pager's task to decode control
>>> characters.
>>
>> It was tongue-in-cheek suggestion to split a CR into
ally, when
copying a directory across sibling directories (see test case),
the new logic would accidentally send that object as an extra.
However, I found a bug in the existing logic. The included test
demonstrates this during the final 'git index-pack' call. It
fails with the message
'fatal
irectories (see test case),
the new logic would accidentally send that object as an extra.
However, I found a bug in the existing logic. The included test
demonstrates this during the final 'git index-pack' call. It
fails with the message
'fatal: pack has 1 unresolved delta'
It i
On Wed, Nov 28, 2018 at 6:13 AM Kenn Sebesta wrote:
>
> v2.19.2, installed from brew on macOS Mojave 14.2.1.
>
> `git-gui` is my much beloved go-to tool for everything git.
> Unfortunately, on my new Macbook Air it seems to have a bug. When I
> first load the program, the paren
v2.19.2, installed from brew on macOS Mojave 14.2.1.
`git-gui` is my much beloved go-to tool for everything git.
Unfortunately, on my new Macbook Air it seems to have a bug. When I
first load the program, the parent window populates normally with the
stage/unstaged and diff panes. However, when I
On Wed, Nov 28, 2018 at 01:47:41AM +, brian m. carlson wrote:
> On Tue, Nov 27, 2018 at 05:42:53PM +0100, Ævar Arnfjörð Bjarmason wrote:
> > Avoid a bug in dash that's been fixed ever since its
> > ec2c84d ("[PARSER] Fix clobbering of checkkwd", 2011-03-15)[1] fir
Eric Sunshine writes:
> On Tue, Nov 27, 2018 at 11:43 AM Ævar Arnfjörð Bjarmason
> wrote:
>> Avoid a bug in dash that's been fixed ever since its
>> ec2c84d ("[PARSER] Fix clobbering of checkkwd", 2011-03-15)[1] first
>> released with dash v0.5.7 in July 20
On Tue, Nov 27, 2018 at 05:42:53PM +0100, Ævar Arnfjörð Bjarmason wrote:
> Avoid a bug in dash that's been fixed ever since its
> ec2c84d ("[PARSER] Fix clobbering of checkkwd", 2011-03-15)[1] first
> released with dash v0.5.7 in July 2011.
>
> This fixes 1/2 test
Am 27.11.18 um 19:15 schrieb Johannes Sixt:
> Am 27.11.18 um 00:31 schrieb Junio C Hamano:
>> Johannes Sixt writes:
>>> Am 26.11.18 um 04:04 schrieb Junio C Hamano:
>>> ... this goes too far, IMO. It is the pager's task to decode control
>>> characters.
>>
>> It was tongue-in-cheek suggestion
Am 27.11.18 um 00:31 schrieb Junio C Hamano:
> Johannes Sixt writes:
>
>> Am 26.11.18 um 04:04 schrieb Junio C Hamano:
>>> That does not sound right. I would understand it if both lines
>>> showed ^M at the end, and only the one on the postimage line had it
>>> highlighted as a
On Tue, Nov 27 2018, Eric Sunshine wrote:
> On Tue, Nov 27, 2018 at 11:43 AM Ævar Arnfjörð Bjarmason
> wrote:
>> Avoid a bug in dash that's been fixed ever since its
>> ec2c84d ("[PARSER] Fix clobbering of checkkwd", 2011-03-15)[1] first
>> released with das
On Tue, Nov 27, 2018 at 11:43 AM Ævar Arnfjörð Bjarmason
wrote:
> Avoid a bug in dash that's been fixed ever since its
> ec2c84d ("[PARSER] Fix clobbering of checkkwd", 2011-03-15)[1] first
> released with dash v0.5.7 in July 2011.
Perhaps enhance the commit message to
Am 27.11.18 um 00:31 schrieb Junio C Hamano:
Johannes Sixt writes:
Am 26.11.18 um 04:04 schrieb Junio C Hamano:
... this goes too far, IMO. It is the pager's task to decode control
characters.
It was tongue-in-cheek suggestion to split a CR into caret-em on our
end, but we'd get essentially
Avoid a bug in dash that's been fixed ever since its
ec2c84d ("[PARSER] Fix clobbering of checkkwd", 2011-03-15)[1] first
released with dash v0.5.7 in July 2011.
This fixes 1/2 tests failing on Debian Lenny & Squeeze. The other
failure is due to 1b42f45255 ("git-svn: apply &q
Johannes Sixt writes:
> Am 26.11.18 um 04:04 schrieb Junio C Hamano:
>>
>> That does not sound right. I would understand it if both lines
>> showed ^M at the end, and only the one on the postimage line had it
>> highlighted as a trailing-whitespace.
>
> I agree that this is a (small?) weakness.
Am 26.11.18 um 04:04 schrieb Junio C Hamano:
It appears to me that what Frank sees is not "^M highlighted for
whitespace breakage appears only on postimage lines, while ^M is
shown but not highlighted on preimage lines". My reading of the
above is "Not just without highlight, ^M is just *NOT*
Johannes Sixt writes:
> But incorrect whitespace is never highlighted in removed lines, why
> should CR be an exception?
> ...
> Same here for other cases, for example
>
> -something
> +something
>
> will not have on obvious indicator that whitespace was corrected.
All correct, but misses one
On Sun, Nov 25, 2018 at 03:03:11PM +0100, Frank Schäfer wrote:
> Am 24.11.18 um 23:07 schrieb Johannes Sixt:
> > I don't think that there is anything to fix. If you have a file with
> > CRLF in it, but you did not declare to Git that CRLF is the expected
> > end-of-line indicator, then the CR *is*
Am 25.11.18 um 15:03 schrieb Frank Schäfer:
Am 24.11.18 um 23:07 schrieb Johannes Sixt:
I don't think that there is anything to fix. If you have a file with
CRLF in it, but you did not declare to Git that CRLF is the expected
end-of-line indicator, then the CR *is* trailing whitespace (because
Am 24.11.18 um 23:07 schrieb Johannes Sixt:
> I don't think that there is anything to fix. If you have a file with
> CRLF in it, but you did not declare to Git that CRLF is the expected
> end-of-line indicator, then the CR *is* trailing whitespace (because
> the line ends at LF), and 'git diff'
Am 24.11.18 um 15:51 schrieb Frank Schäfer:
Am 23.11.18 um 22:47 schrieb Johannes Sixt:
Am 23.11.18 um 19:19 schrieb Frank Schäfer:
The CR marker ^M doesn't show up in '-' lines of diffs when the ending
of the removed line is CR+LF.
It shows up as expected in '-' lines when the ending of the
On Sat, Nov 24, 2018 at 03:51:26PM +0100, Frank Schäfer wrote:
[]
>
> Hmm... is CR-only line termination supported at all ?
> E.g. 'eol' can be set to 'lf' or 'crlf' but not 'cr'...
>
No, CR-only is not supported, because:
Nobody was implementing it, and that is probably because
the only
Am 23.11.18 um 22:47 schrieb Johannes Sixt:
> Am 23.11.18 um 19:19 schrieb Frank Schäfer:
>> The CR marker ^M doesn't show up in '-' lines of diffs when the ending
>> of the removed line is CR+LF.
>> It shows up as expected in '-' lines when the ending of the removed line
>> is CR only.
>> It also
Denton Liu writes:
> I just realised that there is a slight problem with the proposed change.
> When we do a merge and there are no merge conflicts, at the end of the
> merge, we get dropped into an editor with this text:
>
> Merge branch 'master' into new
>
> # Please enter a commit
Am 23.11.18 um 19:19 schrieb Frank Schäfer:
The CR marker ^M doesn't show up in '-' lines of diffs when the ending
of the removed line is CR+LF.
It shows up as expected in '-' lines when the ending of the removed line
is CR only.
It also always shows up as expected in '+' lines.
Is your
:
LF to CR+LF:
@@ -1,2 +1,2 @@
-aaa
+aaa^M
bbb
CR+LF to LF:
@@ -1,2 +1,2 @@
-aaa => BUG: should be -aaa^M
+aaa
bbb
CR to CR+LF:
@@ -1 +1,2 @@
-aaa^Mbbb
+aaa^M
+bbb
CR+LF to CR:
@@ -1,2 +1 @@
-aaa => BUG: should be -aaa^M
-bbb
+aaa^Mbbb
LF to CR:
@@ -1,2 +1 @@
-aaa
-bb
On Wed, Nov 21, 2018 at 06:38:20PM +0900, Junio C Hamano wrote:
> Denton Liu writes:
>
> > Changes since V3:
> > * Add patch to cleanup 'merge --squash c3 with c7' test in t7600
> > * Use test_i18ncmp instead of test_cmp to pass GETTEXT_POISON tests
>
> Queued. Thanks, both.
I just
Denton Liu writes:
> Changes since V3:
> * Add patch to cleanup 'merge --squash c3 with c7' test in t7600
> * Use test_i18ncmp instead of test_cmp to pass GETTEXT_POISON tests
Queued. Thanks, both.
* Add passthrough options in pull
* Add documentation for the new option
* Add tests to ensure desired behaviour
Changes since V2:
* Merge both patches into one patch
* Fix bug in help message printing logic
Changes since V3:
* Add patch to cleanup 'merge
ors use descriptor 5,
> > > > which goes to stdout. I'm not sure if those should actually be going to
> > > > stderr (or if there's some TAP significance to those lines).
> > >
> > > I chose to send these messages to standard error, because they are,
> > &g
actually be going to
> > > stderr (or if there's some TAP significance to those lines).
> >
> > I chose to send these messages to standard error, because they are,
> > well, errors. TAP only cares about stdout, but by aborting the test
> > script in BUG(), error()
o those lines).
>
> I chose to send these messages to standard error, because they are,
> well, errors. TAP only cares about stdout, but by aborting the test
> script in BUG(), error() or die() we are already violating TAP anyway,
> so I don't think it matters whether we send "b
On Mon, Nov 19, 2018 at 02:44:32PM -0500, Jeff King wrote:
> On Mon, Nov 19, 2018 at 02:13:26PM +0100, SZEDER Gábor wrote:
>
> > Send these "bug in the test script" error messages directly to the
> > test scripts standard error and thus to the terminal, so those
On Mon, Nov 19, 2018 at 02:13:26PM +0100, SZEDER Gábor wrote:
> Send these "bug in the test script" error messages directly to the
> test scripts standard error and thus to the terminal, so those bugs
> will be much harder to overlook. Instead of updating all ~20 s
Some of the functions in our test library check that they were invoked
properly with conditions like this:
test "$#" = 2 ||
error "bug in the test script: not 2 parameters to test-expect-success"
If this particular condition is triggered, then 'error' will abort t
Denton Liu writes:
>> I wonder if this is what you really meant to have instead:
>>
>> >else if (cleanup_mode == COMMIT_MSG_CLEANUP_SCISSORS &&
>> > - whence == FROM_COMMIT)
>> > - wt_status_add_cut_line(s->fp);
>> > + whence ==
being removed is now silenced in both cases.
Changes since V1:
* Only check MERGE_MSG for a scissors line instead of all prepended
files
* Make a variable static in merge where appropriate
* Add passthrough options in pull
* Add documentation for the
Thanks for your feedback, Junio.
I tried to reroll the patch by adding another option into the MERGE_MODE
file but unfortunately, it didn't work completely because doing `merge
--squash` doesn't produce a MERGE_MODE. In addition to this, because of
the way merge and commit were structured, I
g_options *opts,
>
> if (opts->commondir)
> repo_config = mkpathdup("%s/config", opts->commondir);
> + else if (opts->git_dir)
> + BUG("git_dir without commondir");
Yeah, I think this is the right thing to do. Thanks!
-Peff
f (opts->git_dir)
+ BUG("git_dir without commondir");
else
repo_config = NULL;
--
gitgitgadget
On Wed, Nov 14, 2018 at 04:52:59PM +0900, Junio C Hamano wrote:
> Denton Liu writes:
>
> > With this fix, the message becomes the following:
> >
> > Merge branch 'master' into new
> >
> > # >8
> > # Do not modify or remove the line
Denton Liu writes:
> With this fix, the message becomes the following:
>
> Merge branch 'master' into new
>
> # >8
> # Do not modify or remove the line above.
> # Everything below it will be ignored.
> #
> #
I discovered a bug in Git a while ago where if one is using
commit.cleanup = scissors, if making a commit after a merge conflict,
the scissors line will be placed after the `Conflicts:` section. As a
result, a careless Git user (e.g. me) may accidentally commit the
`Conflicts:` section.
Here
Johannes Schindelin writes:
> You misunderstand. In this case it is crucial to read the regression test
> first. The fix does not make much sense before one understands the
> condition under which the order of the code statements matters.
I am not sure what you mean. It sounds as if you want
Hi Junio,
On Tue, 13 Nov 2018, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> >> For a trivially small change/fix like this, it is OK and even
> >> preferrable to make 1+2 a single step, as applying t/ part only to
> >> try to see the breakage (or "am"ing everything and then "diff |
>
Johannes Schindelin writes:
>> For a trivially small change/fix like this, it is OK and even
>> preferrable to make 1+2 a single step, as applying t/ part only to
>> try to see the breakage (or "am"ing everything and then "diff |
>> apply -R" the part outside t/ for the same purpose) is easy
test_must_fail git rev-parse --verify HEAD^2 &&
>
> Even if we made an octopus by mistake, the above will catch it,
> which is good.
>
> > + test_path_is_missing .git/MERGE_HEAD
> > +'
> > +
> > test_done
>
> And from the proposed log message, I am reading that the last two
> things (i.e. resulting tip is a child with a single parent and there
> is no leftover MERGE_HEAD file) fail without the fix.
>
> This is enough material to convince me or anybody that the bug is
> worth fixing. Thanks for being careful noticing a glitch during
> your real (and otherwise unrelated to the bug) work and following
> through.
>
e --continue &&
> + test_must_fail git rev-parse --verify HEAD^2 &&
Even if we made an octopus by mistake, the above will catch it,
which is good.
> + test_path_is_missing .git/MERGE_HEAD
> +'
> +
> test_done
And from the proposed log message, I am readi
From: Johannes Schindelin
When calling `merge` on a branch that has already been merged, that
`merge` is skipped quietly, but currently a MERGE_HEAD file is being
left behind and will then be grabbed by the next `pick` (that did
not want to create a *merge* commit).
Demonstrate this.
g websites. E.g. here's two issues for fixing this
> on GitLab:
>
> https://gitlab.com/gitlab-org/gitlab-ce/issues/50201
> https://gitlab.com/gitlab-org/gitlab-ce/issues/50660
>
> These hosting platforms are intentionally producing bad error messages
> to not leak information, as
.
So I doubt it's something they'll ever change, the bug I have open with
this on GitLab is to make this configurable for privately run instances.
git clone of non-existent repository results in request for credentials
REPRODUCING:
sudo apt install git
git clone https://github.com/xorbit/LiFePo4owered-Pi.git#this repo does not
exist
Git will then prompt for username and password on Github.
I can see a valid data-leak concern (one
100644
--- a/parse-options.c
+++ b/parse-options.c
@@ -197,7 +197,7 @@ static int get_value(struct parse_opt_ctx_t *p,
return 0;
default:
- die("should not happen, someone must be hit on the forehead");
+ BUG("opt->type %d
cache_entry
*ce, struct stat *st)
changed |= DATA_CHANGED;
return changed;
default:
- die("internal error: ce_mode is %o", ce->ce_mode);
+ BUG("unsupported ce_mode: %o", ce->ce_mode);
The first error, "internal error", is clearly a BUG(). The second two
are meant to catch calls with invalid parameters and should never
happen outside the test suite.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
remote.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
ted.
Also no problem if the svn dump is filtered with "svndumpfilter
--drop-empty-revs" before load into a fresh repo.
I'll be able to provide the dump for further investigations. I would
send it on demand. I'm able to reproduce the failure with the dump. It
seemed many others had suffered f
gt;
> default:
> - die("should not happen, someone must be hit on the forehead");
> + BUG("opt->type %d should not happen", opt->type);
> }
> }
OK, this should not happen.
> @@ -424,7 +424,7 @@ void parse_options_start(struct par
Nguyễn Thái Ngọc Duy writes:
> The first error, "internal error", is clearly a BUG(). The second two
> are meant to catch calls with invalid parameters and should never
> happen outside the test suite.
Sounds as if it would happen inside test suites.
I guess by "in
ead-cache.c
> +++ b/read-cache.c
> @@ -316,7 +316,7 @@ static int ce_match_stat_basic(const struct cache_entry
> *ce, struct stat *st)
> changed |= DATA_CHANGED;
> return changed;
> default:
> - die("internal error:
100644
--- a/parse-options.c
+++ b/parse-options.c
@@ -197,7 +197,7 @@ static int get_value(struct parse_opt_ctx_t *p,
return 0;
default:
- die("should not happen, someone must be hit on the forehead");
+ BUG("opt->type %d
The first error, "internal error", is clearly a BUG(). The second two
are meant to catch calls with invalid parameters and should never
happen outside the test suite.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
remote.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
cache_entry
*ce, struct stat *st)
changed |= DATA_CHANGED;
return changed;
default:
- die("internal error: ce_mode is %o", ce->ce_mode);
+ BUG("unsupported ce_mode: %o", ce->ce_mode);
On Thu, Nov 01, 2018 at 12:48:04AM +, brian m. carlson wrote:
> > So a few questions:
> >
> > - is this a bug or not? I.e., do we still need to care about proxies
> > that can't handle Expect? The original commit was from 2011. Maybe
> > things are bet
at's because rather than going
> through post_rpc(), we push the stateless data through a proxy_state
> struct. And in proxy_state_init(), when we set up the headers, we do not
> disable curl's Expect handling.
>
> So a few questions:
>
> - is this a bug or not? I.e., do we st
ate
struct. And in proxy_state_init(), when we set up the headers, we do not
disable curl's Expect handling.
So a few questions:
- is this a bug or not? I.e., do we still need to care about proxies
that can't handle Expect? The original commit was from 2011. Maybe
things are better now. Or maybe th
On Wed, Oct 24, 2018 at 4:55 PM Christophe Bliard
wrote:
>
> Hi,
>
> I observed an unexpected behavior while using git grep with both git
> 2.19.1 and 2.14.3.
Quick note. I confirm this is a bug in tree_entry_interesting()
perhaps being over-optimistic. It'll take me more time
On Fri, Oct 26, 2018 at 09:30:51AM +0200, Raphael Stolt wrote:
> Configuration for global ignore patterns in ~/.config/git/config:
>
> [core]
> excludesfile = .gitignore
>
> doesn't get looked up per default in ~/.config/git/ which might be
> considered a bug as the
Configuration for global ignore patterns in ~/.config/git/config:
[core]
excludesfile = .gitignore
doesn't get looked up per default in ~/.config/git/ which might be
considered a bug as the .gitignore file isn't loaded. It's only loaded
when .gitignore is located in $HOME or explicitly
I noticed that the piped output still prints the (HEAD -> ) :
git log --pretty=format:"%d*%B" --decorate-refs='refs/tags/*'
*bar
(tag: "123")*foo
git log --pretty=format:"%d*%B" --decorate-refs='refs/tags/*' > tmp.tmp
(HEAD -> branch)*bar
(tag: "123")*foo
I would expect the output
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
6] fileB
> > 1 file changed, 1 insertion(+)
> > create mode 100644 fileB
> > > git --no-pager grep foo HEAD -- ':!fileA'
> > HEAD:fileB:foo is false+
> > > git --no-pager grep foo HEAD -- ':!fileB'
> > HEAD:fileA:foo
> > HEAD:fileB:foo is false+
>
, fileB appears in grep results but it should have
> been excluded.
>
> If the HEAD parameter is removed, it works as expected:
It's probably a bug. We have different code paths for matching things
with or without HEAD, roughly speaking. I'll look into to this more on
the weekend, unl
6410172300120130ustar00rootroot00foo
fileB664000161336410172300120170ustar00rootroot00foo
is false+
fileA can be excluded, but not fileB.
Is it a bug?
Thanks
--
Christophe Bliard
Hi Junio,
me again. I was wrong.
On Wed, 24 Oct 2018, Johannes Schindelin wrote:
> 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
1 - 100 of 4422 matches
Mail list logo
