Re: bug in HTTP protocol spec

(+cc: bmwill@, who is working on protocol v2) Hi, Dorian Taylor wrote: > On Feb 21, 2018, at 2:15 PM, Jeff King wrote: >> Thanks, I agree the document is buggy. Do you want to submit a patch? > > Will this do? Thanks for writing it. Do you mind if we forge your sign-off? (See

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

+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 changed." > > This causes problems when using scripts that detect file changes such > as tsc -w

Bug Report: git status triggers a file change event

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 changed." This causes problems when using scripts that detect file changes such as tsc -w (Typescript compiler) and using softwares that regularly

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

When using git log, boundary commits (ie, those commits added by specifying --boundary) do not respect the order (e.g., --date-order, --topo-order). Consider the following commit history, where number indicates the order of the commit timestamps: 0125 <--A \ \

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

TYPO IN EXPECTED OUTPUT. To avoid inevitable confusion, creating new thread "Bug: git log: boundary commits do not respect order (e.g. date-order, topo-order) 2". DON'T REPLY TO THIS MESSAGE. Instead reply to the new message On Wed, Feb 21, 2018 at 6:28 PM, Josh Tepper <j...

Re: bug in HTTP protocol spec

> On Feb 21, 2018, at 2:15 PM, Jeff King wrote: > > Thanks, I agree the document is buggy. Do you want to submit a patch? Will this do? Note I am not sure what the story is behind that `version 1` element, whether it's supposed to go before or after the null packet or if there

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

When using git log, boundary commits (ie, those commits added by specifying --boundary) do not respect the order (e.g., --date-order, --topo-order). Consider the following commit history, where number indicates the order of the commit timestamps: 0125 <--A \ \

Re: bug in HTTP protocol spec

On Wed, Feb 21, 2018 at 10:29:35AM -0800, Dorian Taylor wrote: > I didn’t get an insight until I ran with GIT_TRACE_PACKET=true on a > known-good remote (i.e. GitHub), that the null packet-line `` has to > follow the service line. This is not reflected in the example here: > >

bug in HTTP protocol spec

Hello list, I had been banging my head all morning trying to figure out why I couldn’t get a little HTTP implementation to clone/push via the smart protocol (just wrapping git-receive-pack/git-upload-pack). I kept getting the following (likely familiar to some) error: ``` fatal: Could not

RE: [BUG] Worktree prune complains about missing path

dn't help. Best would be to prepare a minimal example of shell > commands to reproduce the behavior you're trying to illustrate.) Good point. Again, my bad - very long day debugging. I wanted to show where I was in the directory so I sacrificed brevity for completeness and noise. My apologies. So, no bug, just a buggy user. Cheers, Randall

Re: [BUG] Worktree prune complains about missing path

On Tue, Feb 20, 2018 at 3:36 PM, Randall S. Becker wrote: > I’m a bit confused about this, as I thought I understood worktrees :(. > > /home/randall/nsgit/test/test dir.mytest: rm -rf dest.wt > /home/randall/nsgit/test/test dir.mytest/dest: git worktree prune -v > Removing

[BUG] Worktree prune complains about missing path

I’m a bit confused about this, as I thought I understood worktrees :(. /home/randall/nsgit/test/test dir.mytest/dest git worktree list /home/randall/nsgit/test/test dir.mytest/dest: git worktree list /home/randall/nsgit/test/test dir.mytest/dest 4e901ca [master] /home/randall/nsgit/test/test

git-gui, BUG: minimize/maximize buttons missing when repo is opened in gui

System: Ubuntu 17.10 Gnome When opening git-gui from a directory which is a repository, minimize and maximize buttons are showing and functional in git-gui. However, if I open git-gui in a non-repo directory, git-gui opens a dialog where I can "Create New Repository", "Clone Existing

[PATCH 0/2] quoting bug sending push-options over http

This series fixes a small quoting problem in 511155db51 (remote-curl: allow push options, 2017-03-22). The interesting one is the second patch. [1/2]: t5545: factor out http repository setup [2/2]: remote-curl: unquote incoming push-options remote-curl.c | 11 ++-

Re: Bug? Error during commit

Jeff King writes: > Here's the patch to make "show -B --stat" work. I'll give some more > thought to whether this is a good idea and prepare a series. > > One downside is that in the common case it causes us to look up each > object twice (once to get its size, and then again to

[BUG] git init doesn't respect `--template` like configuration variable init.templateDir and $GIT_TEMPLATE_DIR

The title says it all. If I run `git init --template=~/path/to/my/template` I get the following message: warning: templates not found ~/path/to/my/template But, if I run: $ env GIT_TEMPLATE_DIR=~/path/to/my/template git init I don't get a warning and the template is used just

Re: Bug? Error during commit

generate diffstat" message a bit too. One reason the message is so vague is that we don't actually have any kind of error code. Though really the only reason for xdiff to fail is due to file size. So we could perhaps offer some advice there. But if we do all the things I suggested above, then

Re: Bug? Error during commit

On Thu, Feb 8, 2018 at 3:45 AM, Jeff King wrote: > On Mon, Feb 05, 2018 at 08:59:52PM +0700, Duy Nguyen wrote: > >> On Mon, Feb 5, 2018 at 8:48 PM, Andreas Kalz wrote: >> > Hello, >> > >> > I am using git frequently and usually it is running great. >> > >> > I

Re: [PATCH 1/2] update-index doc: note a fixed bug in the untracked cache

On Fri, Feb 09 2018, Junio C. Hamano jotted: > Ævar Arnfjörð Bjarmason writes: > >>> Will queue with the above typofix, together with the other one. I >>> am not sure if we want to say "Before 2.17", though. >> >> I'm just keeping in mind the user who later on upgrades git

Re: [PATCH 1/2] update-index doc: note a fixed bug in the untracked cache

Ævar Arnfjörð Bjarmason writes: >> Will queue with the above typofix, together with the other one. I >> am not sure if we want to say "Before 2.17", though. > > I'm just keeping in mind the user who later on upgrades git from say > 2.14 to 2.18 or something, and is able to

Re: [PATCH 1/2] update-index doc: note a fixed bug in the untracked cache

On Fri, Feb 09 2018, Junio C. Hamano jotted: > Ævar Arnfjörð Bjarmason <ava...@gmail.com> writes: > >> +Before 2.17, the untracked cache had a bug where replacing a directory >> +with a symlink to another directory could cause it to incorrectly show >> +files tr

Re: [PATCH 1/2] update-index doc: note a fixed bug in the untracked cache

Ævar Arnfjörð Bjarmason <ava...@gmail.com> writes: > +Before 2.17, the untracked cache had a bug where replacing a directory > +with a symlink to another directory could cause it to incorrectly show > +files tracked by git as untracked. See the "status: add a fai

[PATCH 1/2] update-index doc: note a fixed bug in the untracked cache

Document the bug tested for in my "status: add a failing test showing a core.untrackedCache bug" and fixed in Duy's "dir.c: fix missing dir invalidation in untracked code". Since this is very likely something others will encounter in the future on older versions, and it's no

[BUG] Integer overflow when supplying large context value to diff --unified

Hello, Git versions tested: 2.13.6, 2.1.4 When passing-in a large context value for the --unified option for git-diff, Git will produce an invalid-looking range information for hunks. For example, if running 'git diff --unified=10 HEAD^', the output will include (this is just a run against my

Re: Bug Report: Subtrees and GPG Signed Commits

On Mon, Feb 5, 2018 at 1:45 PM, Junio C Hamano wrote: > Given that all references to this shell function seem to do > > sometree=$(toptree_for_commit $something) > > and then $sometree is used as if it were a tree object name, I can > understand why the lack of

Re: Bug? Error during commit

On Mon, Feb 05, 2018 at 08:59:52PM +0700, Duy Nguyen wrote: > On Mon, Feb 5, 2018 at 8:48 PM, Andreas Kalz wrote: > > Hello, > > > > I am using git frequently and usually it is running great. > > > > I read to write to this eMail address regarding problems and possible bugs.

Re: BUG: fetch in certain repo always gives "did not send all necessary objects"

On Wed, Feb 07, 2018 at 09:25:42AM -0800, Elijah Newren wrote: > > So other_head_refs knows that it's looking at the worktrees. And it > > passes the alternate ref-store to refs_head_ref(), with "add_one_ref" as > > the callback. But the knowledge that we're not talking about the real > > "HEAD"

Re: BUG: fetch in certain repo always gives "did not send all necessary objects"

t it (which I see from your message > that it also fails to do). > > I guess that's two more items on my todo list :) Cool, if you're taking a look at those, I'll take a look at the other one mentioned by Peff in this thread -- "make fsck pay attention to other worktree HEADs"

Re: BUG: On some Linux systems, "Stage To Commit" hotkey in git-gui stages one file only, even if multiple files are selected

On Wed, Feb 7, 2018 at 8:29 AM, Birger Skogeng Pedersen wrote: > Steps to reproduce (on Ubuntu 17.10): > - Open git-gui in a repository with two or more unstaged, changed files > - Select two or more files in the "Unstaged Changes" > - Click CTRL+T to stage the files that you

Re: BUG: fetch in certain repo always gives "did not send all necessary objects"

On Wed, Feb 7, 2018 at 5:21 AM, Jeff King wrote: > On Tue, Feb 06, 2018 at 04:00:32PM -0800, Elijah Newren wrote: > >> It took me hours to figure it out, after users ran out of ideas and >> came and asked me for help. (Maybe if I was familiar with worktree, >> and knew they had

Bug report: Subtree split including extra commits

Apologies if this is the wrong place to send a bug report for Contributed software. I've run into what seems like an issue/bug with git subtree. I am trying to split a single directory of our repo into its own repo using git subtree. I ran the the following command from our project root: git

Re: [bug report]: error doing_rebase

ed in my earlier mail), then you successfully confirmed that we fixed a bug, and that you expected the buggy behavior. > - with change SHA. > > It seems to be bug in recent version. > > Should I provide additional information? Ciao, Johannes > On 02/06/2018 12:4

BUG: On some Linux systems, "Stage To Commit" hotkey in git-gui stages one file only, even if multiple files are selected

In git-gui, multiple files from the "Unstaged Changes" widget can be selected. Once multiple files are selected, they can be staged by clicking (toolbar) "Commit"->"Stage To Commit". All the files that were selected then gets staged for the commit. The "Stage To Commit" hotkey (CTRL+T) behaves

Re: BUG: fetch in certain repo always gives "did not send all necessary objects"

On Wed, Feb 07, 2018 at 08:21:57AM -0500, Jeff King wrote: > The best PSA for this particular bug may be "try pruning the worktrees": > > $ git worktree prune -v > Removing worktrees/foo: gitdir file points to non-existent location > > $ git prune; echo

Re: BUG: fetch in certain repo always gives "did not send all necessary objects"

On Wed, Feb 07, 2018 at 06:08:40PM +0700, Duy Nguyen wrote: > > And/or ideas of what steps could cause corruption so I can send out a > > PSA to help users avoid it? > > There is another thing we could do. One bad HEAD should not abort the > entire operation (at least if it's not the current

Re: BUG: fetch in certain repo always gives "did not send all necessary objects"

nk that materially changes anything. Until you run "git worktree prune", that HEAD file is still there and still supposed to be valid. > I suspect you mean that there was another previous bug that induced > corruption, that this commit fixed that other bug, while also > introduc

Re: BUG: fetch in certain repo always gives "did not send all necessary objects"

ing and move on, or don't warn at all and let "git worktree prune" collect it (which I see from your message that it also fails to do). I guess that's two more items on my todo list :) Sorry for all the trouble because of this bug of mine. > If not, I'll try to dig more, but I thought I'd ask others familiar > with this area. -- Duy

Re: BUG: fetch in certain repo always gives "did not send all necessary objects"

ng directory that made use of a now gc'ed commit. In the case I was able to dig into, we did not. (There was a left-over .git/worktree/ that had a now gc'ed commit, but no working directory that used it.) I suspect you mean that there was another previous bug that induced corruption, that this

Re: BUG: fetch in certain repo always gives "did not send all necessary objects"

On Tue, Feb 6, 2018 at 3:04 PM, Elijah Newren wrote: > > Does anyone have an idea what may have happened here or how to avoid it? According to Peff this got fixed https://public-inbox.org/git/20171020031630.44zvzh3d2vlhg...@sigill.intra.peff.net/ and but you've had a corrupted

BUG: fetch in certain repo always gives "did not send all necessary objects"

the unused directory under .git/worktree (perhaps because it thought something was using it?). The fetch bug didn't go away until doing an 'rm -rf .git/worktree/3.0-release'. I have no experience prior to today with git worktree, and the developer in question doesn't remember how things got to th

Re: Cloned repository has file changes -> bug?

Jeff King writes: > I'm not entirely convinced it's worth all of this effort, but I think it > would be _possible_ at least. I thought that the original poster wants to have a knob that the project can ask its participants to enable in their clones of the repository that wars

Re: Cloned repository has file changes -> bug?

I’m not git expert but, from a user point of view, the following would make sense. When adding a file, git could check whether a different file is already in the repository with the same name (case-insensitive check). Then simply report that this may be a mistake and request to use ‘git add -f’

Re: Cloned repository has file changes -> bug?

On Tue, Feb 06, 2018 at 02:24:25PM +0100, Ævar Arnfjörð Bjarmason wrote: > 3) Such hooks slow down pushes, especially on big repos, you can > optimize things a bit (e.g. only look in the same directories), but > pathologically you end up needing to compare the cross-product of >

Re: Cloned repository has file changes -> bug?

On Tue, Feb 06 2018, Filip Jorissen jotted: > Hi all, > > Thank you for your quick responses. I was able to resolve the problem based > on your feedback! > > Based on this experience, I would like to suggest that git is somehow able to > avoid these problems by doing a case check itself rather

Re: Cloned repository has file changes -> bug?

On Tue, Feb 6, 2018 at 8:09 PM, Filip Jorissen wrote: > Hi all, > > Thank you for your quick responses. I was able to resolve the problem based > on your feedback! > > Based on this experience, I would like to suggest that git is somehow able to > avoid these

Re: Cloned repository has file changes -> bug?

Hi all, Thank you for your quick responses. I was able to resolve the problem based on your feedback! Based on this experience, I would like to suggest that git is somehow able to avoid these problems by doing a case check itself rather than relying on the host OS for this? Kind regards!

Re: [bug report]: error doing_rebase

Hi, On Mon, 5 Feb 2018, Bulat Musin wrote: > Now there are 3 sequential commits, I want to squash them into 1: > > git rebase -i HEAD~2 > > In editor I changed all "pick" to "squash", saved file, I got: > > error: cannot 'squash' without a previous commit You cannot start with a squash. You

[bug report]: error doing_rebase

Hi. To reproduce: git init testrepo cd testrepo echo 1 >> file git add file git commit -m'1' echo 2 >> file git add file git commit -m'2' echo 3 >> file git add file git commit -m'3' Now there are 3 sequential commits, I want to squash them into 1: git rebase -i HEAD~2 In editor I

Re: Bug Report: Subtrees and GPG Signed Commits

Stephen R Guglielmo writes: > diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh > index cc033af73..dec085a23 100755 > --- a/contrib/subtree/git-subtree.sh > +++ b/contrib/subtree/git-subtree.sh > @@ -475,7 +475,7 @@ squash_msg () { > >

Re: Bug Report: Subtrees and GPG Signed Commits

On Mon, Feb 5, 2018 at 9:30 AM, Stephen R Guglielmo wrote: > On Wed, Jan 31, 2018 at 7:33 AM, Stephen R Guglielmo > wrote: >> On Tue, Jan 30, 2018 at 6:37 PM, Avery Pennarun wrote: >>> On Tue, Jan 30, 2018 at 6:24 PM, Junio C

Re: Bug Report: Subtrees and GPG Signed Commits

On Wed, Jan 31, 2018 at 7:33 AM, Stephen R Guglielmo wrote: > On Tue, Jan 30, 2018 at 6:37 PM, Avery Pennarun wrote: >> On Tue, Jan 30, 2018 at 6:24 PM, Junio C Hamano wrote: >>> Stefan Beller writes: There

Re: Bug? Error during commit

On Mon, Feb 5, 2018 at 8:48 PM, Andreas Kalz wrote: > Hello, > > I am using git frequently and usually it is running great. > > I read to write to this eMail address regarding problems and possible bugs. > I am using git version 2.16.1.windows.2 / 64 Bit and during commit the

Bug? Error during commit

Hello,   I am using git frequently and usually it is running great.   I read to write to this eMail address regarding problems and possible bugs. I am using git version 2.16.1.windows.2 / 64 Bit and during commit the following error message comes up: e:\Internet>git commit -m 2018-01-27 fatal:

Re: Bug Report: Subtrees and GPG Signed Commits

Stephen R Guglielmo writes: > On Tue, Jan 30, 2018 at 6:37 PM, Avery Pennarun wrote: >> >> Sorry I can't help more. >> >> Good luck, >> >> Avery > > Thanks all for the discussion/replies. > > We use subtrees extensively in our environment right now.

Re: Bug/comment

On Tuesday 30 January 2018 05:32 AM, Andrew Ardill wrote: > Hi Ilija, > > On 30 January 2018 at 10:21, Ilija Pecelj <pec...@gmail.com> wrote: >> Though it might not be considered a bug 'per se' it is definitely wired. >> Namely, when you type 'yes' word and hit en

Re: Bug Report: Subtrees and GPG Signed Commits

On Tue, Jan 30, 2018 at 6:37 PM, Avery Pennarun wrote: > On Tue, Jan 30, 2018 at 6:24 PM, Junio C Hamano wrote: >> Stefan Beller writes: >>> There has not been feedback for a while on this thread. >>> I think that is because subtrees

Re: Bug Report: Subtrees and GPG Signed Commits

On Tue, Jan 30, 2018 at 6:24 PM, Junio C Hamano wrote: > Stefan Beller writes: >> There has not been feedback for a while on this thread. >> I think that is because subtrees are not in anyone's hot >> interest area currently. >> >> This is definitely the

Re: Bug Report: Subtrees and GPG Signed Commits

Stefan Beller writes: > There has not been feedback for a while on this thread. > I think that is because subtrees are not in anyone's hot > interest area currently. > > This is definitely the right place to submit bugs. > Looking through "git log --format="%ae %s" -S

Re: Bug Report: Subtrees and GPG Signed Commits

On Tue, Jan 30, 2018 at 11:15 AM, Stephen R Guglielmo <srguglie...@gmail.com> wrote: > Hi, just following up on this bug report. I have not heard back. Is > there additional information that's needed? Is there a better place to > file bug reports? > > Additionally, I have co

Re: Bug Report: Subtrees and GPG Signed Commits

Hi, just following up on this bug report. I have not heard back. Is there additional information that's needed? Is there a better place to file bug reports? Additionally, I have confirmed that this bug still exists with git version 2.16.1. Thanks On Thu, Jan 18, 2018 at 11:19 AM, Stephen R

Re: Bug/comment

Hi Ilija, On 30 January 2018 at 10:21, Ilija Pecelj <pec...@gmail.com> wrote: > Though it might not be considered a bug 'per se' it is definitely wired. > Namely, when you type 'yes' word and hit enter in git bash for widnows, the > process enters infinite loop and just prints 'y

Bug/comment

Though it might not be considered a bug 'per se' it is definitely wired. Namely, when you type 'yes' word and hit enter in git bash for widnows, the process enters infinite loop and just prints 'y' letter in new line. It can be interrupted with CTRL+C. I'm not sure if it has any other

Re: Cloned repository has file changes -> bug?

he > end of this email. Git checkout does not work to remove the file changes. > This behavior seems to be reproducible across multiple computers. Is this a > bug? How can I fix the repository? > > Changes not staged for commit: > (use "git add ..." to update what will

Re: Cloned repository has file changes -> bug?

On Sat, Jan 27, 2018 at 08:59:50PM +0100, Ævar Arnfjörð Bjarmason wrote: > > On Sat, Jan 27 2018, Filip Jorissen jotted: > > > I think our git repository is bugged. The reason why I say this is the > > following. When cloning the repository, the newly cloned repository > > immediately has file

Re: Cloned repository has file changes -> bug?

On Sat, Jan 27 2018, Filip Jorissen jotted: > I think our git repository is bugged. The reason why I say this is the > following. When cloning the repository, the newly cloned repository > immediately has file changes[...]. If you run this: git ls-files | tr '[:upper:]' '[:lower:]' | sort

Cloned repository has file changes -> bug?

changes. This behavior seems to be reproducible across multiple computers. Is this a bug? How can I fix the repository? Thanks in advance for the support! Filip MacBook-Pro-van-Filip:git filip$ git clone g...@github.com:open-ideas/IDEAS.git Cloning into 'IDEAS'... remote: Counting objects: 48419

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

On Fri, Jan 26, 2018 at 2:50 PM, Kaartic Sivaraam <kaartic.sivar...@gmail.com> wrote: > This might seem to be a bug as the comment in "git-rebase-todo" says, > > However, if you remove everything, the rebase will be aborted. > > But "man git rebase" cl

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

problem is, HEAD is moved away anyway (to origin/master I > think)  For me it left HEAD at @~3. Reading the synopsis of `man git rebase` I could guess that the corresponding abstract form would be, $ git rebase -i > even if rebase is supposed to abort the operation and leave

Re: git credential-osxkeychain bug/feature?

On Thu, Jan 25, 2018 at 12:16:33PM -0500, Robert Leach wrote: > But perhaps access to KA from a remote ssh session is restricted for > security reasons? I'm just curious I suppose. Should/can this work? It's definitely not a restriction from the osxkeychain credential helper. I believe that

git credential-osxkeychain bug/feature?

Hi, I wanted to submit an issue regarding the credential-osxkeychain interface functionality. I don't know whether it's a bug or a feature request. Maybe it's even impossible to address? - I don't know, but here's my issue. Let me know if fixing/implementing this is a bad idea or if it's

Bug, git rebase -i does not abort correctly

rebase scripts are too much for me, so I'll play the user reporting bugs this time :) Instead of doing $ git rebase -i --onto origin/master @~3 I sometimes accidentally type $ git rebase -i origin/master @~3 ("rebase -i" is actually an alias, which is why I never forget to type -i)

Re: [BUG] git pull with pull.rebase and rebase.autoStash is not working anymore in 2.16

Yeah it seems like this bug. Thank you for sharing this with me. -- Sincerely, Dimitriy Ryazantcev > Could this be the same one as reported as Git for Windows issue > #1437[1] ("`git status` reports (non-existent) modifications after > `git stash push`", 2018-01-20), fixed

Re: git merge-tree: bug report and some feature requests

On Tue, Jan 23, 2018 at 3:52 AM, Edward Thomson wrote: > Indeed, when I added merge to libgit2, we put the higher-level conflict > analysis into application code because there was not much interest in it > at the time. I've been meaning to add this to `git_status` in

Re: [BUG] git pull with pull.rebase and rebase.autoStash is not working anymore in 2.16

Hi Dimitriy, On 24/01/2018 13:19, Dimitriy wrote: > > Looks like regression in 2.16. > Worked fine before update. > Seems like git stash is not always working. > Any ideas? Could this be the same one as reported as Git for Windows issue #1437[1] ("`git status` reports (non-existent)

Re: git merge-tree: bug report and some feature requests

Thanks, Ed. I think I'll pursue the libgit2 route; sounds promising. >> But the alternative appears to be punting entirely, as libgit2 does, >> and merely providing something akin to three index entries. > > Indeed, when I added merge to libgit2, we put the higher-level conflict > analysis into

[BUG] git pull with pull.rebase and rebase.autoStash is not working anymore in 2.16

Looks like regression in 2.16. Worked fine before update. Seems like git stash is not always working. Any ideas? $ git --version git version 2.16.0.windows.2 $ git config pull.rebase true $ git config rebase.autoStash true $ git status On branch develop Your branch is behind 'origin/develop'

[PATCH 4/5] update-index doc: note a fixed bug in the untracked cache

From: Ævar Arnfjörð Bjarmason <ava...@gmail.com> Document the bug tested for in my "status: add a failing test showing a core.untrackedCache bug" and fixed in Duy's "dir.c: fix missing dir invalidation in untracked code". Since this is very likely something others wi

[PATCH 1/5] status: add a failing test showing a core.untrackedCache bug

he "sleep 1" after the "checkout master" are needed to reproduce this, presumably due to the untracked cache tracking on the basis of cached whole seconds from stat(2). When git gets into this state, a workaround to fix it is to issue a one-off: git -c core.untrackedCa

Re: git merge-tree: bug report and some feature requests

On Tue, Jan 23, 2018 at 7:08 AM, Josh Bleecher Snyder wrote: > Looking over your list above, at a minimum, libgit2 might not have a > particularly good way to represent submodule/file or > submodule/directory conflicts, because is-a-submodule is defined > external to a

Re: git merge-tree: bug report and some feature requests

>> I'm experimenting with some new porcelain for interactive rebase. One >> goal is to leave the work tree untouched for most operations. It looks >> to me like 'git merge-tree' may be the right plumbing command for >> doing the merge part of the pick work of the todo list, one commit at >> a

Re: git merge-tree: bug report and some feature requests

On Sat, Jan 20, 2018 at 7:00 PM, Josh Bleecher Snyder wrote: > Hi, all. > > I'm experimenting with some new porcelain for interactive rebase. One > goal is to leave the work tree untouched for most operations. It looks > to me like 'git merge-tree' may be the right plumbing

Re: git merge-tree: bug report and some feature requests

On Sun, Jan 21 2018, Josh Bleecher Snyder jotted: > 3. Feature suggestion > > There's no direct indication of whether any given file's merge > succeeded. Currently I sniff for merge conflicts by looking for > "+<<< .our", which feels like an ugly kludge. Could we provide an > explicit

git merge-tree: bug report and some feature requests

. If I'm wrong about this, I'd love pointers; what follows may still be interesting anyway. I've encountered some bumps with 'git merge-tree'. A bug report and some feature requests follow. Apologies for the long email. 1. Bug When a binary file containing NUL is added on only one side, the resulting

Re: Bug Report: Subtrees and GPG Signed Commits

Hi, just following up on this bug report. I have not heard back. Is there additional information that's needed? Is there a better place to file bug reports? Thanks On Sat, Jan 6, 2018 at 5:45 PM, Stephen R Guglielmo <srguglie...@gmail.com> wrote: > Hi all, > > I've noticed an

Re: [BUG] git remote prune removes local tags, depending on fetch config

On Tue, Jan 16, 2018 at 12:48:32PM +0100, Andreas Schwab wrote: > On Jan 15 2018, Michael Giuffrida wrote: > > > It doesn't seem like a useful feature -- you wouldn't expect `git > > fetch --prune` to remove your local branches that you were developing > > on, right? > >

Re: [BUG] git remote prune removes local tags, depending on fetch config

On Jan 15 2018, Michael Giuffrida wrote: > It doesn't seem like a useful feature -- you wouldn't expect `git > fetch --prune` to remove your local branches that you were developing > on, right? Don't mix local and remote refs. There is a reason why remote tracking

Re: [BUG] git remote prune removes local tags, depending on fetch config

On Tue, Jan 16 2018, Michael Giuffrida jotted: > Just to confirm, you're talking about the behavior of removing *all* > tags that aren't found on the remote? (Not just tags that used to be > on some remote, but have since been removed from that remote.) So, > with your proposed workflow, you

RE: [BUG] test_must_fail: does not correctly detect failures - Was Git 2.16.0-rc2 Test Summary on NonStop

, which > > clearly does not happen in this case. On the platform, if the perl > > script is via stdin, 162 or 169 are returned. If via file (perl > > file.pl), 255 comes back. The port has issues. I have an opened a bug > > report with the platform developers. Usua

Re: [BUG] test_must_fail: does not correctly detect failures - Was Git 2.16.0-rc2 Test Summary on NonStop

in, 162 or 169 are returned. If via file (perl > file.pl), 255 comes back. The port has issues. I have an opened a bug > report with the platform developers. Usual non-Open Source timeframes > to fix apply. ☹ I believe the standard behavior for Perl with die is the following: exit $!

Re: [BUG] git remote prune removes local tags, depending on fetch config

Just to confirm, you're talking about the behavior of removing *all* tags that aren't found on the remote? (Not just tags that used to be on some remote, but have since been removed from that remote.) So, with your proposed workflow, you would never create your own tags locally, without pushing

Re: [BUG] git remote prune removes local tags, depending on fetch config

On Mon, Jan 15 2018, Michael Giuffrida jotted: > `git remote prune ` should "delete all stale remote-tracking > branches under ". I was surprised to discover, after some > troubleshooting, that it also deletes *all* local tags that don't > exist on the remote, if the following refspec is

[BUG] git remote prune removes local tags, depending on fetch config

`git remote prune ` should "delete all stale remote-tracking branches under ". I was surprised to discover, after some troubleshooting, that it also deletes *all* local tags that don't exist on the remote, if the following refspec is included in the remote's fetch config:

RE: [BUG] test_must_fail: does not correctly detect failures - Was Git 2.16.0-rc2 Test Summary on NonStop

funky would be > short-sighted. [I'm saying all this without knowing how perl specifies 'die' > beyond the paragraph you cited. Perhaps there's more about 'die' that > justifies exit code 162.] I'd say that the perl port is broken. I agree that 162 is wrong. Its interpretation is 128+signal,

Re: [BUG] test_must_fail: does not correctly detect failures - Was Git 2.16.0-rc2 Test Summary on NonStop

Am 15.01.2018 um 03:37 schrieb Randall S. Becker: On January 14, 2018 4:33 PM, I wrote: The exotic error code coming back from perl is 162. I can muck with it, if there was a value more useful to git. * 553 } else if (WIFEXITED(status)) { * 554 code =

RE: [BUG] test_must_fail: does not correctly detect failures - Was Git 2.16.0-rc2 Test Summary on NonStop

On January 14, 2018 4:33 PM, I wrote: > On January 14, 2018 1:41 PM Johannes Sixt wrote: > > Sent: > > Am 14.01.2018 um 17:50 schrieb Randall S. Becker: > > > Follow-up: This looks like the completion code from perl on NonStop > > > is not the same as expected by git in the case of failures. I

RE: [BUG] test_must_fail: does not correctly detect failures - Was Git 2.16.0-rc2 Test Summary on NonStop

> -Original Message- > From: Johannes Sixt [mailto:j...@kdbg.org] > Sent: On January 14, 2018 1:41 PM wrote: > Am 14.01.2018 um 17:50 schrieb Randall S. Becker: > > Follow-up: This looks like the completion code from perl on NonStop is > > not the same as expected by git in the case of

Re: [BUG] test_must_fail: does not correctly detect failures - Was Git 2.16.0-rc2 Test Summary on NonStop

Am 14.01.2018 um 17:50 schrieb Randall S. Becker: Follow-up: This looks like the completion code from perl on NonStop is not the same as expected by git in the case of failures. I need to debug this to get more details to the team. We have had completion issues before relating to interpretation

RE: [BUG] test_must_fail: does not correctly detect failures - Was Git 2.16.0-rc2 Test Summary on NonStop

On January 13, 2018 3:17 PM, I wrote: > On January 13, 2018 2:31 PM, I wrote: > > On January 13, 2018 1:08 PM, I wrote: > > > Here’s where things are. This is probably the best git release so > > > far > > (ever). > > > After applying a4cdf02, I had 6 total breakages. 3 existing, 3 new. > > > Many

[BUG] test_must_fail: does not correctly detect failures - Was Git 2.16.0-rc2 Test Summary on NonStop

On January 13, 2018 2:31 PM, I wrote: > On January 13, 2018 1:08 PM, I wrote: > > Here’s where things are. This is probably the best git release so far > (ever). > > After applying a4cdf02, I had 6 total breakages. 3 existing, 3 new. > > Many reduced. The test took about 24 hours to run on

RE: [BUG] Weird breakages in t1450 #2 on NonStop

On January 12, 2018 9:39 AM, Jeff King wrote: > On Thu, Jan 11, 2018 at 04:39:04PM -0500, Randall S. Becker wrote: > > > > executed because the test_commit fails with a non-zero git commit > > > completion code. There is no rn (actual r n 252 252 252 252) in > > > the objects directory - even

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