Bug: duplicate sections in .git/config after remote removal

While the impact of this bug is minimal, and git itself is not affected, it can affect external tools that want to read the .git/config file, expecting unique section names. To reproduce: Given the following example .git/config file (I am leaving out the [core] section for brevity): [remote

git submodule deinit resulting in BUG: builtin/submodule--helper.c:1045: module_list_compute should not choke on empty pathspec

Hi, i tried to run "git submodule deinit xxx" on a submodule that was recently removed from the Rust project. But git responded with a BUG/Core dump (and also did not remove the submodule directory from the checkout). ~/src/rust/rust$ git submodule deinit src/rt/hoedown/ error: pathsp

Re: A bug in git merge

On Tue, Mar 27, 2018 at 12:53:52PM +0300, Orgad Shaneh wrote: > If I cherry-pick a commit that added a line, then merge another commit > which removes this line, the line remains in the file instead of being > removed. > > The following script demonstrates the bug. > > file

A bug in git merge

Hi, If I cherry-pick a commit that added a line, then merge another commit which removes this line, the line remains in the file instead of being removed. The following script demonstrates the bug. file should be equivalent on both branches git init seq 1 20 > file git add file git commit

Re: Should I try to fix rebase interactive preserve-merges bug

Hi Jake & Wink, On Sun, 25 Mar 2018, Jacob Keller wrote: > On Sun, Mar 25, 2018 at 10:32 AM, Wink Saville wrote: > > There is a "TODO known breakage" in t3404-rebase-interactve.sh: > > > >not ok 24 - exchange two commits with -p # TODO known breakage > > > > I'm

Re: Should I try to fix rebase interactive preserve-merges bug

> AFAIK this breakage of preserve-merges is a design flaw which isn't > really fixable, which is why --recreate-merges is being added. > > I believe the plan is to deprecate preserve-merges once > recreate-merges has landed. > > Thanks, > Jake Txs for the info, hopefully others will respond.

Re: Should I try to fix rebase interactive preserve-merges bug

On Sun, Mar 25, 2018 at 10:32 AM, Wink Saville wrote: > There is a "TODO known breakage" in t3404-rebase-interactve.sh: > >not ok 24 - exchange two commits with -p # TODO known breakage > > I'm contemplating trying to fix it. But with --recreate-merges coming > maybe it's

Should I try to fix rebase interactive preserve-merges bug

There is a "TODO known breakage" in t3404-rebase-interactve.sh: not ok 24 - exchange two commits with -p # TODO known breakage I'm contemplating trying to fix it. But with --recreate-merges coming maybe it's not worth the effort. Should I proceed with attempting a fix or is --preserve-merges

RE: Bug With git rebase -p

Hi Joseph, On Thu, 22 Mar 2018, Joseph Strauss wrote: > I meant to say that I installed 2.17.0-rc0, and it worked perfectly. Thank you for testing. Ciao, Johannes

RE: Bug With git rebase -p

gt; Cc: Joseph Strauss <josep...@bhphoto.com>; git@vger.kernel.org Subject: Re: Bug With git rebase -p Johannes Schindelin <johannes.schinde...@gmx.de> writes: > On Tue, 20 Mar 2018, Joseph Strauss wrote: > >> Perfect. Thank you. > > You are welcome. > > I am

Re: Bug With git rebase -p

Johannes Schindelin writes: > On Tue, 20 Mar 2018, Joseph Strauss wrote: > >> Perfect. Thank you. > > You are welcome. > > I am puzzled, though... does your message mean that you tested the Git for > Windows v2.17.0-rc0 installer and it did fix your problem? Or do you

RE: Bug With git rebase -p

Hi Joseph, On Tue, 20 Mar 2018, Joseph Strauss wrote: > Perfect. Thank you. You are welcome. I am puzzled, though... does your message mean that you tested the Git for Windows v2.17.0-rc0 installer and it did fix your problem? Or do you simply assume that it does fix your problem because Junio

Re: [BUG] log --graph corrupts patch

Jeff King writes: >> To make it bullet-proof, I think we'd have to actually parse the graph >> structure, finding a "*" line and then accepting only an indent that >> matched it. > > Wow. Nerd snipe successful. This turned out to be quite tricky, but also > kind of interesting.

Re: .gitattributes override behavior (possible bug, or documentation bug)

Dakota Hawkins writes: > At any rate, would it at least be a good idea to make the "trailing > slash halts recursion, won't consider nested .gitignore files" > explicit in the `.gitignore` doc? Unless I'm missing it, I don't think > that behavior is called out (or at

Re: .gitattributes override behavior (possible bug, or documentation bug)

On Wed, Mar 21, 2018 at 4:22 AM, Dakota Hawkins wrote: > Thinking about this a little more, I'm now attracted to the idea that > its .gitignore that's weird. > > As I understand it, .gitignore stops recursion when there's a > directory match (`somedir/`) but also

Re: .gitattributes override behavior (possible bug, or documentation bug)

On Wed, Mar 21, 2018 at 04:35:26AM -0400, Dakota Hawkins wrote: > > I think it means "for the rest of the description of how the patterns > > work". I.e., "foo/" matches as "foo" when the rest of the matching rules > > are applied. I agree it's a bit awkward. Patches welcome. :) > > I'd be more

Re: .gitattributes override behavior (possible bug, or documentation bug)

> I think it means "for the rest of the description of how the patterns > work". I.e., "foo/" matches as "foo" when the rest of the matching rules > are applied. I agree it's a bit awkward. Patches welcome. :) I'd be more than happy to do that! It will take me a while, this (email and

Re: .gitattributes override behavior (possible bug, or documentation bug)

On Wed, Mar 21, 2018 at 03:36:09AM -0400, Dakota Hawkins wrote: > > I think that ignoring all of /ignore-most/ is much more efficient, since > > we don't have to enumerate the paths inside it at all (which is why the > > current behavior works as it does). > > That's definitely true, but I

Re: .gitattributes override behavior (possible bug, or documentation bug)

One extra note: I was burned by this just a few hours ago in a new repo (but because of this discussion I realized what the problem was pretty quickly). In the top-level .gitignore I had build/ ... !alpine/build/ where `build/` was a stock ignore line among hundreds that I blindly

Re: .gitattributes override behavior (possible bug, or documentation bug)

> I think that ignoring all of /ignore-most/ is much more efficient, since > we don't have to enumerate the paths inside it at all (which is why the > current behavior works as it does). That's definitely true, but I wonder what the impact would be for most cases (even for most cases with large

Re: .gitattributes override behavior (possible bug, or documentation bug)

On Tue, Mar 20, 2018 at 11:22:02PM -0400, Dakota Hawkins wrote: > Thinking about this a little more, I'm now attracted to the idea that > its .gitignore that's weird. > > As I understand it, .gitignore stops recursion when there's a > directory match (`somedir/`) but also explicitly allows

Re: [BUG] log --graph corrupts patch

On Tue, Mar 20, 2018 at 11:58:14AM -0400, Jeff King wrote: > The issue bisects to 7e4ffb4c17 (diff-highlight: add support for --graph > output, 2016-08-29). I think the problem is the "\s+" at the end of the > $GRAPH regex, which soaks up the space for the context, and accidentally > treats the

Re: .gitattributes override behavior (possible bug, or documentation bug)

Thinking about this a little more, I'm now attracted to the idea that its .gitignore that's weird. As I understand it, .gitignore stops recursion when there's a directory match (`somedir/`) but also explicitly allows nested .gitnore file _as well as_ exclusion (`!*.txt`). So, in the following

Re: .gitattributes override behavior (possible bug, or documentation bug)

On Tue, Mar 20, 2018 at 5:40 AM, Jeff King wrote: > On Tue, Mar 20, 2018 at 12:25:27AM -0400, Dakota Hawkins wrote: > >> > Right. The technical reason is mostly "that is not how it was designed, >> > and it would possibly break some corner cases if we switched it now". >> >> I'm

Re: [BUG] log --graph corrupts patch

On Tue, Mar 20, 2018 at 09:58:14AM +, Phillip Wood wrote: > > Are you using any exotic filters for your pager? If you use "git > > --no-pager" does the problem persist? > > Hi Peff, thanks for taking the time to check this, I had forgotten about > the pager. I'm using diff-highlight and it

RE: Bug With git rebase -p

Perfect. Thank you. -Original Message- From: Johannes Schindelin [mailto:johannes.schinde...@gmx.de] Sent: Tuesday, March 20, 2018 10:53 AM To: Junio C Hamano <gits...@pobox.com> Cc: Joseph Strauss <josep...@bhphoto.com>; git@vger.kernel.org Subject: Re: Bug With git r

Re: Bug With git rebase -p

example at GitHub, https://github.com/jkstrauss/git-bug/ > > > > There seem to be two problems when rebasing merge commits with git rebase > > -p : > > 1. All lines of merge commits' messages get collapse into a single line. > > 2. When an asterisk is present

Re: [BUG] log --graph corrupts patch

On 20/03/18 06:09, Jeff King wrote: > On Mon, Mar 19, 2018 at 10:21:56AM +, Phillip Wood wrote: > >> I've just been reviewing some patches with 'git log --graph --patch' and >> came across what looked like a bug: >> >> | @@ -272,6 +272,9

Re: [BUG] log --graph corrupts patch

On Mon, Mar 19, 2018 at 10:21:56AM +, Phillip Wood wrote: > I've just been reviewing some patches with 'git log --graph --patch' and > came across what looked like a bug: > > | @@ -272,6 +272,9 @@ do > | --keep-empty) > |

Re: .gitattributes override behavior (possible bug, or documentation bug)

> So I think the "recommended subset" is basically "everything but these > few constructs". We just need to document them. ;) Mentioned so-far/running list? - Matching directories recursively, or at all I guess (e.g. "/") - (???) Instead: "/*" - Negative matches - (???) Instead: Is there any

Re: .gitattributes override behavior (possible bug, or documentation bug)

On Tue, Mar 20, 2018 at 12:25:27AM -0400, Dakota Hawkins wrote: > > Right. The technical reason is mostly "that is not how it was designed, > > and it would possibly break some corner cases if we switched it now". > > I'm just spitballing here, but do you guys think there's any subset of > the

Re: .gitattributes override behavior (possible bug, or documentation bug)

> Right. The technical reason is mostly "that is not how it was designed, > and it would possibly break some corner cases if we switched it now". I'm just spitballing here, but do you guys think there's any subset of the combined .gitignore and .gitattributes matching functionality that could at

Re: .gitattributes override behavior (possible bug, or documentation bug)

On Mon, Mar 19, 2018 at 11:17:04PM -0400, Dakota Hawkins wrote: > Sorry to tack on to my previous email, but I just thought of this: > > If something like "-diff=lfs" won't do what I (and git-lfs) thought it > would, do you think it would be prudent/reasonable to suggest git-lfs > add a "no-lfs"

Re: .gitattributes override behavior (possible bug, or documentation bug)

On Mon, Mar 19, 2018 at 11:10:26PM -0400, Dakota Hawkins wrote: > > As you noted below, that second line does not match your path, because > > attributes on a directory aren't applied recursively. And it has nothing > > to do with overriding. If you remove the png line entirely, you can see > >

Re: .gitattributes override behavior (possible bug, or documentation bug)

On Mon, Mar 19, 2018 at 08:33:15PM -0700, Junio C Hamano wrote: > Jeff King writes: > > > The best you can probably do is: > > > > /.readme-docs/* diff=foo > > > > Since you have no diff.foo.* config, that will behave in the default way > > (including respecting the usual "is

Re: .gitattributes override behavior (possible bug, or documentation bug)

On Mon, Mar 19, 2018 at 11:33 PM, Junio C Hamano wrote: > Jeff King writes: > >> The best you can probably do is: >> >> /.readme-docs/* diff=foo >> >> Since you have no diff.foo.* config, that will behave in the default way >> (including respecting the usual

Re: .gitattributes override behavior (possible bug, or documentation bug)

Jeff King writes: > The best you can probably do is: > > /.readme-docs/* diff=foo > > Since you have no diff.foo.* config, that will behave in the default way > (including respecting the usual "is it binary" checks). So a bit hacky, > but I think it would work as "ignore prior

Re: .gitattributes override behavior (possible bug, or documentation bug)

Sorry to tack on to my previous email, but I just thought of this: If something like "-diff=lfs" won't do what I (and git-lfs) thought it would, do you think it would be prudent/reasonable to suggest git-lfs add a "no-lfs" filter for exactly this case? That way I could have explicit exclusions

Re: .gitattributes override behavior (possible bug, or documentation bug)

Thanks for the quick reply! On Mon, Mar 19, 2018 at 10:34 PM, Jeff King wrote: > On Mon, Mar 19, 2018 at 09:49:28PM -0400, Dakota Hawkins wrote: > >> Summary: Trying to apply attributes to file extensions everywhere >> except in one directory. >> >> .gitattributes: >> >>

Re: .gitattributes override behavior (possible bug, or documentation bug)

On Mon, Mar 19, 2018 at 09:49:28PM -0400, Dakota Hawkins wrote: > Summary: Trying to apply attributes to file extensions everywhere > except in one directory. > > .gitattributes: > > *.[Pp][Nn][Gg] filter=lfs diff=lfs merge=lfs -text > /.readme-docs/ -filter=lfs -diff=lfs -merge=lfs >

.gitattributes override behavior (possible bug, or documentation bug)

According to the gitattributes docs: "When more than one pattern matches the path, a later line overrides an earlier line. This overriding is done per attribute." I had a need to do this recently, and while the attributes are git-lfs specific, I think the issue may be generic. Summary: Trying

Re: Bug With git rebase -p

Joseph Strauss <josep...@bhphoto.com> writes: > I found the following erroneous behavior with "git rebase -p". > > My current version is git version 2.16.2.windows.1 > > I made an example at GitHub, https://github.com/jkstrauss/git-bug/ > > There seem t

Bug With git rebase -p

I found the following erroneous behavior with "git rebase -p". My current version is git version 2.16.2.windows.1 I made an example at GitHub, https://github.com/jkstrauss/git-bug/ There seem to be two problems when rebasing merge commits with git rebase -p : 1. All lines of mer

Re: Potential git bug

On Mon, Mar 19, 2018 at 04:14:31PM -0400, Nick Hunt wrote: > oh, wait, switching branches didn't vaporize my changes, it auto-committed > them. > which is still weird and possibly a bug? Are you sure that the changes were not already present on the switched-to branch? -Peff

Re: Potential git bug

oh, wait, switching branches didn't vaporize my changes, it auto-committed them. which is still weird and possibly a bug? Nick Hunt nhun...@gmail.com 404-988-1845 On Mon, Mar 19, 2018 at 3:13 PM, Nick Hunt <nhun...@gmail.com> wrote: > i committed my changes, then ran > git reset

Potential git bug

i committed my changes, then ran git reset --soft HEAD^ at this point everything is fine then i switched branches, and all of my changes vaporized into thin air. uhhh, is this supposed to happen? anyway, thank god intellij saves my work for me as i go, so i didn't have to re-write all my code.

[BUG] log --graph corrupts patch

I've just been reviewing some patches with 'git log --graph --patch' and came across what looked like a bug: | @@ -272,6 +272,9 @@ do | --keep-empty) | keep_empty=yes | ;; | --allow-empty-message) | + --no-keep-empty) | + keep_empty

Re: [bug] git stash push {dir-pathspec} wipes untracked files

On 15/03/2018 17:52, Junio C Hamano wrote: > > > Hi, I ran into what I believe is a bug today. I’m using primarily Git > > for Windows 2.16.2 and also reproduced the behavior on Git for Windows > > 2.15.1 and Git 2.14.1 on Ubuntu: > > > > Given any reposito

RE: [bug] git stash push {dir-pathspec} wipes untracked files

> -Original Message- > From: git-ow...@vger.kernel.org <git-ow...@vger.kernel.org> On Behalf > Of Junio C Hamano > Sent: March 15, 2018 12:52 PM > To: Jake Stine <jake.st...@gmail.com> > Cc: git@vger.kernel.org > Subject: Re: [bug] git stash push {di

Re: [bug] git stash push {dir-pathspec} wipes untracked files

Jake Stine <jake.st...@gmail.com> writes: > Hi, I ran into what I believe is a bug today. I’m using primarily Git > for Windows 2.16.2 and also reproduced the behavior on Git for Windows > 2.15.1 and Git 2.14.1 on Ubuntu: > > Given any repository with at least on

[bug] git stash push {dir-pathspec} wipes untracked files

Hi, I ran into what I believe is a bug today. I’m using primarily Git for Windows 2.16.2 and also reproduced the behavior on Git for Windows 2.15.1 and Git 2.14.1 on Ubuntu: Given any repository with at least one subdirectory: 1. Create some untracked files in the subdir 2. Modify

Re: git-log bug: --grep and -number args are at odds

On Tue, Mar 13 2018, Alexander Mills jotted: > $ git log -50 ### I get 50 results > > $ git log -50 --grep="*" ### I get a lot more than 50... > > shouldn't `-50` minimize the results length to 50 or fewer? On what git version? On my 2.16.2.804.g6dcf76e118 on git.git this works as

git-log bug: --grep and -number args are at odds

$ git log -50 ### I get 50 results $ git log -50 --grep="*" ### I get a lot more than 50... shouldn't `-50` minimize the results length to 50 or fewer? -alex -- Alexander D. Mills ! New cell phone number: (415)766-8243 alexander.d.mi...@gmail.com

Re: Bug in "revision.c: --all adds HEAD from all worktrees" ?

On Tue, Mar 13 2018, Stan Hu jotted: > To be clear, this is how I think we got into this state: > > We have worktrees that are created to squash and rebase a branch. They were > left around inadvertently for one reason or another. > > Since we were using git v2.14.3, a git gc would prune

Re: Bug, git rebase -i does not abort correctly

On Friday 26 January 2018 02:54 PM, Duy Nguyen wrote: > > Sort of. It smells bad design to me when a mistake can easily become a > feature. But with your help, I think I should be able to disable this > feature on my local build. Thanks. > In case you're still facing this issue, it just struck

Re: Bug in "revision.c: --all adds HEAD from all worktrees" ?

To be clear, this is how I think we got into this state: We have worktrees that are created to squash and rebase a branch. They were left around inadvertently for one reason or another. Since we were using git v2.14.3, a git gc would prune dangling objects because it never saw that a worktree

Re: Bug in "revision.c: --all adds HEAD from all worktrees" ?

On Mon, Mar 12, 2018 at 10:39 PM, Ævar Arnfjörð Bjarmason <ava...@gmail.com> wrote: > Now, obviously the root cause is that the repo is corrupt through some > other bug (since fixed?), but the error message here is really bad, and > should at least say "fatal: bad object H

Re: Bug in "revision.c: --all adds HEAD from all worktrees" ?

would unblock you? > > It doesn't seem to help. > > $ git worktree prune -n > > $ git worktree prune > $ git fetch > remote: Counting objects: 35, done. > remote: Compressing objects: 100% (20/20), done. > remote: Total 21 (delta 17), reused 5 (delta 1) > U

RE: Bug report: git-stash doesn't return correct status code

] On Behalf Of Junio C Hamano Sent: Wednesday, March 07, 2018 23:03 To: Vromen, Tomer <tomer.vro...@intel.com> Cc: git@vger.kernel.org Subject: Re: Bug report: git-stash doesn't return correct status code Junio C Hamano <gits...@pobox.com> writes: > "Vromen, Tomer" <tom

Re: Bug report: git-stash doesn't return correct status code

Junio C Hamano writes: > "Vromen, Tomer" writes: > >>> git stash && git checkout -b new-feature-branch && git stash pop >> >> This is useful when I realize that I want to open a new branch for my >> changes (that I haven't committed yet). >> However,

Re: Bug report: git-stash doesn't return correct status code

"Vromen, Tomer" writes: >> git stash && git checkout -b new-feature-branch && git stash pop > > This is useful when I realize that I want to open a new branch for my changes > (that I haven't committed yet). > However, I might have forgotten to save my changes in the

Bug report: git-stash doesn't return correct status code

Hi all, I often use this one-liner: > git stash && git checkout -b new-feature-branch && git stash pop This is useful when I realize that I want to open a new branch for my changes (that I haven't committed yet). However, I might have forgotten to save my changes in the editor, so git-stash

Bug: moving submodules that have submodules inside them causes a fatal error in git status

if this is an invalid bug report. I'm running Git version: 2.16.2 (Debian Unstable) -- Sean Behan signature.asc Description: PGP signature

Re: [Bug] git log --show-signature print extra carriage return ^M

the github documentation: https://help.github.com/articles/generating-a-new-gpg-key/ that saves my keys in ~/AppData/Roaming/GnuPG. 2018-03-05 15:29 GMT+01:00 Johannes Schindelin <johannes.schinde...@gmx.de>: > Hi Larry, > > On Sun, 4 Mar 2018, Larry Hunter wrote: > >>

Re: Bug report: "Use of uninitialized value $_ in print"

Jeff King wrote: > On Fri, Mar 02, 2018 at 09:15:44AM -0800, Junio C Hamano wrote: >> Jeff King writes: >>> That's probably a reasonable sanity check, but I think we need to abort >>> and not just have a too-small DISPLAY array. Because later code like the >>> hunk-splitting is

Re: [BUG] [git 2.16.1] yeeek ... my files are gone .. by git pull

On Mon, Mar 05, 2018 at 03:49:13PM +0100, Johannes Schindelin wrote: > > I think that is doing the right thing for half of the problem. But > > there's something else funny where we do not include the "upstream" > > commits from the split history (i.e., we rebase onto nothing, > > whereas a

Re: [BUG] [git 2.16.1] yeeek ... my files are gone .. by git pull

Hi Peff, On Wed, 28 Feb 2018, Jeff King wrote: > On Tue, Feb 27, 2018 at 12:33:56AM +0100, Johannes Schindelin wrote: > > > > So something like this helps: > > > > > > diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh > > > index 81c5b42875..71e6cbb388 100644 > > > ---

Re: [Bug] git log --show-signature print extra carriage return ^M

Hi Larry, On Sun, 4 Mar 2018, Larry Hunter wrote: > There is bug using "git log --show-signature" in my installation > > git 2.16.2.windows.1 > gpg (GnuPG) 2.2.4 > libgcrypt 1.8.2 The gpg.exe shipped in Git for Windows should say something like this:

[Bug] git log --show-signature print extra carriage return ^M

There is bug using "git log --show-signature" in my installation git 2.16.2.windows.1 gpg (GnuPG) 2.2.4 libgcrypt 1.8.2 that prints (with colors) an extra ^M (carriage return?) at the end of the gpg lines. As an example, the output of "git log --show-signature H

Re: Bug report: "Use of uninitialized value $_ in print"

On Fri, Mar 02, 2018 at 01:53:32PM -0800, Junio C Hamano wrote: > Sam Kuper writes: > > > 1. It would yield, IIUC, less flexibility to create new kinds of view > > based on a consistent, standardised underlying model. > > > > 2. It is harder to read, for some types of

Re: Bug report: "Use of uninitialized value $_ in print"

On Fri, Mar 02, 2018 at 05:30:28PM +, Sam Kuper wrote: > On 02/03/2018, Jeff King wrote: > > Unfortunately, I don't think there's an easy way to do what you want > > (show word-diffs but apply the full diff). > > Oh :( > > That would be a *very* useful feature to have,

Re: Bug report: "Use of uninitialized value $_ in print"

On Fri, Mar 02, 2018 at 09:15:44AM -0800, Junio C Hamano wrote: > Jeff King writes: > > > That's probably a reasonable sanity check, but I think we need to abort > > and not just have a too-small DISPLAY array. Because later code like the > > hunk-splitting is going to assume

Re: Bug report: "Use of uninitialized value $_ in print"

Sam Kuper writes: > 1. It would yield, IIUC, less flexibility to create new kinds of view > based on a consistent, standardised underlying model. > > 2. It is harder to read, for some types of input (e.g. prose) than the > view generated by the existing word-diff

Re: Bug report: "Use of uninitialized value $_ in print"

On 02/03/2018, Junio C Hamano wrote: > Jeff King writes: >> Unfortunately, I don't think there's an easy way to do what you want >> (show word-diffs but apply the full diff). > > The current "word-diff" discards the information on where the lines > end, and it

Re: Bug report: "Use of uninitialized value $_ in print"

Jeff King writes: > Unfortunately, I don't think there's an easy way to do what you want > (show word-diffs but apply the full diff). The current "word-diff" discards the information on where the lines end, and it is pretty much hopeless/useless in the context of "add -p". It

Re: Bug report: "Use of uninitialized value $_ in print"

On 02/03/2018, Jeff King wrote: > Unfortunately, I don't think there's an easy way to do what you want > (show word-diffs but apply the full diff). Oh :( That would be a *very* useful feature to have, especially where multiple small (e.g. single character or single word) changes

Re: Bug report: "Use of uninitialized value $_ in print"

On 02/03/2018, Jonathan Nieder wrote: > Is this reproducible for you? Yes. It seems to occur consistently, given the same input. > Do you have more details about how I can reproduce it? Unfortunately, the particular git repo I encountered it on is private, otherwise I would

Re: Bug report: "Use of uninitialized value $_ in print"

Jeff King writes: > That's probably a reasonable sanity check, but I think we need to abort > and not just have a too-small DISPLAY array. Because later code like the > hunk-splitting is going to assume that there's a 1:1 line > correspondence. We definitely don't want to end up

Re: Bug report: "Use of uninitialized value $_ in print"

On Fri, Mar 02, 2018 at 08:53:34AM -0800, Junio C Hamano wrote: > Jeff King writes: > > > Because the array is full of "undef". See parse_diff(), which does this: > > > > my @diff = run_cmd_pipe("git", @diff_cmd, "--", $path); > > ... > > @colored =

Re: Bug report: "Use of uninitialized value $_ in print"

Jeff King writes: > Because the array is full of "undef". See parse_diff(), which does this: > > my @diff = run_cmd_pipe("git", @diff_cmd, "--", $path); > ... > @colored = run_cmd_pipe(@display_cmd); > ... > for (my $i = 0; $i < @diff; $i++) { > ... >

Re: Bug report: "Use of uninitialized value $_ in print"

On Thu, Mar 01, 2018 at 11:04:34PM -0800, Jonathan Nieder wrote: > > Use of uninitialized value $_ in print at > > /usr/lib/git-core/git-add--interactive line 1371, line 75. > [...] > > Strange. The relevant line, for reference: > > $ dpkg-deb --fsys-tarfile git_2.11.0-3+deb9u2_amd64.deb | >

Re: Bug report: "Use of uninitialized value $_ in print"

On Fri, Mar 02, 2018 at 01:19:35AM +, Sam Kuper wrote: > The bug is that in the midst of running > > git -c interactive.diffFilter="git diff --word-diff --color" add --patch That's not how interactive.diffFilter is supposed to work. It's meant to have the output of an

Re: Bug report: "Use of uninitialized value $_ in print"

Hi, Sam Kuper wrote: > First, background. I encountered a bug on Debian Stretch, using this > git version: > > $ git --version > git version 2.11.0 > > The bug is that in the midst of running > > git -c interactive.diffFilter="git diff --word-diff --color&q

Bug report: "Use of uninitialized value $_ in print"

First, background. I encountered a bug on Debian Stretch, using this git version: $ git --version git version 2.11.0 The bug is that in the midst of running git -c interactive.diffFilter="git diff --word-diff --color" add --patch and after having answered "y" to some patch

Re: Bug: git log: boundary commits do not respect order (e.g. date-order, topo-order) 2

see the commit message for >> 86ab4906a7c "revision walker: Fix --boundary when limited". Here is an >> excerpt: >> >> - After get_revision() finishes giving out all the positive >>commits, if we are doing the boundary processing, we look at >>the pa

Re: [BUG] [git 2.16.1] yeeek ... my files are gone .. by git pull

On Tue, Feb 27, 2018 at 12:33:56AM +0100, Johannes Schindelin wrote: > > So something like this helps: > > > > diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh > > index 81c5b42875..71e6cbb388 100644 > > --- a/git-rebase--interactive.sh > > +++ b/git-rebase--interactive.sh >

Re: [BUG] [git 2.16.1] yeeek ... my files are gone .. by git pull

, really, is this > > intended? > > Yeah, the bug seems to be in --preserve-merges. Here's an easier > reproduction: > > git init > >one && git add one && git commit -m one > git checkout --orphan other > git mv one two && git co

Re: Bug Report: git status triggers a file change event

Hi all, On Thu, 22 Feb 2018, Stefan Beller wrote: > On Wed, Feb 21, 2018 at 9:22 PM, Jonathan Nieder wrote: > > +git-for-windows First of all, this is clearly not a Windows-specific problem, as the index file *is* updated, and that is simply the same behavior as on

Re: [BUG] [git 2.16.1] yeeek ... my files are gone .. by git pull

On Fri, Feb 23, 2018 at 06:29:55AM +0100, "Marcel 'childNo͡.de' Trautwein" wrote: > shows me a quite different behavior, so solely rebase not seems the full > problem > BUT > `--rebase=preserve` will .. o’man , really, is this intended? Yeah, the bug seems to be in --p

Re: [BUG] [git 2.16.1] yeeek ... my files are gone .. by git pull

> Am 23.02.2018 um 00:20 schrieb Jonathan Nieder : > > Hi Marcel, > > … > Sorry, this is not the most helpful reply but: > > Can you describe a reproduction recipe so that I can experience the > same thing? > > That is: > > 1. steps to reproduce > 2. expected result > 3.

Re: [BUG] [git 2.16.1] yeeek ... my files are gone .. by git pull

Hi Marcel, Marcel 'childNo͡.de' Trautwein" wrote: > I think we have a problem … or at least I had > and I’m not quite sure if this is „working as designed“ > but I’m sure it „should not work as it did“. [...] > I wanted to clone another repository … but yeah … it’s late for me today and > I put

[BUG] [git 2.16.1] yeeek ... my files are gone .. by git pull

Hi, I think we have a problem … or at least I had and I’m not quite sure if this is „working as designed“ but I’m sure it „should not work as it did“. Because? It pruned a lot of files and even the local repository. by pull by giving another repository URL instead of a known remote While

Re: bug in HTTP protocol spec

> On Feb 22, 2018, at 12:02 PM, Junio C Hamano wrote: > > I saw somewhere "Apple-Mail" and a phrase "repaste". So perhaps > copy on the client is involved in the whitespace damage (of > course the original could be broken, but I somehow doubt it).

Re: bug in HTTP protocol spec

Jeff King writes: > This indentation is funny. But I suspect it is because your whole patch > seems to have been whitespace-damaged (see the section on gmail in > "git help git-format-patch"). I saw somewhere "Apple-Mail" and a phrase "repaste". So perhaps copy on the client is

Re: Bug: git log: boundary commits do not respect order (e.g. date-order, topo-order) 2

nd give them out. The boundary commits are correctly sorted by topo-order among themselves as of commit 4603ec0f960 "get_revision(): honor the topo_order flag for boundary commits". So, I'm not sure that this is a bug (it is working "as designed") but it certainly is non-obvious

Re: Bug Report: git status triggers a file change event

On Wed, Feb 21, 2018 at 9:22 PM, Jonathan Nieder wrote: > +git-for-windows > Hi, > > Raining Chain wrote: > >> On Windows 10, git version 2.16.2.windows.1, running the command >> >> git status >> >> will trigger a file change event to file C:\myPath\.git "Attributes >>

Re: bug in HTTP protocol spec

On 02/21, Dorian Taylor wrote: > > > On Feb 21, 2018, at 9:37 PM, Jonathan Nieder wrote: > > > > Thanks for writing it. > > > > Do you mind if we forge your sign-off? (See Documentation/SubmittingPatches > > item '(5) Certify your work' for details about what this means.)

Re: bug in HTTP protocol spec

> On Feb 22, 2018, at 2:08 AM, Jeff King wrote: > > > This indentation is funny. But I suspect it is because your whole patch > seems to have been whitespace-damaged (see the section on gmail in > "git help git-format-patch"). That is, bit-for-bit, what came out of that

Re: bug in HTTP protocol spec

On Wed, Feb 21, 2018 at 11:23:52PM -0800, Dorian Taylor wrote: > diff --git a/Documentation/technical/http-protocol.txt > b/Documentation/technical/http-protocol.txt > index a0e45f2889e6e..19d73f7efb338 100644 > --- a/Documentation/technical/http-protocol.txt > +++

Re: bug in HTTP protocol spec

> On Feb 21, 2018, at 9:37 PM, Jonathan Nieder wrote: > > Thanks for writing it. > > Do you mind if we forge your sign-off? (See Documentation/SubmittingPatches > item '(5) Certify your work' for details about what this means.) Sure, or I can just re-paste:

<    1   2   3   4   5   6   7   8   9   10   >