Re: [BUG REPORT] Git does not correctly replay bisect log

On Thu, Dec 6, 2018 at 6:30 PM Lukáš Krejčí wrote: > > I am talking about `git bisect replay`. The shell script, as far as I > can see, only updates the references (ref/bisect/*) and never checks if > the revisions marked as 'good' are ancestors of the 'bad' one. > Therefore,

Re: [BUG REPORT] Git does not correctly replay bisect log

On Thu, 2018-12-06 at 17:31 +0100, Christian Couder wrote: > > When Git replays the bisect log, it only updates refs/bisect/bad, > > refs/bisect/good-*, refs/bisect/skip-* and reconstructs the log in > > .git/BISECT_LOG. After that check_good_are_ancestors_of_bad() verifies > > that all good

Re: [BUG REPORT] Git does not correctly replay bisect log

Hi, On Thu, Dec 6, 2018 at 3:43 PM Lukáš Krejčí wrote: > > Hello again, > > after looking into this today, I'm not sure if this can be considered a > bug - it's just that I expected Git to check out the exact commit to > test that was there before resetting the bisect. That made me uncertain >

Re: [BUG REPORT] Git does not correctly replay bisect log

Hello again, after looking into this today, I'm not sure if this can be considered a bug - it's just that I expected Git to check out the exact commit to test that was there before resetting the bisect. That made me uncertain whether Git restored the correct state. When I looked at what Git

Re: [BUG REPORT] Git does not correctly replay bisect log

On Tue, 2018-12-04 at 13:01 +0100, Christian Couder wrote: > To debug I think it would be interesting to see the output of the > following commands just before we get different results: > > git for-each-ref 'refs/bisect/*' > > and > > git log -1 --format=oneline > I placed the following

Re: [BUG REPORT] Git does not correctly replay bisect log

On Tue, Dec 4, 2018 at 12:20 PM Lukáš Krejčí wrote: > > On Tue, 2018-12-04 at 12:04 +0100, Christian Couder wrote: > > > > Could you try to check that? And first could you give us the output of: > > > > git merge-base 5b394b2ddf0347bef56e50c69a58773c94343ff3 > >

Re: [BUG REPORT] Git does not correctly replay bisect log

(I'm sorry about the formatting, here's the message again.) Executing git bisect replay reaches a different commit than the one that is obtained by running the commands from the bisect log manually. Distribution: Arch Linux git: 2.19.2-1 perl: 5.28.1-1 pcre2: 10.32-1 expat: 2.2.6-1 perl-error:

Re: [BUG REPORT] Git does not correctly replay bisect log

On Tue, 2018-12-04 at 12:04 +0100, Christian Couder wrote: > > Could you try to check that? And first could you give us the output of: > > git merge-base 5b394b2ddf0347bef56e50c69a58773c94343ff3 > 94710cac0ef4ee177a63b5227664b38c95bbf703 $ git merge-base 5b394b2ddf0347bef56e50c69a58773c94343ff3

Re: [BUG REPORT] Git does not correctly replay bisect log

On Tue, Dec 4, 2018 at 10:53 AM Lukáš Krejčí wrote: > > Executing git bisect replay reaches a different commit than > the one that is obtained by running the commands from the bisect log manually. > $ git bisect replay /var/tmp/git-bisect.log > We are not bisecting. > Bisecting: a merge base

Re: [bug report] git-gui child windows are blank

Just checked gitk, it seems to work fine including children windows. This problem seems to affect git-gui only. On Thu, Nov 29, 2018 at 5:16 AM Eric Sunshine wrote: > > On Wed, Nov 28, 2018 at 2:29 PM Stefan Beller wrote: > > On Wed, Nov 28, 2018 at 6:13 AM Kenn Sebesta wrote: > > > v2.19.2,

Re: [bug report] git-gui child windows are blank

On Wed, Nov 28, 2018 at 2:29 PM Stefan Beller wrote: > On Wed, Nov 28, 2018 at 6:13 AM Kenn Sebesta wrote: > > v2.19.2, installed from brew on macOS Mojave 14.2.1. > > > > `git-gui` is my much beloved go-to tool for everything git. > > Unfortunately, on my new Macbook Air it seems to have a bug.

Re: [BUG REPORT] t5322: demonstrate a pack-objects bug

On 11/28/2018 2:45 PM, Derrick Stolee wrote: I was preparing a new "sparse" algorithm for calculating the interesting objects to send on push. The important steps happen during 'git pack-objects', so I was creating test cases to see how the behavior changes in narrow cases. Specifically, when

Re: [bug report] git-gui child windows are blank

On Wed, Nov 28, 2018 at 6:13 AM Kenn Sebesta wrote: > > v2.19.2, installed from brew on macOS Mojave 14.2.1. > > `git-gui` is my much beloved go-to tool for everything git. > Unfortunately, on my new Macbook Air it seems to have a bug. When I > first load the program, the parent window populates

Re: BUG REPORT: git clone of non-existent repository results in request for credentials

I was afraid that was the reason. Oh well, at least we know why :-) Thanks Ævar! Best-F > On Nov 11, 2018, at 9:00 AM, Ævar Arnfjörð Bjarmason wrote: > > >> On Sun, Nov 11 2018, Federico Lucifredi wrote: >> >> git clone of non-existent repository results in request for credentials >> >>

Re: BUG REPORT: git clone of non-existent repository results in request for credentials

On Sun, Nov 11 2018, Federico Lucifredi wrote: > git clone of non-existent repository results in request for credentials > > REPRODUCING: > sudo apt install git > git clone https://github.com/xorbit/LiFePo4owered-Pi.git#this repo does > not exist > > Git will then prompt for username and

Re: [Bug report] Git incorrectly selects language in macos

On Fri, Sep 14, 2018 at 10:20 PM Niko Dzhus wrote: > Looks like the issue appeared after updating git from brew. > > A quick search revealed that brew changed how it builds git recently. > I think, it just didn't include i18n by default before, so I never > noticed this. > > Anybody here familiar

Re: [Bug report] Git incorrectly selects language in macos

Looks like the issue appeared after updating git from brew. I tried it on a different mac laptop, git 2.18 still used English, but after updating to 2.19 it started using secondary language. A quick search revealed that brew changed how it builds git recently. I think, it just didn't include

Re: [Bug report] Git incorrectly selects language in macos

Tried what you suggested - it seems, it only ignores English. In you example, with Swedish as primary and German as secondary, git uses Swedish. With more that one secondary language, the one with a higher priority is being used, as expected. I also tried using non-generic English (English-UK and

Re: [Bug report] Git incorrectly selects language in macos

On Fri, Sep 14 2018, Niko Dzhus wrote: > It doesn't use English when other language is available as a secondary > language. > > Reproducing: > > 1. Open "Language & Region" in macos settings > 2. In "Preferred languages" box, set English as a primary language. > 3. Add another language, that

Re: (Bug report + fix) gitk "IgnCase" search doesn't ignore case

On Thu, Jun 14, 2018 at 02:53:03PM +0200, Juan Navarro wrote: > Gitk "find commit" search function doesn't follow the "IgnCase" option that > is selectable with a combo selector on the right side of the window; it > should be searching in a case-insensitive way, but it doesn't. > > Steps to

Re: Bug report for git push

On Fri, May 11, 2018 at 09:44:54PM -0400, Surenkumar Nihalani wrote: > Push summary: [remote rejected] (cannot lock ref 'refs/heads/master': is at > cf2cc0c147d8215ec87d3ddaf32f0b2c58630423 but expected > fdda486ad43a6e6b5dc5f2795ce27124e0686752) This generally indicates that somebody was

Re: BUG report: unicode normalization on APFS (Mac OS High Sierra)

Hi, On Fri, Apr 27, 2018 at 2:45 PM, Totsten Bögershausen wrote: > On 2018-04-26 19:23, Elijah Newren wrote: >> Sure. First, though, note that I can make it pass (or at least "not >> ok...TODO known breakage") with the following patch (may be >> whitespace-damaged by gmail): >>

Re: BUG report: unicode normalization on APFS (Mac OS High Sierra)

On 2018-04-26 19:23, Elijah Newren wrote: On Thu, Apr 26, 2018 at 10:13 AM, Torsten Bögershausen wrote: Hm, thanks for the report. I don't have a high sierra box, but I can probably get one. t0050 -should- pass automagically, so I feel that I can do something. Unless someone

Re: BUG report: unicode normalization on APFS (Mac OS High Sierra)

On Thu, Apr 26, 2018 at 10:13 AM, Torsten Bögershausen wrote: > Hm, > thanks for the report. > I don't have a high sierra box, but I can probably get one. > t0050 -should- pass automagically, so I feel that I can do something. > Unless someone is faster of course. Sweet, thanks

Re: BUG report: unicode normalization on APFS (Mac OS High Sierra)

On 26.04.18 18:48, Elijah Newren wrote: > On HFS (which appears to be the default Mac filesystem prior to High > Sierra), unicode names are "normalized" before recording. Thus with a > script like: > > mkdir tmp > cd tmp > > auml=$(printf "\303\244") > aumlcdiar=$(printf

Re: Bug Report - Pull remote branch does not retrieve new tags

t re-cloning, as my https://public-inbox.org/git/874lkuvtve@evledraar.gmail.com/ explains. > >> -Original Message- >> From: Bryan Turner [mailto:btur...@atlassian.com]V >> Sent: 19 April 2018 23:14 >> To: Andrew Ducker >> Cc: git@vger.kernel.org &

RE: Bug Report - Pull remote branch does not retrieve new tags

soft/vscode/issues/48211 if anyone wants to chime in with advice over there :-) Thanks, Andy > -Original Message- > From: Bryan Turner [mailto:btur...@atlassian.com] > Sent: 19 April 2018 23:14 > To: Andrew Ducker > Cc: git@vger.kernel.org > Subject: Re: Bug Report - Pull remote br

Re: Bug Report - Pull remote branch does not retrieve new tags

Andrew, On Thu, Apr 19, 2018 at 6:55 AM, Andrew Ducker wrote: > > What happens: > When I create a new tag on the remote (changing nothing else) > "git pull origin master" produces the following: > From git.internal.company.com:team/testrepo >* branch

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

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 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 existing diff piped

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" add --patch > > and after having

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 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 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

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 report]: error doing_rebase

Hi Bulat, Please make sure to keep the Git mailing list in Cc: (I get *very* prickly when Git users treat me as a free-of-cost help desk, and when I get that annoyed, I stop helping). On Tue, 6 Feb 2018, Bulat Musin wrote: > Yes, I tested again. > > With built 2.16... and it shows error

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

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 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 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 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 confirmed that this bug

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 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 wrote: > Hi all, > > I've noticed an issue regarding the

Re: Bug report: git clone with dest

On Fri, Jan 05, 2018 at 02:37:25PM -0800, Junio C Hamano wrote: > Well, MaintNotes on the 'todo' branch needs a bit of updating, as it > says something somewhat misleading. > > -- >8 -- > Subject: MaintNotes: clarify the purpose of maint->master upmerge Yup, this makes sense. Thanks for

Re: Bug report: git clone with dest

Jeff King writes: > On Fri, Jan 05, 2018 at 12:45:03PM -0800, Junio C Hamano wrote: > >> Jeff King writes: >> >> > Out of curiosity, did this change at some point? I thought the process >> > used to be to merge to maint, and then pick up topics in master by >> >

Re: Bug report: git clone with dest

Hi Peff, On Fri, 5 Jan 2018, Jeff King wrote: > On Fri, Jan 05, 2018 at 09:22:07PM +0100, Johannes Schindelin wrote: > > > On Fri, 5 Jan 2018, Isaac Shabtay wrote: > > > > > Done: https://github.com/git-for-windows/git/pull/1421 > > > > > > I added credit to Jeff in the PR's description. > >

Re: Bug report: git clone with dest

Hi, On Fri, 5 Jan 2018, Junio C Hamano wrote: > Jeff King writes: > > > On Wed, Jan 03, 2018 at 02:42:51PM -0800, Isaac Shabtay wrote: > > > >> Indeed interesting... this one's for the books... > >> Thanks for the patches. Any idea when these are going to make it to the > >>

Re: Bug report: git clone with dest

On Fri, Jan 05, 2018 at 12:45:03PM -0800, Junio C Hamano wrote: > Jeff King writes: > > > Out of curiosity, did this change at some point? I thought the process > > used to be to merge to maint, and then pick up topics in master by > > merging maint to master. > > If you look at

Re: Bug report: git clone with dest

Jeff King writes: > Out of curiosity, did this change at some point? I thought the process > used to be to merge to maint, and then pick up topics in master by > merging maint to master. If you look at "Sync with maint" merges made to 'master', you'd notice that most of them are

Re: Bug report: git clone with dest

On Fri, Jan 05, 2018 at 09:22:07PM +0100, Johannes Schindelin wrote: > On Fri, 5 Jan 2018, Isaac Shabtay wrote: > > > Done: https://github.com/git-for-windows/git/pull/1421 > > > > I added credit to Jeff in the PR's description. > > Sadly, the PR's description won't make it into the commit

Re: Bug report: git clone with dest

Johannes Schindelin writes: > Hi Isaac, > > On Fri, 5 Jan 2018, Isaac Shabtay wrote: > >> Done: https://github.com/git-for-windows/git/pull/1421 >> >> I added credit to Jeff in the PR's description. > > Sadly, the PR's description won't make it into the commit

Re: Bug report: git clone with dest

Hi Isaac, On Fri, 5 Jan 2018, Isaac Shabtay wrote: > Done: https://github.com/git-for-windows/git/pull/1421 > > I added credit to Jeff in the PR's description. Sadly, the PR's description won't make it into the commit history, and the authorship really should have been retained. I found

Re: Bug report: git clone with dest

On Fri, Jan 05, 2018 at 11:53:50AM -0800, Junio C Hamano wrote: > > They haven't even been reviewed yet. If they get good feedback, then the > > maintainer will pick them up, then merge them to 'next', and then > > eventually to 'master', after which they'd become part of the next > > major

Re: Bug report: git clone with dest

Jeff King writes: > On Wed, Jan 03, 2018 at 02:42:51PM -0800, Isaac Shabtay wrote: > >> Indeed interesting... this one's for the books... >> Thanks for the patches. Any idea when these are going to make it to the >> official Git client builds? (specifically the Windows one) > >

Re: Bug report: git clone with dest

Done: https://github.com/git-for-windows/git/pull/1421 I added credit to Jeff in the PR's description. Note that I tried compiling master, but failed due to a reason unrelated to this patch: builtin/checkout.c:24:10: fatal error: fscache.h: No such file or directory Maybe I wasn't building it

Re: Bug report: git clone with dest

Hi Isaac, On Thu, 4 Jan 2018, Isaac Shabtay wrote: > I cloned git's codebase, applied the four patches on master, built and > tested on Ubuntu Trusty. (After verifying that master indeed exhibits > this behaviour on Linux as well. Just checking). > Seems to work fine. > I also looked at the

Re: Bug report: git clone with dest

Hello Johannes, Jeff, I cloned git's codebase, applied the four patches on master, built and tested on Ubuntu Trusty. (After verifying that master indeed exhibits this behaviour on Linux as well. Just checking). Seems to work fine. I also looked at the code. Most of the patched lines relate to

Re: Bug report: git clone with dest

Hi Isaac, On Wed, 3 Jan 2018, Isaac Shabtay wrote: > Indeed interesting... this one's for the books... > Thanks for the patches. Any idea when these are going to make it to > the official Git client builds? (specifically the Windows one) If you help them getting reviewed, tested, and validated,

Re: Bug report: git clone with dest

On Wed, Jan 03, 2018 at 02:42:51PM -0800, Isaac Shabtay wrote: > Indeed interesting... this one's for the books... > Thanks for the patches. Any idea when these are going to make it to the > official Git client builds? (specifically the Windows one) They haven't even been reviewed yet. If they

Re: Bug report: git clone with dest

Indeed interesting... this one's for the books... Thanks for the patches. Any idea when these are going to make it to the official Git client builds? (specifically the Windows one) On 3 January 2018 at 14:28, Jeff King wrote: > On Wed, Jan 03, 2018 at 12:59:48PM -0800, Isaac

Re: Bug report: git clone with dest

On Wed, Jan 03, 2018 at 12:59:48PM -0800, Isaac Shabtay wrote: > Target directory is deleted on clone failures. > > Steps to reproduce, for example on Windows: > > cd /d %TEMP% > mkdir dest > git clone https://some-fake-url/whatever-makes-git-clone-fail dest > > Of course, the clone will fail

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

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 > > > ** Summary >

Re: Bug report

On Wed, Aug 30, 2017 at 11:25:00PM +0200, Aleksandar Pavic wrote: > I have a file > > app/Controller/CustomerCardVerificationController.php > > And when I take a look at changes log, I get this (no matter which tool I > use): > > 2017-07-31 19:41 dule o membership renew payment

Re: Bug report

On 08/31/2017 08:36 AM, Kevin Daudt wrote: > On Wed, Aug 30, 2017 at 11:25:00PM +0200, Aleksandar Pavic wrote: >> I have a file >> >> app/Controller/CustomerCardVerificationController.php >> >> And when I take a look at changes log, I get this (no matter which tool I >> use): >> >> 2017-07-31

Re: Bug report

Hm, thanks, but the link was not helpful, there are no merge commits to master branch. Those changes should have not been undone, that's how we caught it, because 1 line peace of code introduced new feature (+-10% tolerance on credit card verification amount). So most likeley they were

Re: Bug report

The following answer that I got back in 2015 from Jeff King might be relevant to your problem: https://marc.info/?l=git=144178948506788=2 Regards, Dov On Thu, Aug 31, 2017 at 9:36 AM, Kevin Daudt wrote: > On Wed, Aug 30, 2017 at 11:25:00PM +0200, Aleksandar Pavic wrote: >> I

Re: Bug report

On Wed, Aug 30, 2017 at 11:25:00PM +0200, Aleksandar Pavic wrote: > I have a file > > app/Controller/CustomerCardVerificationController.php > > And when I take a look at changes log, I get this (no matter which tool I > use): > > 2017-07-31 19:41 dule o membership renew payment

Re: Bug Report - Segmentation Fault on "git add --all"

On 20 July 2017 at 02:54, Tillson Galloway wrote: > Context: > We currently have a git project with a root directory ("~/project") > for pipelines and deployment of a Node app, and then a subdirectory > ("~/project/project-app"). > After realizing that we didn't need

Re: bug report: dates on diff

Junio C Hamano writes: > Imagine this scenario: > > - Contributor A writes a change on 2017-07-01 and send it in to me > - Contributor B writes a change on 2017-07-03 and send it in to me > - I apply change from B on 2017-07-04 on 'master' > - I apply change from A on

Re: bug report: dates on diff

Todd Lewis writes: > Trying not to sound snide, but, what's the point of "--date=" on commits if > you > can't use it later? Granted, things always seem harder until you understand > how > the work. Thanks again. You do not sound snide at all, at least to me ;-) Imagine

Re: bug report: dates on diff

On 07/06/2017 12:22 PM, Junio C Hamano wrote: > If you didn't create this repository back in 2012, then the syntax > "master@{01-01-2012}" that asks "Back at the beginning of 2012, what > object did the master branch point at?" does not have a sensible > answer. That can be seen in the warning

Re: bug report: dates on diff

Todd Lewis writes: > [utoddl@tarna gitbug]$ git diff master@{01-01-2012} charter.txt > warning: Log for 'master' only goes back to Thu, 6 Jul 2017 08:19:45 -0400. What you observed is how @{} syntax is designed to work, and is not limited to "git diff". Any Git command

Re: Bug report: Corrupt pack file after committing a large file (>4 GB?)

On 2017-05-26 07:51, Yu-Hsuan Chen wrote: > Dear maintainer, > > There is a bug where committing a large file corrupts the pack file in > Windows. Steps to recreate are: > > 1. git init > 2. stage and commit a file larger than 4 GB (not entirely sure about this > size) > 3. git checkout -f > >

Re: Bug report: Corrupt pack file after committing a large file (>4 GB?)

On Fri, May 26, 2017 at 01:51:34PM +0800, Yu-Hsuan Chen wrote: > There is a bug where committing a large file corrupts the pack file in > Windows. Steps to recreate are: > > 1. git init > 2. stage and commit a file larger than 4 GB (not entirely sure about this > size) > 3. git checkout -f > >

Re: Bug report: Git Stash; spelling mistake of stash followed by a yes prints character 'y' infinite times.

On Wed, 2017-05-03 at 14:51 +0530, Rashmi Pai wrote: > I am a corporate user of git. I noticed that when you switch between > the branches and do a git stash ( I miss spelled it as git stahs). Git > asked if i meant git stash. and i entered yes. and git printed the > character y infinite times.

Re: Bug report: Git Stash; spelling mistake of stash followed by a yes prints character 'y' infinite times.

Jeff King writes: >> 4. Now git says git: 'stahs' is not a git command. See 'git --help'. >> >> Did you mean this? >> >> stash > > After this step git exits, and you're back at your shell prompt... Perhaps the suggestion message should be rephrased not to sound like it is

Re: Bug report: Git Stash; spelling mistake of stash followed by a yes prints character 'y' infinite times.

On Wed, May 03, 2017 at 03:16:06PM +0530, Rashmi Pai wrote: > Below are the steps to reproduce. > 1. create a local branch and make some code changes in the same branch. > 2. now checkout another branch. git says Your local changes to the > following files would be overwritten by checkout. > 3.

Re: Bug Report: .gitignore behavior is not matching in git clean and git status

Samuel Lijin writes: > After some more digging (and familiarizing myself with the > behind-the-scenes logic) the issue is that dir.c has this implicit > assumption that a directory which contains only untracked and ignored > files should itself be considered untracked. While

Re: Bug Report: .gitignore behavior is not matching in git clean and git status

After some more digging (and familiarizing myself with the behind-the-scenes logic) the issue is that dir.c has this implicit assumption that a directory which contains only untracked and ignored files should itself be considered untracked. While that works fine for use cases where we're asking if

Re: Bug Report: .gitignore behavior is not matching in git clean and git status

On Sun, Apr 30, 2017 at 8:56 PM, Chris Johnson wrote: > Good assessment/understanding of the issue. git clean -n does not > report anything as being targeted for removal, and git clean -f > matches that behavior. I agree with it probably being related > specifically to

  1   2   3   >