Hi Eugen,
On Thu, 12 Sep 2019, Eugen Konkov wrote:
> $ git --version
> git version 2.20.1
First thing to try is whether Git v2.23.0 still exposes that bug.
Ciao,
Johannes
Hi Mike
On 29/08/2019 00:25, Mike Hommey wrote:
Hi,
This just happened to me while cherry-pick'ing:
$ git cherry-pick HEAD@{1}
error: could not apply 614fe5e629b84... try
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add ' or 'git rm '
hint: and commit the resul
Thanks Jeff
You are completely right! It works as I expect if I remember the extra
parameter `--recursive` when doing `git submodule update --init
--recursive`
Thanks a lot for your feedback! This is really useful! I learned a
useful thing today :)
/Jesper
On Thu, Mar 7, 2019 at 7:08 PM Jeff Ki
On Thu, Mar 07, 2019 at 12:07:21PM +0100, Jesper Rønn-Jensen wrote:
> Hi I think I may have found an error in the way git handles a
> submodule's submodule. Read further for the example (extracted from a
> real project).
First off, thank you for the example script. It made understanding
what's go
oper
DDI 021 469 888 / and...@terabyte.co.nz
/TERABYTE
-Original Message-
From: Ævar Arnfjörð Bjarmason
Sent: Thursday, 20 December 2018 8:00 AM
To: Andrew Shearer
Cc: git@vger.kernel.org; Eric Wong
Subject: Re: error: Use of uninitialized value $hash in chomp
On Wed, Dec 19 2018,
DI 021 469 888 / and...@terabyte.co.nz
/TERABYTE
-Original Message-
From: Ævar Arnfjörð Bjarmason
Sent: Thursday, 20 December 2018 8:00 AM
To: Andrew Shearer
Cc: git@vger.kernel.org; Eric Wong
Subject: Re: error: Use of uninitialized value $hash in chomp
On Wed, Dec 19 2018,
On Wed, Dec 19 2018, Andrew Shearer wrote:
> Hello
>
> I am using a "git svn clone" command to extract our project history from svn
> into git.
> About 30m into the process it fails with:
>
> r50739 = 2a1491de1353b1e3cce50d8f9d383407218a44f1 (refs/remotes/git-svn)
> fatal: Cannot open '.git/Git
Basin Ilya writes:
> Hi.
>
> I'm trying to make the Cygwin Git understand Mingw-style repo urls:
>
> git config --global \
> file:///cygdrive/c.insteadOf \
> file:///C:
>
> But this fails with:
>
> error: invalid key: file:///cygdrive/c.insteadOf
Understandable.
> Manually e
On 18.05.2018 19:14, Martin Ågren wrote:
On 18 May 2018 at 17:43, Robert P. J. Day wrote:
...
Ah, this is about saving to the stash vs stashing away. The latter is
what `git stash` is all about -- stashing changes *away*. At least
according to my mental model and the top of the man-page.
S
On Fri, 18 May 2018, Sybille Peters wrote:
> My 2c on this:
>
> 1) "If the --keep-index option is used, all changes already added to
>the index are left intact" (manpage git stash)
>
> That appears to be correct and clear
>
>
> 2) "$ git stash push --keep-index # save *all other* changes to th
On 18 May 2018 at 17:43, Robert P. J. Day wrote:
> On Fri, 18 May 2018, Sybille Peters wrote:
>
>> My 2c on this:
>>
>> 1) "If the --keep-index option is used, all changes already added to
>>the index are left intact" (manpage git stash)
>>
>> That appears to be correct and clear
>
> yup, th
On Fri, 18 May 2018, Sybille Peters wrote:
> My 2c on this:
>
> 1) "If the --keep-index option is used, all changes already added to
>the index are left intact" (manpage git stash)
>
> That appears to be correct and clear
yup, that's not the issue.
> 2) "$ git stash push --keep-index # sav
My 2c on this:
1) "If the --keep-index option is used, all changes already added to the
index are left intact" (manpage git stash)
That appears to be correct and clear
2) "$ git stash push --keep-index # save *all other* changes to the
stash" (manpage git stash)
That is either not corr
On 18 May 2018 at 12:51, Robert P. J. Day wrote:
> On Fri, 18 May 2018, Martin Ågren wrote:
>
>> On 18 May 2018 at 11:37, Robert P. J. Day wrote:
>> >
>> > toward the bottom of "man git-stash", one reads part of an example:
>> >
>> > # ... hack hack hack ...
>> > $ git add --patch foo
On Fri, 18 May 2018, Martin Ågren wrote:
> On 18 May 2018 at 11:37, Robert P. J. Day wrote:
> >
> > toward the bottom of "man git-stash", one reads part of an example:
> >
> > # ... hack hack hack ...
> > $ git add --patch foo# add just first part to the index
> > $ git stash
On 18 May 2018 at 11:37, Robert P. J. Day wrote:
>
> toward the bottom of "man git-stash", one reads part of an example:
>
> # ... hack hack hack ...
> $ git add --patch foo# add just first part to the index
> $ git stash push --keep-index# save all other changes to the sta
On 08/03/18 13:17, SZEDER Gábor wrote:
Just to let you know, I get the following error compiling Git in master
branch:
$ make prefix=/usr NO_GETTEXT=YesPlease all doc info
...
GEN git-remote-testgit
GEN perl/build/man/man3/Git.3pm
Can't write-open perl/build/man/man3/Git.3pm: Permiss
> Just to let you know, I get the following error compiling Git in master
> branch:
>
> $ make prefix=/usr NO_GETTEXT=YesPlease all doc info
> ...
> GEN git-remote-testgit
> GEN perl/build/man/man3/Git.3pm
> Can't write-open perl/build/man/man3/Git.3pm: Permission denied at
> /usr/bin/p
On Sat, Feb 3, 2018 at 4:17 AM, Brian Buchalter wrote:
> I am attempting to repair a git repo which has an illegal byte
> sequence but am not sure how to proceed. Steps to reproduce: `git
> clone https://github.com/christopherpow/nes-test-roms.git` results in:
>
> ```
> Cloning into 'nes-test-roms
On Friday 22 December 2017 05:19 PM, Johannes Schindelin wrote:
Hi Kaartic,
I think I didn't mention I've set `commit.gpgsign` to `true` for that
repo, did I?
Hah! I had troubles to associate the correct line in my versions of Git's
source code (the line numbers alone are only reliable if yo
Hi Kaartic,
On Thu, 21 Dec 2017, Kaartic Sivaraam wrote:
> Speaking of trace, (thanks to Dscho!) the one I got using 'valgrind'
> (with `--leak-check=full` option) can be found below. I've kept only
> relevant parts of it to avoid unwanted noise of `set -x`. Let me know
> if that's needed too.
>
>Original Message
>From: kaartic.sivar...@gmail.com
>Date: 21/12/2017 17:14
>To: "phillip.w...@talktalk.net", "Phillip
Wood", "Git Mailing List"
>Cc: "Johannes Schindelin"
>Subj: Re: Error in `git': free(): invalid pointer
On Thu, 2017-12-21 at 16:53 +, phillip.w...@talktalk.net wrote:
> Hm, There is a problem with sequencer_remove_state() which does
>
> free(opts->gpg_sign)
>
> however unless a gpg key was given on the commandline, opts->gpg is
> initialized to "" which is statically allocated.
>
> This un
>Original Message
>From: kaartic.sivar...@gmail.com
>Date: 20/12/2017 18:33
>To: "Phillip Wood", "Git Mailing List"
>Cc: "Johannes Schindelin"
>Subj: Error in `git': free(): invalid pointer (was Re: [PATCH]
sequencer: improve config handling)
>
>I recently encountered that error when t
On Thu, 2017-12-21 at 15:06 +0100, Johannes Schindelin wrote:
> Hi Kaartic,
> I fear that the strace does not cover the `git-rebase` process nor the
> `git-rebase--helper` process (which must have been part of your run, as
> the commit affected only that part of the rebase operation).
>
Yep. It s
On Thursday 21 December 2017 02:09 AM, phillip.w...@talktalk.net wrote:
>
>
> Hi Kaartic
>
> I'm replying off list as I've only got access to webmail at the
> moment.
No issues brought the CCs including the list to ensure we don't miss things.
> Are you able to do a backtrace
Hi Kaartic,
On Thu, 21 Dec 2017, Kaartic Sivaraam wrote:
> I recently encountered that error when trying to do an interactive
> rebase after using filter-branch to remove a file completely in a
> repository. I bisected this issue which pointed at this patch. I'm not
> sure how it is related as I'
On Sat, Aug 12, 2017 at 04:22:08PM +0300, KES wrote:
> Hi.
>
> When I use `git pull -v --rebase` command under user I got this error:
>
> POST git-upload-pack (947 bytes)
> POST git-upload-pack (452 bytes)
> remote: warning: unable to access '/root/.config/git/attributes': Permission
> denied
>
Am 29.05.2017 um 13:20 schrieb Mathias Artus:
Hi,
Today i've tried to set up a template directory. I added in the system wide
gitconfig the following lines:
[init]
templatedir = "//OurServer/SomeDirectory/GitTemplate"
Where //Ourserver is a Network Path.
With th
I tried `git config mergetool.meld.hasOutput true` followed again by
`git mergetool --tool=meld` and got the same error.
My original message:
When using `git mergetool --tool=kdiff3`, it works fine. But
with `git mergetool --tool=meld` I get this for every merge conflict:
`
Can you try `git config mergetool.meld.hasOutput true` and see if that
fixes the issue?
Hi,
On Mon, 2 Jan 2017, M. Abuhena Sobuj wrote:
> My Git Bash was perfect but suddenly It stooped work for me.
>
> I just got message
> "Error: could not fork child process: Resource temporarily unavailable (-1).
> DLL rebasing may be required. See 'rebaseall / rebase --help'."
Is this a 32-bit
On Mon, Dec 05, 2016 at 11:56:31AM +0100, Johannes Schindelin wrote:
> Hi Peter,
>
> On Mon, 5 Dec 2016, P. Duijst wrote:
>
> > On 12/5/2016 06:15, David Aguilar wrote:
> > > On Fri, Dec 02, 2016 at 05:05:06PM +0100, Johannes Schindelin wrote:
> > > >
> > > > On Fri, 2 Dec 2016, P. Duijst wrote:
Hi Peter,
On Mon, 5 Dec 2016, P. Duijst wrote:
> On 12/5/2016 06:15, David Aguilar wrote:
> > On Fri, Dec 02, 2016 at 05:05:06PM +0100, Johannes Schindelin wrote:
> > >
> > > On Fri, 2 Dec 2016, P. Duijst wrote:
> > >
> > > > Incase filenames are used with a quote ' or a bracket [ (and
> > > > m
On 12/5/2016 06:15, David Aguilar wrote:
On Fri, Dec 02, 2016 at 05:05:06PM +0100, Johannes Schindelin wrote:
Hi Peter,
On Fri, 2 Dec 2016, P. Duijst wrote:
Incase filenames are used with a quote ' or a bracket [ (and maybe some more
characters), git "diff" and "difftool -y" works fine, but
On Fri, Dec 02, 2016 at 05:05:06PM +0100, Johannes Schindelin wrote:
> Hi Peter,
>
> On Fri, 2 Dec 2016, P. Duijst wrote:
>
> > Incase filenames are used with a quote ' or a bracket [ (and maybe some
> > more
> > characters), git "diff" and "difftool -y" works fine, but git *difftool
> > **-d*
Hi Peter,
On Fri, 2 Dec 2016, P. Duijst wrote:
> Incase filenames are used with a quote ' or a bracket [ (and maybe some more
> characters), git "diff" and "difftool -y" works fine, but git *difftool **-d*
> gives the next error message:
>
>peter@scm_ws_10 MINGW64 /d/Dev/test (master)
>
[re-adding git@vger to the cc; please keep conversations on the list so
everybody can benefit from the answers]
On Tue, Oct 04, 2016 at 01:13:16PM -0300, Luciano Schillagi wrote:
> I ran the command
>
> Luko ~ $ git config --global --unset push.default
>
>
> and it gives me the following
>
>
On Thu, Sep 22, 2016 at 08:02:35PM -0300, Luciano Schillagi wrote:
> please, what should I do to fix this error? thanks
>
> Luko ~ $ git init
> error: malformed value for push.default: aguas
> error: Must be one of nothing, matching, simple, upstream or current.
> fatal: bad config variable 'push
Fabrizio Cucci venit, vidit, dixit 28.05.2016 19:54:
> Hello everyone,
>
> I'm trying to understand why I'm getting the error as per subject.
>
> The scenario is the following: I'm on the master branch (which
> contains several commits) and I would like to create a new empty
> branch (let's call
I'm digging this topic up from the ground because if it was fixed, I
would not have spent many confusing (and a little bit panicking)
minutes wondering how the hell I managed to push to "origin/master"
which I did not have push access to begin with, which turned out to be
the local branch, refs/hea
Is apparently a known issue.
Here is a temp fix : https://github.com/git-for-windows/git/issues/376
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Adrian,
please note that Renato never got your mail (you should always use
reply-to-all). I re-Cc:ed him, please do not forget to reply-to-all next time.
On 2015-09-11 23:33, Adrian Ang wrote:
> Renato Akaboci gmail.com> writes:
>>
>> I´m in trouble just after installation of my Git for Wind
Renato Akaboci gmail.com> writes:
>
> Hi,
>
> I´m in trouble just after installation of my Git for Windows.
> I get a box with error saying:
>
> couldn´t read file "C:\Program
> Files\Git\cmd\mingw64\libexec\git-core\git-gui": no such file or
> directory
>
> I´ve just installed git as normal.
I'm having the same problem. In fact, my post was right in front of yours.
Another thing I notice is that Git commands are not listed in Windows Explorer.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info a
Thanks for the detailed explanation Eric! That really helped clear my
doubts. Also tried with "0x" and it's working fine however, as
suggested by you, i will use '='
Thanks again! :)
On Tue, Aug 11, 2015 at 4:17 AM, Eric Sunshine wrote:
> On Mon, Aug 10, 2015 at 6:29 PM, Jacob Keller wrote:
>>
On Mon, Aug 10, 2015 at 6:29 PM, Jacob Keller wrote:
> On Mon, Aug 10, 2015 at 2:54 AM, Gaurav Chhabra
> wrote:
>> Apologies for the delay in reply! I tried your suggestion and it
>> works. Thanks! :)
>>
>> I'm curious why integer comparison is throwing error. Shouldn't i be
>> comparing numbers
On Mon, Aug 10, 2015 at 2:54 AM, Gaurav Chhabra
wrote:
> Apologies for the delay in reply! I tried your suggestion and it
> works. Thanks! :)
>
> I'm curious why integer comparison is throwing error. Shouldn't i be
> comparing numbers with numeric operator?
>
Yes, but shell doesn't treat hex numb
Torsten Bögershausen writes:
> So I think that git clone can be slighty more consistant here.
Sure.
>> I _think_ taking notice of "word://" (with doubled slashes) and
>> treating it specially will not introduce any new issue; while it is
>> still OK for users to have a local directory called "w
Apologies for the delay in reply! I tried your suggestion and it
works. Thanks! :)
I'm curious why integer comparison is throwing error. Shouldn't i be
comparing numbers with numeric operator?
On Mon, Aug 10, 2015 at 3:23 PM, Gaurav Chhabra
wrote:
> Apologies for the delay in reply! I tried your
On 2015-08-06 09.50, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Torsten Bögershausen writes:
>>
>>> It looks as if
>>> static char *get_repo_path(const char *repo, int *is_bundle)
>>> in built/clone.c
>>> checks if there is a local directory structure looking like a
>>> .git directory.
Junio C Hamano writes:
> Torsten Bögershausen writes:
>
>> It looks as if
>> static char *get_repo_path(const char *repo, int *is_bundle)
>> in built/clone.c
>> checks if there is a local directory structure looking like a
>> .git directory.
>> This is wrong.
>
> It is as designed, though, to al
Torsten Bögershausen writes:
> It looks as if
> static char *get_repo_path(const char *repo, int *is_bundle)
> in built/clone.c
> checks if there is a local directory structure looking like a
> .git directory.
> This is wrong.
It is as designed, though, to allow cloning from a local directory
wi
On 2015-08-06 06.21, Chris Packham wrote:
> Hi All,
>
> A developer at $dayjob called me over to have a look at a git error he
> was getting (names changed to protect the innocent).
>
> $ git --version
> git version 2.5.0
> $ git clone ssh://example.com/repo.git
> Cloning into 'repo'...
>
On Wed, Aug 5, 2015 at 1:32 PM, Gaurav Chhabra wrote:
> I had written the following code to check whether a push is for branch
> deletion:
>
> #!/bin/bash
>
> NULL=""
> if [[ "$new_sha" -eq "$NULL" ]]; then # Line 17
> remote: Stdin: [
On Fri, Dec 05, 2014 at 04:55:51PM +0100, Torsten B?gershausen wrote:
> On 12/05/2014 09:10 AM, Torsten B?gershausen wrote:
> Or a test case showing the problem is welcome too.
I mentioned some examples in my previous post. Here they are in
condensed form. They assume core.eol isn't set in your gl
On 12/05/2014 09:10 AM, Torsten Bögershausen wrote:
> On 05.12.14 06:42, Alex Stangl wrote:
>> Hi,
>>
>> There seems to be problems with the checks in the git code for conflicts
>> between config values of core.autocrlf and core.eol. Because the various
>> config files are read in separate passes,
On Tue, Aug 12, 2014 at 12:11 PM, Dennis Kaarsemaker
wrote:
> On ma, 2014-08-11 at 18:56 -0400, Luke Campagnola wrote:
>>
>> raven:/home/luke/vispy (transform-cache)$ git checkout master
>> Switched to branch 'master'
>> Deleted 103 .pyc files
>> Deleted 11 empty directories
>
> This looks like yo
On ma, 2014-08-11 at 18:56 -0400, Luke Campagnola wrote:
>
> raven:/home/luke/vispy (transform-cache)$ git checkout master
> Switched to branch 'master'
> Deleted 103 .pyc files
> Deleted 11 empty directories
This looks like you have a local post-checkout hook that deletes empty
directories. Fix
On Tue, Aug 12, 2014 at 5:56 AM, Luke Campagnola
wrote:
> Greetings,
>
> I have been working happily with git for a couple of years, and ran
> into a mysterious issue today: after running a git-pull during which I
> saw the message "Auto packing the repository for optimum performance".
> I now rec
Am 28.07.2014 12:39, schrieb Duy Nguyen:
> I know wine is kind of second citizen but is there a cheap trick to
> make it work on wine? Reverting fcd428f (Win32: fix broken pipe
> detection - 2012-03-01) could result in conflicts in compat that I'm
> not comfortable resolving. I don't have Windows a
On 07/29/2014 03:05 PM, Duy Nguyen wrote:
> On Tue, Jul 29, 2014 at 7:20 PM, Michael Stefaniuc
> wrote:
>> On 07/29/2014 08:30 AM, Torsten Bögershausen wrote:
>>> On 07/28/2014 12:39 PM, Duy Nguyen wrote:
I know wine is kind of second citizen but is there a cheap trick to
make it work o
On Tue, Jul 29, 2014 at 7:20 PM, Michael Stefaniuc wrote:
> On 07/29/2014 08:30 AM, Torsten Bögershausen wrote:
>> On 07/28/2014 12:39 PM, Duy Nguyen wrote:
>>> I know wine is kind of second citizen but is there a cheap trick to
>>> make it work on wine? Reverting fcd428f (Win32: fix broken pipe
>
On 07/29/2014 08:30 AM, Torsten Bögershausen wrote:
> On 07/28/2014 12:39 PM, Duy Nguyen wrote:
>> I know wine is kind of second citizen but is there a cheap trick to
>> make it work on wine? Reverting fcd428f (Win32: fix broken pipe
>> detection - 2012-03-01) could result in conflicts in compat th
On 07/28/2014 12:39 PM, Duy Nguyen wrote:
I know wine is kind of second citizen but is there a cheap trick to
make it work on wine? Reverting fcd428f (Win32: fix broken pipe
detection - 2012-03-01) could result in conflicts in compat that I'm
not comfortable resolving. I don't have Windows at hom
On Wed, Jul 09, 2014 at 09:10:49AM +0200, Ralf Thielow wrote:
> I'm getting the following error when calling 'git status' on one of
> my projects.
>
> git: dir.c:739: last_exclude_matching_from_list: Assertion `x->baselen
> == 0 || x->base[x->baselen - 1] == '/'' failed.
> Aborted (core dumped)
>
al Message-
From: brian m. carlson [mailto:sand...@crustytoothpaste.net]
Sent: Wednesday, June 18, 2014 5:25 PM
To: Dodge, Warren L
Cc: git@vger.kernel.org
Subject: Re: Error 128 Clone succeeded, but checkout failed
On Thu, Jun 19, 2014 at 12:11:43AM +, Dodge, Warren L wrote:
> Hi Brian
On Thu, Jun 19, 2014 at 12:11:43AM +, Dodge, Warren L wrote:
> Hi Brian
Hi. Please do keep the list in CC. Someone else may be able to help
you better than I.
> c:\Program Files (x86)\Git\bin\git.exe" --version
> git version 1.9.4.msysgit.0
>
> I also had 1.8.?? and it did the same thing s
On Wed, Jun 18, 2014 at 04:03:40PM -0700, warren.l.do...@tektronix.com wrote:
> git.exe clone --progress -v L:\GIT_REPOSITORY L:\warrend\fail
>
> Cloning into L:\warrend\fail
> Done.
> Fatal: unable to read "Long hash key"
> Warning: clone succeeded, but checkout failed.
> You can inspect wh
William Giokas wrote:
> On Tue, May 13, 2014 at 03:24:51PM -0500, Felipe Contreras wrote:
> > William Giokas wrote:
> > > On Tue, May 13, 2014 at 02:09:55PM -0500, Felipe Contreras wrote:
> > > > As you say, it's perfectly OK.
> > >
> > > But wrong. Yes, it works, but it's not how it should be don
On Tue, May 13, 2014 at 03:24:51PM -0500, Felipe Contreras wrote:
> William Giokas wrote:
> > On Tue, May 13, 2014 at 02:09:55PM -0500, Felipe Contreras wrote:
> > > As you say, it's perfectly OK.
> >
> > But wrong. Yes, it works, but it's not how it should be done when we
> > have a code review s
William Giokas wrote:
> On Tue, May 13, 2014 at 02:09:55PM -0500, Felipe Contreras wrote:
> > William Giokas wrote:
> > > On Tue, May 13, 2014 at 10:30:26AM -0700, Junio C Hamano wrote:
> >
> > > > Why do we "import changegroup" unconditionally, even though it
> > > > is only used in the n
On Tue, May 13, 2014 at 02:09:55PM -0500, Felipe Contreras wrote:
> William Giokas wrote:
> > On Tue, May 13, 2014 at 10:30:26AM -0700, Junio C Hamano wrote:
>
> > > Why do we "import changegroup" unconditionally, even though it
> > > is only used in the new codepath meant only for version
William Giokas wrote:
> On Tue, May 13, 2014 at 10:30:26AM -0700, Junio C Hamano wrote:
> > Why do we "import changegroup" unconditionally, even though it
> > is only used in the new codepath meant only for version 3.0 or
> > higher, not inside the "if" block that decides if we need th
On Tue, May 13, 2014 at 10:30:26AM -0700, Junio C Hamano wrote:
> Torsten Bögershausen writes:
>
> > I did some testing with Git 2.0-rc3 + 58aee0864adeeb5363f.
> > The remote-helper tests for hg-git worked OK
> > with both hg version 2.9 and 3.0 under both Mac OS and Linux.
> >
> > Should we cons
Junio C Hamano wrote:
> It is time to catch regressions by asking wider audiences who do not
> normally follow Git development (i.e. those who are not the ones that
> follow 'master' and rebuild/install it once or twice a week for their
> daily use).
And you have one of those regressions in Git v
Torsten Bögershausen writes:
> I did some testing with Git 2.0-rc3 + 58aee0864adeeb5363f.
> The remote-helper tests for hg-git worked OK
> with both hg version 2.9 and 3.0 under both Mac OS and Linux.
>
> Should we consider 58aee086 to be included in Git 2.0 ?
It is way too late for Git 2.0, unl
(Please use reply-all and don't snip the important stuff)
On 2014-05-13 09.54, Charles Brossollet wrote:
> Le 12 mai 2014 à 21:37, Felipe Contreras a écrit
> :
>
>> Torsten Bögershausen wrote:
I'm using git 1.9.3 on Mac OS X 10.9.2, with hg 3.0 installed with brew.
It used to work
Le 12 mai 2014 à 21:37, Felipe Contreras a écrit :
> Torsten Bögershausen wrote:
>>> I'm using git 1.9.3 on Mac OS X 10.9.2, with hg 3.0 installed with brew.
>>>
>>> It used to work before, on this same repository, since then git and hg were
>>> both upgraded.
>> In short: The remote helper of
Torsten Bögershausen wrote:
> > I'm using git 1.9.3 on Mac OS X 10.9.2, with hg 3.0 installed with brew.
> >
> > It used to work before, on this same repository, since then git and hg were
> > both upgraded.
> In short: The remote helper of Git 1.9.3 is not compatible with hg 3.0
> You can eiher
> I'm using git 1.9.3 on Mac OS X 10.9.2, with hg 3.0 installed with brew.
>
> It used to work before, on this same repository, since then git and hg were
> both upgraded.
In short: The remote helper of Git 1.9.3 is not compatible with hg 3.0
You can eiher downgrade hg, or rebuild Git and cherry-
On Thu, 24 Apr 2014, Jeff King wrote:
Thanks, that's very helpful. I wasn't able to reproduce your problem
locally, but I suspect the curl patch below may fix it:
...
Daniel, I think the similar fix to curl_multi_cleanup in commit a900d45
missed this code path, and we need something like the
On Thu, Apr 24, 2014 at 12:15 AM, Jeff King wrote:
> I suspect the curl patch below may fix it:
>
> diff --git a/lib/multi.c b/lib/multi.c
> index bc93264..72e4825 100644
> --- a/lib/multi.c
> +++ b/lib/multi.c
> @@ -1804,10 +1804,13 @@ static void close_all_connections(struct Curl_multi
> *multi
On Wed, Apr 23, 2014 at 07:49:09AM -0400, Greg M wrote:
> > The easiest way to find it is probably to attach a debugger to the
> > running git-remote-https, and get a backtrace when it dies from SIGPIPE.
> > You'll probably want to install your system's debug packages for curl,
> > too.
> >
>
> T
On Wed, Apr 23, 2014 at 2:59 AM, Jeff King wrote:
> On Sun, Apr 20, 2014 at 08:42:15PM -0400, Greg M wrote:
>
>> Using git version 1.9.2 I am getting this error:
>>
>> [normal@laptop tmp]$ git clone https://github.com/mozilla/rust.git
>> Cloning into 'rust'...
>> remote: Reusing existing pack: 296
On Sun, Apr 20, 2014 at 08:42:15PM -0400, Greg M wrote:
> Using git version 1.9.2 I am getting this error:
>
> [normal@laptop tmp]$ git clone https://github.com/mozilla/rust.git
> Cloning into 'rust'...
> remote: Reusing existing pack: 296648, done.
> remote: Counting objects: 80, done.
> remote:
Michael Haggerty writes:
> I wonder whether we could give a way to specify a reference in an
> unambiguous, canonical fashion like I expected, for example by using a
> leading slash: "/refs/heads/mybranch". This could be a way for the user
> to ask for DWIMming to be turned off without having to
On 02/18/2014 08:51 PM, Junio C Hamano wrote:
> John Keeping writes:
>
>> There's already the arbitrary set of prefixes in
>> refs.c::prettify_refname() and refs.c::ref_rev_parse_rules(). I can see
>> how a user might think that since "git log refs/heads/name" is
>> equivalent to "git log master
David Kastrup writes:
> Junio C Hamano writes:
>
>> Duy Nguyen writes:
>>
>>> + if (!force && dwim_ref(name, strlen(name), sha1, &real_ref))
>>> + die(_("creating ref refs/heads/%s makes %s ambiguous.\n"
>>> + "Use -f to create it anyway."),
>>> + name,
On Tue, Feb 18, 2014 at 11:51:05AM -0800, Junio C Hamano wrote:
> John Keeping writes:
>
> > There's already the arbitrary set of prefixes in
> > refs.c::prettify_refname() and refs.c::ref_rev_parse_rules(). I can see
> > how a user might think that since "git log refs/heads/name" is
> > equival
John Keeping writes:
> There's already the arbitrary set of prefixes in
> refs.c::prettify_refname() and refs.c::ref_rev_parse_rules(). I can see
> how a user might think that since "git log refs/heads/name" is
> equivalent to "git log master" then "git branch refs/heads/name" should
> be equiva
Junio C Hamano writes:
> Duy Nguyen writes:
>
>> +if (!force && dwim_ref(name, strlen(name), sha1, &real_ref))
>> +die(_("creating ref refs/heads/%s makes %s ambiguous.\n"
>> + "Use -f to create it anyway."),
>> +name, name);
>
> Does this check s
On Tue, Feb 18, 2014 at 11:03:10AM -0800, Junio C Hamano wrote:
> Duy Nguyen writes:
>
> > Prevent is a strong word. I meant we only do it if they force
> > it. Something like this..
> >
> > -- 8< --
> > diff --git a/branch.c b/branch.c
> > index 723a36b..3f0540f 100644
> > --- a/branch.c
> > +++
Duy Nguyen writes:
> Prevent is a strong word. I meant we only do it if they force
> it. Something like this..
>
> -- 8< --
> diff --git a/branch.c b/branch.c
> index 723a36b..3f0540f 100644
> --- a/branch.c
> +++ b/branch.c
> @@ -251,6 +251,11 @@ void create_branch(const char *head,
>
Duy Nguyen gmail.com> writes:
> Prevent is a strong word. I meant we only do it if they force
> it. Something like this..
>
I would propose to make this even stronger:
Forbid to create any branches which start with any of:
- "refs/"
- "heads/"
- "remotes/"
- "tags/"
as long as you do not use th
On Fri, Feb 14, 2014 at 08:32:07AM -0800, Junio C Hamano wrote:
> Duy Nguyen writes:
>
> > On Fri, Feb 14, 2014 at 7:45 PM, Andreas Schwab
> > wrote:
> >> Josef Wolf writes:
> >>
> >>> Notice the refs/heads _within_ refs/heads!
> >>>
> >>> Now I wonder how I managed to get into this situation
On Fri, Feb 14, 2014 at 08:32:07AM -0800, Junio C Hamano wrote:
> A. You are not allowed to call your branch with a string that begins with
> 'refs/heads/'.
> B. Why?
> A. Because it will confuse you.
> B. I know what I am doing.
> A. ???
Your reply in
http://git.661346.n2.nabble.com/1-8-
David Kastrup writes:
> Junio C Hamano writes:
> ...
>> A. Because it will confuse you.
>> B. I know what I am doing.
>> A. ???
>
> A. But maybe Git will no longer know what you are doing. Its standard
> way of resolving references will mean that once a branch
> refs/heads/wibble exists, ref
On Fri, Feb 14, 2014 at 04:35:14PM +0100, David Kastrup wrote:
> Josef Wolf writes:
> > The only command in this script that uses "heads" is
> >
> > git symbolic-ref HEAD "refs/heads/$new_branch"
> >
> You probably should check how $new_branch comes about.
This is the line of code where $new_br
Junio C Hamano writes:
> Duy Nguyen writes:
>
>> On Fri, Feb 14, 2014 at 7:45 PM, Andreas Schwab
>> wrote:
>>> Josef Wolf writes:
>>>
Notice the refs/heads _within_ refs/heads!
Now I wonder how I managed to get into this situation and what's the best
way
to recover?
1 - 100 of 142 matches
Mail list logo
