Re: Q: rational for $XDG_CONFIG_HOME/git/config to be "non global" or just a bug?

Jacob Keller writes: >> I actually thought that the plan was "you either have this, or the >> other one, never both at the same time" (and I think those who >> pushed the XDG thing in to the system made us favor it over the >> traditional one). So as long as --global

Re: Re: Re: bug deleting "unmerged" branch (2.12.3)

From: "Ulrich Windl" Hi! Sorry for the late response: On a somewhat not-up-to date manual: -d, --delete Delete a branch. The branch must be fully merged in its upstream branch, or in HEAD if no upstream was set with --track or

Re: Q: rational for $XDG_CONFIG_HOME/git/config to be "non global" or just a bug?

On Mon, 11 Dec 2017, Junio C Hamano wrote: > Jonathan Nieder writes: > > I think the documentation > > ~/.gitconfig > > User-specific configuration file. Also called "global" > > configuration file. > > should be clarified --- e.g. it could say

Re: Q: rational for $XDG_CONFIG_HOME/git/config to be "non global" or just a bug?

On Mon, Dec 11, 2017 at 5:05 PM, Junio C Hamano wrote: > Jonathan Nieder writes: > >> I think the documentation >> >> ~/.gitconfig >> User-specific configuration file. Also called "global" >> configuration file. >> >>

Re: Q: rational for $XDG_CONFIG_HOME/git/config to be "non global" or just a bug?

Jonathan Nieder writes: > I think the documentation > > ~/.gitconfig > User-specific configuration file. Also called "global" > configuration file. > > should be clarified --- e.g. it could say > > $XDG_CONFIG_HOME/git/config >

Re: Q: rational for $XDG_CONFIG_HOME/git/config to be "non global" or just a bug?

On Mon, 11 Dec 2017, Jonathan Nieder wrote: > > Example to show that TFM outlines precedence and --global correctly: > > $> grep xdg .gitconfig .config/git/config > > .gitconfig:xdg-and-user = user > > .config/git/config: xdg = xdg > > .config/git/config: xdg-and-user = xdg > > $> git config

Re: Q: rational for $XDG_CONFIG_HOME/git/config to be "non global" or just a bug?

Hi, Yaroslav Halchenko wrote: > Example to show that TFM outlines precedence and --global correctly: > > $> grep xdg .gitconfig .config/git/config > .gitconfig:xdg-and-user = user > .config/git/config: xdg = xdg > .config/git/config: xdg-and-user = xdg > $> git config user.xdg ; git config

Q: rational for $XDG_CONFIG_HOME/git/config to be "non global" or just a bug?

r.xdg# so outputs nothing $> git config --global user.xdg-and-user user $> mv .gitconfig{,.aside} $> git config --global --add user.new value $> cat .config/git/config [user] xdg = xdg xdg-and-user = xdg new = value So, is that simply a bug and $XDG_CONFIG_HOME/git/co

Antw: Re: Re: bug deleting "unmerged" branch (2.12.3)

Hi! Sorry for the late response: On a somewhat not-up-to date manual: -d, --delete Delete a branch. The branch must be fully merged in its upstream branch, or in HEAD if no upstream was set with --track or --set-upstream. Maybe the topic of multiple

Bug: "git status --porcelain --show-stash" does not show stash count

Using: $ git version git version 2.15.1 Running without --porcelain shows the correct stash count: $ git status --show-stash On branch feature-Enable-Unmarshaling-Support Untracked files: (use "git add ..." to include in what will be committed) testdata/

Re: Re: bug deleting "unmerged" branch (2.12.3)

From: "Ulrich Windl" Hi Philip! I'm unsure what you are asking for... Ulrich Hi Ulrich, I was doing a retrospective follow up (of the second kind [1]). In your initial email https://public-inbox.org/git/5a1d70fd02a100029...@gwsmtp1.uni-regensburg.de/

Antw: Re: bug deleting "unmerged" branch (2.12.3)

Hi Philip! I'm unsure what you are asking for... Ulrich >>> "Philip Oakley" 04.12.17 0.30 Uhr >>> From: "Junio C Hamano" > "Philip Oakley" writes: > >> I think it was that currently you are on M, and neither A nor B are >>

