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

[BUG REPORT] Git does not correctly replay bisect log

Executing git bisect replay reaches a different commit than the one that is obtained by running the commands from the bisect log manually. Distribution: Arch Linux git: 2.19.2-1 perl: 5.28.1-1 pcre2: 10.32-1 expat: 2.2.6-1 perl-error: 0.17027-1 grep: 3.1-2 bash: 4.4.023-1 no system

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

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

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 copying a directory across sibling directories

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

[bug report] git-gui child windows are blank

v2.19.2, installed from brew on macOS Mojave 14.2.1. `git-gui` is my much beloved go-to tool for everything git. Unfortunately, on my new Macbook Air it seems to have a bug. When I first load the program, the parent window populates normally with the stage/unstaged and diff panes. However, when I

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

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

git clone of non-existent repository results in request for credentials REPRODUCING: sudo apt install git git clone https://github.com/xorbit/LiFePo4owered-Pi.git#this repo does not exist Git will then prompt for username and password on Github. I can see a valid data-leak concern (one

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

[Bug report] Git incorrectly selects language in macos

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 git is translated to, as a secondary language, for

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

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

Hi, this question was originally posted on the Google Groups list, trying to get help (https://groups.google.com/d/topic/git-users/QAFKOQU4eUo/discussion). Now that it's confirmed as a bug and I have a proposed solution, I'm posting here. Gitk "find commit" search function doesn't follow

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

Bug report for git push

Hi everyone! I am facing this spurious issue (not easily reproducible and usually a retry fixes it) with git push: Warning: Permanently added 'github.com,192.30.255.112' (RSA) to the list of known hosts. Counting objects: 8, done. Delta compression using up to 2 threads. Compressing objects:

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

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

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 "\141\314\210") >"$auml" echo "auml: " $(echo

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

Bug Report - Pull remote branch does not retrieve new tags

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 * branchmaster -> FETCH_HEAD Already up-to-date. If I instead do a "git pull" I get: From

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

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

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

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

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

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

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

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

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

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

ized value $_ in print at /usr/lib/git-core/git-add--interactive line 1371, line 75. Use of uninitialized value $_ in print at /usr/lib/git-core/git-add--interactive line 1371, line 75. I hope that this bug report can help the git core maintainers to either fix the problem upstream, or to co-ordi

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

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

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

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

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

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

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: Possible bug report: git checkout tag problem

Hi Myles, On Mon, 8 Jan 2018, Myles Fong wrote: > Brief description: > When two tags are pointing to the same commit, e.g. tagA and tagB, if I > do `git checkout tagA` then `git checkout tagB`, and then `git status`, > it shows `HEAD detached at tagA` > > Expected behaviour: > I'm expecting it

Possible bug report: git checkout tag problem

Hi, Brief description: When two tags are pointing to the same commit, e.g. tagA and tagB, if I do `git checkout tagA` then `git checkout tagB`, and then `git status`, it shows `HEAD detached at tagA` Expected behaviour: I'm expecting it to show `HEAD detached at tagB`, though I understand

Bug Report: Subtrees and GPG Signed Commits

Hi all, I've noticed an issue regarding the use of `git subtree add` and `git subtree pull` when the subtree repository's commit (either HEAD or whatever commit specified by the subtree command) is signed with GPG. It seems to work properly if the commit is not signed but previous commits are.

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

  1   2   3   4   5   >