Hi,
I would like to report what I suspect is a bug in `git rebase -i`.
The problem in question is that when a `rebase -i` is run on a repo
which has had a subtree added with `git subtree add --prefix=xxx`
previously; the later command will be executed without the `--prefix`
argument, resulting in
Jeff King writes:
> ...
> --commit-filter '
> commit=$(git commit-tree "$@")
> git notes copy $GIT_COMMIT $commit
> echo $commit
> '
Thanks. I was writing the same "git notes copy $this $that" based
response, but TIL we had --stdin to fe
On Thu, Aug 22, 2019 at 04:44:37PM -0400, Christopher Sean Morrison wrote:
> We’re migrating a very large old repository to Git (the oldest in
> continuous development!) and using the notes feature to preserve Svn
> data like revision IDs and branch information. We’ve run into what
> seems like a
Hi,
We’re migrating a very large old repository to Git (the oldest in continuous
development!) and using the notes feature to preserve Svn data like revision
IDs and branch information. We’ve run into what seems like an incomplete
feature or bug in that notes get orphaned/disassociated if an o
Hi git developers,
Apologies in advance if my mailing list etiquette isn't 100% perfect. I
don't use mailing lists all that often. Please CC me in replies, because
I am not subscribed.
I use `git-ls-files` in a project[1] to get a list of ignored
files/directories, and to ignore them in my projec
user$ git checkout -b "environment-logging"
Switched to a new branch ' environment-logging'
user$ git status
On branch environment-logging
nothing to commit, working tree clean
user$ git checkout develop
Switched to branch 'develop'
Your branch is up to date with 'origin/develop'.
user$ git branch
On Thu, Apr 11, 2019 at 03:16:22PM -0400, Can Gemicioglu wrote:
> I noticed a problem when trying to apply a patch file that contained
> many separate patches in a single file.
To quote the first line of its manpage :) 'git apply' is meant to
"Apply a patch to files and/or to the index". Note the
Hi,
I noticed a problem when trying to apply a patch file that contained many
separate patches in a single file. Trying to apply this patch gave me a "No
such file or directory" error for one of the files in the middle and after
looking around I realised this file was also created earlier in th
On 15-02-19, 08:09, Elijah Newren wrote:
> Hi Viresh,
>
> On Thu, Feb 14, 2019 at 10:40 PM Viresh Kumar wrote:
> >
> > On 14-02-19, 13:23, Elijah Newren wrote:
> > > I think you're getting tripped up by double-dot vs triple-dot with
> > > diff being different than log:
> > >
> > > `git diff D..E`
Philip Oakley writes:
> It was my understanding that the end point would be total removal of
> any options and the typing of the double dot would be an error. Given
> that hard end point I was looking to ensure that users of double dots
> have a manageable route to unlearning old bad habits. Thus
Hi Junio,
On 17/02/2019 03:34, Junio C Hamano wrote:
Philip Oakley writes:
Those who do *not* opt into that "early warning" configuration dance
would eventually be warned whenever they type "diff A..B", and the
timing for that eventuality is not under their control, so quite
honestly, I do no
Philip Oakley writes:
>> Those who do *not* opt into that "early warning" configuration dance
>> would eventually be warned whenever they type "diff A..B", and the
>> timing for that eventuality is not under their control, so quite
>> honestly, I do not see much point in "giving users the chance"
On 15/02/2019 23:32, Junio C Hamano wrote:
Philip Oakley writes:
On 15/02/2019 20:12, Junio C Hamano wrote:
Historically, it was a mistake to allow A..B to be used for two
endpoints, which was made back when we haven't thought things
through. That is why I stopped "warn to deprecate and then
Philip Oakley writes:
> On 15/02/2019 20:12, Junio C Hamano wrote:
>>
>> Historically, it was a mistake to allow A..B to be used for two
>> endpoints, which was made back when we haven't thought things
>> through. That is why I stopped "warn to deprecate and then
>> completely remove", as I do n
On 15/02/2019 20:12, Junio C Hamano wrote:
Elijah Newren writes:
Instead of outright deprecating it, would it make sense to include a
configuration option, say "diff.sensibleDots", that would enable a user
to set the dots to the other form if they desire?
I think Junio's suggested steps would
On Thu, Feb 14, 2019 at 02:10:53PM -0800, Junio C Hamano wrote:
> Elijah Newren writes:
>
> > The only thing I seem to be able to retain is the following: "git
> > diff D..E is totally useless and should be an error because (1) it
> > doesn't do what I expect and (2) for folks that want the beha
Elijah Newren writes:
>> Instead of outright deprecating it, would it make sense to include a
>> configuration option, say "diff.sensibleDots", that would enable a user
>> to set the dots to the other form if they desire?
>
> I think Junio's suggested steps would still have to come first, and
> t
Denton Liu writes:
> On Thu, Feb 14, 2019 at 02:10:53PM -0800, Junio C Hamano wrote:
>
>> It might be _possible_ to spend a year (i.e. 4 cycles) to start
>> warning when two-dot notation is used for "git diff" (only, not any
>> plumbing like "git diff-files") and tell the user to use the more
>>
On Fri, Feb 15, 2019 at 10:52 AM Denton Liu wrote:
>
> On Thu, Feb 14, 2019 at 02:10:53PM -0800, Junio C Hamano wrote:
> > Elijah Newren writes:
> >
> > > The only thing I seem to be able to retain is the following: "git
> > > diff D..E is totally useless and should be an error because (1) it
>
Hi Viresh,
On Thu, Feb 14, 2019 at 10:40 PM Viresh Kumar wrote:
>
> On 14-02-19, 13:23, Elijah Newren wrote:
> > I think you're getting tripped up by double-dot vs triple-dot with
> > diff being different than log:
> >
> > `git diff D..E` means the same thing as `git diff D E`, i.e. diff the
> >
On 14-02-19, 13:23, Elijah Newren wrote:
> I think you're getting tripped up by double-dot vs triple-dot with
> diff being different than log:
>
> `git diff D..E` means the same thing as `git diff D E`, i.e. diff the
> two commits D and E.
Right, so both the branches have at least until rc2 (thou
Elijah Newren writes:
> The only thing I seem to be able to retain is the following: "git
> diff D..E is totally useless and should be an error because (1) it
> doesn't do what I expect and (2) for folks that want the behavior
> currently gotten with that syntax can instead just use a space inst
Hi,
On Thu, Feb 14, 2019 at 11:35 AM Viresh Kumar wrote:
>
> Hello,
>
> I am not sure if it is a bug or not, but the output I got wasn't what
> I was looking for. And so looking for some help. I was looking to send
> pull request [1] to PM maintainer and was generating the request
> against his t
Am 14.02.19 um 09:22 schrieb Viresh Kumar:
> Hello,
>
> I am not sure if it is a bug or not, but the output I got wasn't what
> I was looking for. And so looking for some help. I was looking to send
> pull request [1] to PM maintainer and was generating the request
> against his tree [2], which al
Hello,
I am not sure if it is a bug or not, but the output I got wasn't what
I was looking for. And so looking for some help. I was looking to send
pull request [1] to PM maintainer and was generating the request
against his tree [2], which already has kernel upto v5.0-rc6 merged in
it.
These are
t can actually do something about this.
Please let me know whether I should report this at vimdiff.
My environment is:
Fedora 29
vim-enhanced-8.1.847-2.fc29.x86_64
git-core-2.20.1-1.fc29.x86_64
Related bug report: https://github.com/rebase-helper/rebase-helper/issues/564
Nate Weaver wrote:
> Upon further digging, this is an issue in gettext's code on macOS:
> The function _nl_language_preferences_default (in langprefs.c) specifically
> breaks early when it sees the literal string "en" in the list (from the
> "AppleLanguages" defaults key), but not when it gets "en
Nate Weaver wrote:
>>> 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
good to know that this is fixed
at the correct location upstream.
I tried updating the Homebrew bug report[1] regarding this problem
with respect to Git in order to add the new information you provided,
but the ticket has been "locked" so no additional comments can be made
there
--Nate Weaver (Wevah)
> On Jan 15, 2019, at 10:43:48, Nate Weaver wrote:
>
>> On Jan 15, 2019, at 09:35:52, Nate Weaver wrote:
>>
>>> On Sep 16, 2018, at 02:15:33, Eric Sunshine wrote:
>>>
>>> On Fri, Sep 14, 2018 at 10:20 PM Niko Dzhus wrote:
Looks like the issue appeared after upda
> On Jan 15, 2019, at 09:35:52, Nate Weaver wrote:
>
>> On Sep 16, 2018, at 02:15:33, Eric Sunshine wrote:
>>
>> 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 g
> On Sep 16, 2018, at 02:15:33, Eric Sunshine wrote:
>
> 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 defau
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, $GIT_DIR/BISECT_ANCES
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 commit
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
> wh
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 actua
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 snippe
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
> > 94710cac0ef4ee177a63b5227664b38c95b
(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: 0.
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
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 mus
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 /etc/gitconfig
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, ins
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.
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
cop
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 (se
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 n
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
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
>>
>> REP
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 pa
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 coul
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
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 i18n
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
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 gi
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 example,
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 reprod
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 the
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 pushi
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: 10
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):
>>
>> diff --git a/
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 is faster of cour
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 for taking a look.
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 "\141\31
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 -n
o way to replicate that on an existing repo
without 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 Du
rosoft/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
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
>* branchmaster -> FETCH_HEAD
>
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 git.internal.c
l.com] On Behalf Of Junio C Hamano
Sent: Wednesday, March 07, 2018 23:03
To: Vromen, Tomer
Cc: git@vger.kernel.org
Subject: Re: Bug report: git-stash doesn't return correct status code
Junio C Hamano writes:
> "Vromen, Tomer" writes:
>
>>> git stash && git c
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, I might have forgotten to save my changes in
"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 editor, so
> git-stash will
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
wi
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 going to assume th
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 input (e.g. prose) than the
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, especially where
> mu
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 that there's a 1:1
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 algorithm.
The loss of line-end
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 is pretty much hopeless/useless in t
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 would be a good ad
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 are
sprinkled th
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 point you to it.
I
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 in a situation wh
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 = run_cmd_pipe(@display_cmd);
> > ...
>
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++) {
> ...
> push @{$hunk[-1
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 |
>
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 in
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 answere
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
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 Linux/macOS.
> > Raining Cha
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
>> changed."
>>
>> This cause
+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 (Typ
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
call
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 --no-show-signature in the o
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
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 message
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 h
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 c
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 () {
>
> toptree_for_commit () {
>
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 Hamano wrote:
Stefan Beller writes:
> There has not been fe
1 - 100 of 479 matches
Mail list logo