Re: Bug in git-completion.bash in __git_heads() function

Hi, >This is the first time I am sending a bug report here, so if I have > not met the criteria please let me know. >I found that at: > https://github.com/git/git/blob/master/contrib/completion/git-completion.bash#L371, > the usage of refname:strip=2 generates error: >

Bug in git-completion.bash in __git_heads() function

Hello, This is the first time I am sending a bug report here, so if I have not met the criteria please let me know. I found that at: https://github.com/git/git/blob/master/contrib/completion/git-completion.bash#L371, the usage of refname:strip=2 generates error: fatal: unknown refname

Re: bug deleting "unmerged" branch (2.12.3)

From: "Junio C Hamano" "Philip Oakley" writes: I think it was that currently you are on M, and neither A nor B are ancestors (i.e. merged) of M. As Junio said:- "branch -d" protects branches that are yet to be merged to the **current branch**.

Re: [PATCH] git-gui: allow Ctrl+T to toggle multiple paths (Re: [BUG] git gui can't commit multiple files)

On 12/2/17, Jonathan Nieder wrote: > Jonathan Nieder wrote: > >> From: Johannes Schindelin >> Subject: git-gui: allow Ctrl+T to toggle multiple paths >> >> In the Unstaged Changes panel, selecting multiple lines (using >> shift+click) and pressing

Re: bug deleting "unmerged" branch (2.12.3)

"Philip Oakley" writes: > I think it was that currently you are on M, and neither A nor B are > ancestors (i.e. merged) of M. > > As Junio said:- "branch -d" protects branches that are yet to be > merged to the **current branch**. Actually, I think people loosened this

Re: Re: bug deleting "unmerged" branch (2.12.3)

From: "Ulrich Windl" <ulrich.wi...@rz.uni-regensburg.de> To: <gits...@pobox.com> Cc: <git@vger.kernel.org> Sent: Wednesday, November 29, 2017 8:32 AM Subject: Antw: Re: bug deleting "unmerged" branch (2.12.3) "Ulrich Windl" <ulrich.wi...@r

Re: Antw: Re: bug deleting "unmerged" branch (2.12.3)

Hi Ulrich From: "Johannes Schindelin" <johannes.schinde...@gmx.de> To: "Ulrich Windl" <ulrich.wi...@rz.uni-regensburg.de> Cc: <git@vger.kernel.org> Sent: Wednesday, November 29, 2017 12:27 PM Subject: Re: Antw: Re: bug deleting "unmerged" br

Re: [PATCH] git-gui: allow Ctrl+T to toggle multiple paths (Re: [BUG] git gui can't commit multiple files)

Jonathan Nieder wrote: > From: Johannes Schindelin > Subject: git-gui: allow Ctrl+T to toggle multiple paths > > In the Unstaged Changes panel, selecting multiple lines (using > shift+click) and pressing ctrl+t to stage them causes one file to be > staged instead of

[PATCH] git-gui: allow Ctrl+T to toggle multiple paths (Re: [BUG] git gui can't commit multiple files)

From: Johannes Schindelin Subject: git-gui: allow Ctrl+T to toggle multiple paths In the Unstaged Changes panel, selecting multiple lines (using shift+click) and pressing ctrl+t to stage them causes one file to be staged instead of all of the selected files. The same

Re: [BUG] git gui can't commit multiple files

Originally I had this problem in gentoo and assumed in the end it's likely due to my specific configuration. However recently I switched to nixos and am still experiencing it. I've search again if I can find anything and lo and behold, it's already fixed in the *windows* version of git-gui...

Re: Antw: Re: bug deleting "unmerged" branch (2.12.3)

a > > branch with `git branch -d` as long as it is contained in its upstream > > branch. > > I'm not talking about the intention of a branch, but of the state of a > branch: If multiple branches point (not "contain") the same commit, they > are equivalent (b

Antw: Re: bug deleting "unmerged" branch (2.12.3)

> "Ulrich Windl" writes: > >> I think if more than one branches are pointing to the same commit, >> one should be allowed to delete all but the last one without >> warning. Do you agree? > > That comes from a viewpoint that the only purpose "branch -d" exists

Antw: Re: bug deleting "unmerged" branch (2.12.3)

> Hi Ulrich, > > On Tue, 28 Nov 2017, Ulrich Windl wrote: > >> During a rebase that turned out to be heavier than expected 8-( I >> decided to keep the old branch by creating a temporary branch name to >> the commit of the branch to rebase (which was still the old commit ID at >> that time).

Re: bug deleting "unmerged" branch (2.12.3)

"Ulrich Windl" writes: > I think if more than one branches are pointing to the same commit, > one should be allowed to delete all but the last one without > warning. Do you agree? That comes from a viewpoint that the only purpose "branch -d" exists in addition

Re: Bug in pathspec handling (in conjunction with submodules)

On 11/26, Johannes Schindelin wrote: > Hi Duy & Brandon, > > in 74ed43711fd (grep: enable recurse-submodules to work on objects, > 2016-12-16), the do_match() function in tree-walk.c was changed so that it > can recurse across submodule boundaries. > > However, the

Re: bug deleting "unmerged" branch (2.12.3)

Hi Ulrich, On Tue, 28 Nov 2017, Ulrich Windl wrote: > During a rebase that turned out to be heavier than expected 8-( I > decided to keep the old branch by creating a temporary branch name to > the commit of the branch to rebase (which was still the old commit ID at > that time). > > When done

bug deleting "unmerged" branch (2.12.3)

Hi! During a rebase that turned out to be heavier than expected 8-( I decided to keep the old branch by creating a temporary branch name to the commit of the branch to rebase (which was still the old commit ID at that time). When done rebasing, I attached a new name to the new (rebased) branch,

Bug in pathspec handling (in conjunction with submodules)

Hi Duy & Brandon, in 74ed43711fd (grep: enable recurse-submodules to work on objects, 2016-12-16), the do_match() function in tree-walk.c was changed so that it can recurse across submodule boundaries. However, there is a bug, and I *think* there may be two bugs actually. Or even three. F

[ANNOUNCE] Bug tracker for Git

there. I'll be happy to triage them to keep the list of bugs meaningful. Anyone else wanting to help with bug management can feel free to contact me and I'll grant you permissions to edit issues. This particular implementation of an issue tracker is Monorail <https://chromium.googlesource.com/in

Re: Bug/Wish: bash completion for git pull --rebase doesn't include --autostash

Patch sent, please still CC me as i'm not on the list. Cheers, Albert El dimarts, 31 d’octubre de 2017, a les 18:56:22 CET, Stefan Beller va escriure: > On Tue, Oct 31, 2017 at 8:21 AM, Albert Astals Cid > > wrote: > > git pull --rebase --autostash > > > > is a

Re: Is it not bug git stash -- does not work at non-root directory?

小川恭史 <aiueogawa...@gmail.com> writes: > I upgraded the version of git from 2.13.1 to 2.15.0 on Mac and fixed my issue. > Thanks. Ah, yes, that bug was fixed in the 2.14.0 timeframe but was backported to 2.13.2 and onwards (it was a bug in 2.13.0, I think).

Re: Is it not bug git stash -- does not work at non-root directory?

git/master: cd Documentation > $ Documentation/master: echo >>Makefile > $ Documentation/master: git stash -- Makefile > Saved working directory and index state WIP on master: 89ea799ffc Sync > with maint > $ Documentation/master: git stash show --stat > Doc

Re: Is it not bug git stash -- does not work at non-root directory?

$ Documentation/master: echo >>Makefile $ Documentation/master: git stash -- Makefile Saved working directory and index state WIP on master: 89ea799ffc Sync with maint $ Documentation/master: git stash show --stat Documentation/Makefile | 1 + 1 file changed, 1 in

Re: Is it not bug git stash -- does not work at non-root directory?

orget to 'git add'? . I don't know what I should write about 'the difference between X and Y is Z'. 2017-11-18 12:53 GMT+09:00 Junio C Hamano <gits...@pobox.com>: > 小川恭史 <aiueogawa...@gmail.com> writes: > >> Is it not bug git stash -- does not work at non-root dir

Re: Is it not bug git stash -- does not work at non-root directory?

小川恭史 <aiueogawa...@gmail.com> writes: > Is it not bug git stash -- does not work at non-root directory? Please make it a habit (not limited to when interacting with _this_ project) to state a bit more than "does not work"; instead, say "it is expected to do

Is it not bug git stash -- does not work at non-root directory?

Is it not bug git stash -- does not work at non-root directory?

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

c > >> bails out if there's an error, which I think is the problem. I wonder > >> if it should instead just report something and then keep going. > > > > Also see > > https://public-inbox.org/git/cagz79kyp0z1g_h3nwfmshrawhmbocik5lepuxkj0nveebri...@mail.gmail.com/ &

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

On 15 November 2017 at 22:08, Junio C Hamano wrote: > Luke Diamand writes: > >> Quite a few of the worktrees have expired - their head revision has >> been GC'd and no longer points to anything sensible >> (gc.worktreePruneExpire). The function

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

Luke Diamand writes: > Quite a few of the worktrees have expired - their head revision has > been GC'd and no longer points to anything sensible > (gc.worktreePruneExpire). The function other_head_refs() in worktree.c > bails out if there's an error, which I think is the

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

no longer points to anything sensible >> (gc.worktreePruneExpire). The function other_head_refs() in worktree.c >> bails out if there's an error, which I think is the problem. I wonder >> if it should instead just report something and then keep going. > > Also see > https://public-inbox.org/git/cagz79kyp0z1g_h3nwfmshrawhmbocik5lepuxkj0nveebri...@mail.gmail.com/ So is this a bug or user error on my part? Surely at the very least "git fetch" shouldn't give a cryptic error message just because one of my git worktrees has expired!

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

On Mon, Nov 13, 2017 at 2:03 PM, Luke Diamand wrote: > On 13 November 2017 at 19:51, Luke Diamand wrote: >> Hi! >> >> I think there may be a regression caused by this change which means >> that "git fetch origin" doesn't work: >> >> commit

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

On 13 November 2017 at 19:51, Luke Diamand wrote: > Hi! > > I think there may be a regression caused by this change which means > that "git fetch origin" doesn't work: > > commit d0c39a49ccb5dfe7feba4325c3374d99ab123c59 (refs/bisect/bad) > Author: Nguyễn Thái Ngọc Duy

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

Hi! I think there may be a regression caused by this change which means that "git fetch origin" doesn't work: commit d0c39a49ccb5dfe7feba4325c3374d99ab123c59 (refs/bisect/bad) Author: Nguyễn Thái Ngọc Duy Date: Wed Aug 23 19:36:59 2017 +0700 revision.c: --all adds HEAD

Re: Bug - Status - Space in Filename

Jeff King writes: > Are there callers who don't just print the result? If not, we could just > always emit. That's slightly more efficient since it drops the expensive > strbuf_insert (though there are already so many copies going on in > quote_path_relative that it hardly

Bug: cherry-pick & submodule

on commit B, I got a conflict with `a_submodule`. Changes of `a_file` are successfully cherry-picked. I expected, that there would be no conflicts. A bash script reproducing the bug is listed below. Vasily. rm -rf a_submodule a_repo mkdir a_submodule cd a_submodule git init touch

Bug: cherry-pick & submodule

on commit B, I got a conflict with `a_submodule`. Changes of `a_file` are successfully cherry-picked. I expected, that there would be no conflicts. A bash script reproducing the bug is attached. Vasily. bug.sh Description: application/shellscript

Re: Bug - Status - Space in Filename

On Fri, Nov 10, 2017 at 09:52:16AM +0900, Junio C Hamano wrote: > > That said, if this is the only place that has this funny quoting, it may > > not be worth polluting the rest of the code with the idea that quoting > > spaces is a good thing to do. > > Sounds sane. We can probably use a helper

Re: Bug - Status - Space in Filename

Jeff King writes: > Yeah, I think the original sin is using " -> " in the --porcelain output > (which just got it from --short). That should have been a HT all along > to match the rest of the diff code. The --porcelain=v2 format gets this > right. So we at lesat did something

Re: Bug - Status - Space in Filename

On Thu, Nov 09, 2017 at 12:26:20PM +0900, Junio C Hamano wrote: > The difference in d->head_path part is dealing about renames, which > is irrelevant for showing unmerged paths, but the key difference is > that the _unmerged() forgets to add the enclosing "" around the > result of quote_path(). >

Re: Bug - Status - Space in Filename

Joseph Strauss <josep...@bhphoto.com> writes: > I believe I have found a bug in the way git status -s lists filenames. > > According to the documentation: > The fields (including the ->) are separated from each other by a single > space. If a filename contains whitespa

RE: Bug - Status - Space in Filename

I believe I have found a bug in the way git status -s lists filenames. According to the documentation: The fields (including the ->) are separated from each other by a single space. If a filename contains whitespace or other nonprintable characters, that field will be quoted in the man

Re: Bug report: git reset --hard does not fix submodule worktree

On Fri, Nov 3, 2017 at 5:46 PM, Billy O'Neal (VC LIBS) wrote: > Hello, Git folks. I managed to accidentally break the our test lab by > attempting to git mv a directory with a submodule inside. It seems like if a > reset does an undo on a mv, the workfold entry should be

Bug report: git reset --hard does not fix submodule worktree

Hello, Git folks. I managed to accidentally break the our test lab by attempting to git mv a directory with a submodule inside. It seems like if a reset does an undo on a mv, the workfold entry should be fixed to put the submodule in its old location. Consider the following sequence of

Re: [BUG] Incosistent repository state when trying to rename HEAD in the middle of a rebase

On Thursday 02 November 2017 01:21 PM, Junio C Hamano wrote: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> writes: I was able to spare some time to dig into this and found a few things. First, it seems that the issue is more generic and the BUG kicks in whenever HEAD is not a symbol

Re: [BUG] git clean -d is too greedy

I was a bit trigger happy posting this, after digging a bit more this is a way more serious than I originally thought.   1) .gitignore exists in nested repo (either tracked or untracked)   2) .gitignore is excluded This can be any file, including those commonly excluded such as *~.

[BUG] git clean -d is too greedy

Hi all, Since commit 6b1db4310 it is possible to make git clean -d to remove nested git repositories if 1) .gitignore exists in nested repo (either tracked or untracked) 2) .gitignore is excluded Regarding to 2) it doesn't matter if .gitignore is excluded from (another) .gitignore or

Re: [BUG] Incosistent repository state when trying to rename HEAD in the middle of a rebase

Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> writes: > I was able to spare some time to dig into this and found a few things. > > First, it seems that the issue is more generic and the BUG kicks in > whenever HEAD is not a symbolic ref. Interesting. Shortly we'll be

Re: [BUG] Incosistent repository state when trying to rename HEAD in the middle of a rebase

I was able to spare some time to dig into this and found a few things. First, it seems that the issue is more generic and the BUG kicks in whenever HEAD is not a symbolic ref. I noticed that because when HEAD is a symbolic ref there was a change in the error message shown by git. In (2.11.0) I

Re: Bug/Wish: bash completion for git pull --rebase doesn't include --autostash

On Tue, Oct 31, 2017 at 8:21 AM, Albert Astals Cid wrote: > git pull --rebase --autostash > > is a valid command but the --autostash autocompletion is not suggested after > typing > > git pul --reb > Would be great if that could be added. > > Thanks :) > > Albert > >

Bug/Wish: bash completion for git pull --rebase doesn't include --autostash

git pull --rebase --autostash is a valid command but the --autostash autocompletion is not suggested after typing git pul --reb

[BUG] Incosistent repository state when trying to rename HEAD in the middle of a rebase

I just noticed this recently while trying to see if a recent change [1] that disallowed the possibility of creating HEAD also allowed renaming branches named "HEAD" that were created using previous versions that allowed it. Unfortunately (or fortunately (?)), I was in the middle of an interactive

Re: [Bug Report] [includeIf] does not parse case insensitive -> case sensitive symlink gitdir

On Fri, Oct 27, 2017 at 09:55:58AM -0400, Adrian Kappel wrote: > Hello all, not sure if the issue I've come across is a known bug or > addressable, but wanted to report it just in-case. Thanks for the detailed description - my question is inline > >

[Bug Report] [includeIf] does not parse case insensitive -> case sensitive symlink gitdir

Hello all, not sure if the issue I've come across is a known bug or addressable, but wanted to report it just in-case. ** Summary -- Using the [includeIf] configuration statement with a symlink'd gitdir will not work if the symlink

Re: v2.15.0-rc2 ref deletion bug

On Tue, Oct 24, 2017 at 01:05:00PM +0200, Michael Haggerty wrote: > > I'd expect one of: > > > > 1. We delete "foo" before updating "foo/bar", and we end up with a > > single ref. > > I don't think that this is possible in the general case in a single > transaction. The problem is that

Re: v2.15.0-rc2 ref deletion bug

On 10/24/2017 01:05 PM, Michael Haggerty wrote: > On 10/24/2017 10:24 AM, Jeff King wrote: >> I found a potentially serious bug in v2.15.0-rc2 (and earlier release >> candidates, too) that we may want to deal with before the release. >> >> If I do: >> [...] &

Re: v2.15.0-rc2 ref deletion bug

On 10/24/2017 10:24 AM, Jeff King wrote: > I found a potentially serious bug in v2.15.0-rc2 (and earlier release > candidates, too) that we may want to deal with before the release. > > If I do: > > git init -q repo > cd repo > obj=$(git hash-object -w /dev/null) > g

v2.15.0-rc2 ref deletion bug

I found a potentially serious bug in v2.15.0-rc2 (and earlier release candidates, too) that we may want to deal with before the release. If I do: git init -q repo cd repo obj=$(git hash-object -w /dev/null) git update-ref refs/tags/foo $obj git update-ref --stdin <<-EOF delete refs/ta

Re: Bug: git ls-remote -h / --head results differ in output

Am 15.10.2017 um 13:08 schrieb Martin Ågren: > On 15 October 2017 at 12:02, Thomas Rikl wrote: >> Example: >> >> tom1 ~/emacs/spacemacs/.emacs.d $ export LANG=en_US.utf8 >> >> tom1 ~/emacs/spacemacs/.emacs.d $ git ls-remote -h >> usage: git ls-remote [--heads] [--tags] [--refs]

Re: Bug: git ls-remote -h / --head results differ in output

On 15 October 2017 at 12:02, Thomas Rikl wrote: > Example: > > tom1 ~/emacs/spacemacs/.emacs.d $ export LANG=en_US.utf8 > > tom1 ~/emacs/spacemacs/.emacs.d $ git ls-remote -h > usage: git ls-remote [--heads] [--tags] [--refs] [--upload-pack=] > [-q | --quiet]

Bug: git ls-remote -h / --head results differ in output

Example: tom1 ~/emacs/spacemacs/.emacs.d $ export LANG=en_US.utf8 tom1 ~/emacs/spacemacs/.emacs.d $ git ls-remote -h usage: git ls-remote [--heads] [--tags] [--refs] [--upload-pack=] [-q | --quiet] [--exit-code] [--get-url] [--symref] [ [...]]     -q,

Re: Bug or feature: format-patch breaks long subject lines

writes: > Is this the expected behaviour? Yes, it is expected. Your are seeing the header folding in play. "mailinfo" (hence "am") will grok it just fine, I think.

Bug or feature: format-patch breaks long subject lines

Hello list, git format-patch breaks (or better: word-wraps) long subject lines. This is on Windows 7 with $ git --version git version 2.14.2.windows.2 Reproduce with (some output omitted): -- $ git init

Re: [bug] git add -p breaks, if color.ui is set to "always"

On Fri, Oct 06, 2017 at 02:47:30PM +0200, Alexander Gehrke wrote: > After an update to version 2.14.2 from 2.14.1 "git add --patch" stopped > working > for me, just producing the same output as "git diff", but not prompting to > stage > anything. > > I found that unsetting the config key

[bug] git add -p breaks, if color.ui is set to "always"

After an update to version 2.14.2 from 2.14.1 "git add --patch" stopped working for me, just producing the same output as "git diff", but not prompting to stage anything. I found that unsetting the config key color.ui, which was set to "always" fixed the problem. >From the manpage, color.ui

Weird behavior/bug for git clean in untracked directory

Hello I'm a little bit confused about the behavior of git clean when trying to clean multiple files/directories at once. For instance if I create two directories with an empty file in an new git repository as such: mkdir tmprepo cd tmprepo git init mkdir a b touch a/file b/file and

Re: [bug] git version 2.4.12 color.ui = always breaks git add -p

On Tue, Oct 03, 2017 at 02:47:48PM -0700, Jonathan Nieder wrote: > Hi Christian, > > Christian Rebischke wrote: > > > I played around with my gitconfig and I think I found a bug while doing > > so. I set the following lines in my gitconfig: > > > > [color] &g

Re: [bug] git version 2.4.12 color.ui = always breaks git add -p

Hi Christian, Christian Rebischke wrote: > I played around with my gitconfig and I think I found a bug while doing > so. I set the following lines in my gitconfig: > > [color] > ui = always > > When I try to use `git add -p ` I don't see the 'Stage > this hunk'

[bug] git version 2.4.12 color.ui = always breaks git add -p

Hello everybody, I played around with my gitconfig and I think I found a bug while doing so. I set the following lines in my gitconfig: [color] ui = always When I try to use `git add -p ` I don't see the 'Stage this hunk'-dialog anymore. First I thought it's some other configuration but now

Re: [Bug/Solution] Git hangs in compat/poll/poll.c on HPE NonStop

On 29/09/2017 00:47, Junio C Hamano wrote: > [jch: a patch that hopefully is applicable is attached at the end; > I'd appreciate input from Paolo, the contributor of the original > upstream] I wasn't involved in upstream commit d42461c3, but Linux is also always overwriting the revents output

Re: [Bug/Solution] Git hangs in compat/poll/poll.c on HPE NonStop

[jch: a patch that hopefully is applicable is attached at the end; I'd appreciate input from Paolo, the contributor of the original upstream] "Randall S. Becker" writes: > After a whole lot of investigating, we (it is a large "we") have discovered > the reason for the

[Bug/Solution] Git hangs in compat/poll/poll.c on HPE NonStop

Hi Team, After a whole lot of investigating, we (it is a large "we") have discovered the reason for the hang we occasionally get in git-upload-pack on HPE NonStop servers - reported here well over a year ago. This resulted from a subtle check that the operating system does on file descriptors.

Re: diffstat summary mode change bug

Linus Torvalds writes: > and the reason seems to be that the '\n' at the end got dropped as the > old code was very confusing (the old code had two different '\n' cases > for the "show filename or not"). > > I think the right fix is this whitespace-damaged trivial

Re: diffstat summary mode change bug

On Wed, Sep 27, 2017 at 2:02 PM, Linus Torvalds wrote: > On Wed, Sep 27, 2017 at 1:40 PM, Stefan Beller wrote: >> >> I disagree with this analysis, as the fix you propose adds the >> new line unconditionally, i.e. this code path would be broken

Wrong -dirty suffix set by setlocalversion (was: BUG in git diff-index)

+ linux-kbuild list which is not in the output of: ./scripts/get_maintainer.pl -f scripts/setlocalversion ... but seems relevant anyway. On 31/03/16 13:39, Junio C Hamano wrote: > Andy Lowry writes: > >> So I think now that the script should do "update-index --refresh"

Re: diffstat summary mode change bug

On Wed, Sep 27, 2017 at 1:40 PM, Stefan Beller wrote: > > I disagree with this analysis, as the fix you propose adds the > new line unconditionally, i.e. this code path would be broken > regardless of "show filename or not". Right. Because it is what we want. The old code

Re: diffstat summary mode change bug

On Wed, Sep 27, 2017 at 11:15 AM, Linus Torvalds <torva...@linux-foundation.org> wrote: > (ok, linewrapping in this email may make that look wrong - but the > "mode change" land the "create mode" are both on the same line. Thanks for the bug report. > and

Re: -s theirs use-case(s) Was: BUG: merge -s theirs is not in effect

On Wed, 27 Sep 2017, Yaroslav Halchenko wrote: > > And at that point, use of "-s ours" is no longer a workaround for > > lack of "-s theirs". It is a proper part of the desired semantics, > > i.e. from the point of view of the surviving canonical history line, > > you want to preserve what it

diffstat summary mode change bug

Current git shows file-mode changes incorrectly in the diffstat summary, as I just noted from a pull request I did on the kernel. The pull request *should* have resulted in a summary like this: ... 21 files changed, 247 insertions(+), 67 deletions(-) mode change 100644 => 100755

Re: -s theirs use-case(s) Was: BUG: merge -s theirs is not in effect

On Wed, 27 Sep 2017, Junio C Hamano wrote: > > and that is where the gotcha comes -- what if "my" changes were already > > published? then I would like to avoid the rebase, and would -s theirs > > to choose "their" solution in favor of mine and be able to push so > > others could still

Re: -s theirs use-case(s) Was: BUG: merge -s theirs is not in effect

Yaroslav Halchenko writes: > and that is where the gotcha comes -- what if "my" changes were already > published? then I would like to avoid the rebase, and would -s theirs > to choose "their" solution in favor of mine and be able to push so > others could still

Google indexing https://public-inbox.org/git (was: BUG in git diff-index)

[Reduced Cc: and change Subject:] On 26/09/17 13:11, Eric Wong wrote: > There's no blocks on public-inbox.org and I'm completely against > any sort of blocking/throttling. Maybe there's too many pages > to index? Or the Message-IDs in URLs are too ugly/scary? Not > sure what to do about

Re: BUG in git diff-index

gt; http://git.661346.n2.nabble.com/BUG-in-git-diff-index-tt7652105.html#none > Is there a robots.txt to block indexing on > https://public-inbox.org/git/1459432667.2124.2.ca...@dwim.me ? There's no blocks on public-inbox.org and I'm completely against any sort of blocking/throttling. M

Re: BUG in git diff-index

copy (as Mike learned the hard way) PS: I used NNTP and http://dir.gmane.org/gmane.comp.version-control.git to quickly find this old thread (what could we do without NNTP?). Then I googled for a web archive of this thread and Google could only find this one: http://git.661346.n2.nabble.com/BUG-in-git-dif

Re: -X theirs does not resolve symlink conflict Was: BUG: merge -s theirs is not in effect

On Tue, 26 Sep 2017, Junio C Hamano wrote: > >> I do not recall people talking about symbolic links but the case of > >> binary files has been on the wishlist for a long time, and I do not > >> know of anybody who is working on (or is planning to work on) it. > > Ah, I misremembered. > > We've

Re: -s theirs use-case(s) Was: BUG: merge -s theirs is not in effect

On Tue, 26 Sep 2017, Junio C Hamano wrote: > Yaroslav Halchenko writes: > > 1. As a workaround for absence of -m theirs I using mtheirs git alias: > > (I believe provided to me awhile back here on the list): > > mtheirs = !sh -c 'git merge -s ours --no-commit $1 &&

Re: -s theirs use-case(s) Was: BUG: merge -s theirs is not in effect

Yaroslav Halchenko writes: > 1. As a workaround for absence of -m theirs I using mtheirs git alias: > (I believe provided to me awhile back here on the list): > > mtheirs = !sh -c 'git merge -s ours --no-commit $1 && git read-tree -m -u > $1' - > > and it worked fine

Re: -X theirs does not resolve symlink conflict Was: BUG: merge -s theirs is not in effect

case MERGE_RECURSIVE_OURS: + oidcpy(>oid, >oid); + break; + case MERGE_RECURSIVE_THEIRS: + oidcpy(>oid, >oid); + break; + } } else die("BUG: unsupported object type in the tree"); }

Re: -X theirs does not resolve symlink conflict Was: BUG: merge -s theirs is not in effect

Junio C Hamano writes: > I do not recall people talking about symbolic links but the case of > binary files has been on the wishlist for a long time, and I do not > know of anybody who is working on (or is planning to work on) it. Ah, I misremembered. We've addressed the

<    4   5   6   7   8   9   10   11   12   13   >