On Sun, Dec 18, 2016 at 12:36 PM, Josh Bleecher Snyder
wrote:
> To reproduce, run 'git submodule' from within a bare repo. Result:
>
> $ git submodule
> fatal: $program_name cannot be used without a working tree.
>
> Looks like the intent was for $program_name to be interpolated.
Which version of
To reproduce, run 'git submodule' from within a bare repo. Result:
$ git submodule
fatal: $program_name cannot be used without a working tree.
Looks like the intent was for $program_name to be interpolated.
As an aside, I sent a message a few days ago about a segfault when
working with a filesy
Hello,
Sorry again for the mailing list...
On Thu, Oct 6, 2016 at 11:20 AM, Heiko Voigt wrote:
> So I guess the same applies to 'git status'?
No, it is the strange thing.
As told in my very first message here what happens after git diff and
git status:
$ git clone https://github.com/githubtrai
Hi,
please also keep the mailinglist in the CC so everyone can read this.
On Thu, Oct 06, 2016 at 09:11:05AM +0200, Thomas Bétous wrote:
> On Wed, Oct 5, 2016 at 3:36 PM, Heiko Voigt wrote:
>
> >
> > My initial reaction is that this might be a problem with line endings. Did
> > you
> > check wh
Hi,
please do not top-post the conversation will otherwise get hard to
follow. Thank you.
On Tue, Oct 04, 2016 at 05:46:45PM +0200, Thomas Bétous wrote:
> Thank you for your answer and sorry for the delay (I was on vacation...).
>
> I am using git 2.9.0.windows.1 (run on Windows 7 via git bash).
Thank you for your answer and sorry for the delay (I was on vacation...).
I am using git 2.9.0.windows.1 (run on Windows 7 via git bash).
I tested it on this repo:
https://github.com/githubtraining/example-dependency.git
The same problem occurs.
Here a small script to reproduce the error on my PC
On Tue, Aug 30, 2016 at 01:45:56PM +0200, Thomas Bétous wrote:
> Are you able to reproduce this problem?
No. I just did a clone and an immediate deinit afterwards and no error.
Maybe you can provide a script to reproduce? Which System was this on?
Cheers Heiko
The patterns in question do contain a slash, although they don't start
with a slash.
I tried changing it to "!/.vim/colors/*" as you recommended, with no
change in behavior. I even tried adding a leading slash to every
pattern in gitignore, with no effect.
Removing the line with "!/.vim/colors/*"
On Fri, Sep 2, 2016 at 4:06 PM, Brian Levinstein wrote:
> The relevant repo is here:
> https://github.com/blevinstein/dotfiles
>
> My gitignore file looks like this:
> https://github.com/blevinstein/dotfiles/blob/2400ca8642a7b454a2bfc54e8402343d008836aa/.gitignore
> It basically ignores all files,
The relevant repo is here:
https://github.com/blevinstein/dotfiles
My gitignore file looks like this:
https://github.com/blevinstein/dotfiles/blob/2400ca8642a7b454a2bfc54e8402343d008836aa/.gitignore
It basically ignores all files, except for specifically whitelisted
files. However, when I run "git
Hello,
I found a curious bug in git version 2.9.0.windows.1 (run on Windows 7
via git bash).
If I clone a repository containing submodules and run a "git submodule
deinit" on any of the submodules of this repository without executing
another git command, this command fails.
For instance:
(let's
With the following steps content from one file ends up in another file
by using 'git rebase' (and clobbers the original content).
It is rather straight forward and I discovered this behaviour when
trying to replay http://gitforteams.com/resources/rebasing.html .
The special thing is, that both f
Jehan Pagès writes:
> ... A better naming should
> have been called --invert-matches, or even just --invert.
> And the man description should definitely be completed, IMO.
Renaming the options would not work well without harming existing
users, but a patch to update the documentation is certainl
Hi,
On Wed, Jul 13, 2016 at 7:37 PM, Junio C Hamano wrote:
> Jehan Pagès writes:
>
>>> I think --author=someone greps the "author " field in the commit
>>> object looking for the hit with "someone", and your request asks to
>>> show commits that either do not have "something" or was not written
Jehan Pagès writes:
>> I think --author=someone greps the "author " field in the commit
>> object looking for the hit with "someone", and your request asks to
>> show commits that either do not have "something" or was not written
>> by "someone", I would guess.
>
> Note that I can still see commi
Hi,
On Wed, Jul 13, 2016 at 7:04 PM, Junio C Hamano wrote:
> Jehan Pagès writes:
>
>>> git log --author=someone --invert-grep --grep=something
>>
>> But it does not work. Actually it looks like it just returns
>> everything (as though I had done a simple `git log`).
>
> Do you see a commit that
Hello,
> $ git version
> git version 2.5.5
Tested on a Fedora 23.
You can combine `git log --author=someone --grep=something` to have
all commits by "someone" where "something" can be grepped. If I want
all commits by someone where "something" is not grepped, I would
expect this command to retur
Jehan Pagès writes:
>> git log --author=someone --invert-grep --grep=something
>
> But it does not work. Actually it looks like it just returns
> everything (as though I had done a simple `git log`).
Do you see a commit that is by "someone" and has "something" in it
in the output from the comman
On Sun, Jun 19, 2016 at 12:00 PM, Jeff King wrote:
> Stefan, I think it might be worth revisiting the default set by d22eb04
> to propagate shallowness from the super-project clone. In an ideal
> world, we would be asking each submodule for the actual commit we are
> interested in, and shallowness
On Sun, Jun 19, 2016 at 06:09:28PM -0700, Stefan Beller wrote:
> > I hadn't paid much attention to this topic originally, but was surprised
> > that "--depth 10" in the clone implies "--depth 1" in the submodule.
> > This is not really related to your patch (in fact, your patch makes the
> > logic
On zo, 2016-06-19 at 18:09 -0700, Stefan Beller wrote:
> How often do we see a depth != 1 in practice?
Travis clones with --depth=50
D.
--
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.kern
IBM@IBMIL, "git@vger.kernel.org"
> Date: 06/20/2016 04:09 AM
> Subject: Re: [BUG REPORT] git 2.9.0 clone --recursive fails on
> cloning a submodule
>
> On Sun, Jun 19, 2016 at 5:13 PM, Jeff King wrote:
> > On Sun, Jun 19, 2016 at 01:51:56PM -0700, Junio C
On Sun, Jun 19, 2016 at 5:13 PM, Jeff King wrote:
> On Sun, Jun 19, 2016 at 01:51:56PM -0700, Junio C Hamano wrote:
>
>> Yup, something like this on top of d22eb04 to be merged before
>> v2.9.1 for the maintenance track would be necessary.
>>
>> -- >8 --
>> Subject: clone: do not let --depth imply
On Sun, Jun 19, 2016 at 01:51:56PM -0700, Junio C Hamano wrote:
> Yup, something like this on top of d22eb04 to be merged before
> v2.9.1 for the maintenance track would be necessary.
>
> -- >8 --
> Subject: clone: do not let --depth imply --shallow-submodules
>
> In v2.9.0, we prematurely flipp
Jeff King writes:
> Stefan, I think it might be worth revisiting the default set by d22eb04
> to propagate shallowness from the super-project clone. In an ideal
> world, we would be asking each submodule for the actual commit we are
> interested in, and shallowness would not matter. But until
> u
On Sun, Jun 19, 2016 at 04:07:41PM +0300, Vadim Eisenberg wrote:
> The problem is with other tools that use git, like Swift Package Manager -
> https://swift.org/package-manager/.
> Versions of git before 2.9.0 have no option --no-shallow-submodules. So
> the tools that use git would have to che
specify that option.
Best Regards,
Vadim
Jeff King wrote on 06/19/2016 01:00:51 PM:
> From: Jeff King
> To: Vadim Eisenberg/Haifa/IBM@IBMIL
> Cc: Stefan Beller , git@vger.kernel.org
> Date: 06/19/2016 01:01 PM
> Subject: Re: [BUG REPORT] git 2.9.0 clone --recursive fails on
> c
On Sun, Jun 19, 2016 at 10:17:36AM +0300, Vadim Eisenberg wrote:
> /usr/local/bin/git clone --recursive --depth 10
> https://github.com/IBM-Swift/Kitura-net.git
> Cloning into 'Kitura-net'...
> remote: Counting objects: 253, done.
> remote: Compressing objects: 100% (142/142), done.
> remote: Tot
/usr/local/bin/git clone --recursive --depth 10
https://github.com/IBM-Swift/Kitura-net.git
Cloning into 'Kitura-net'...
remote: Counting objects: 253, done.
remote: Compressing objects: 100% (142/142), done.
remote: Total 253 (delta 134), reused 188 (delta 86), pack-reused 0
Receiving objects: 10
Why half of Git output goes to stdout and half to stderr? I suspect
this is a bug.
Below I call `git pushbug` alias defined it the below presented config
file.
$ cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = tru
On Sat, May 14, 2016 at 07:40:11AM +0200, Torsten Bögershausen wrote:
> On 13.05.16 18:43, Junio C Hamano wrote:
> > Adam Dinwoodie writes:
> >
> >> If you use .gitattributes to enable CRLF->LF rewriting, then commit a
> >> file that would have its line endings rewritten, the "CRLF will be
> >> r
On 13.05.16 18:43, Junio C Hamano wrote:
> Adam Dinwoodie writes:
>
>> If you use .gitattributes to enable CRLF->LF rewriting, then commit a
>> file that would have its line endings rewritten, the "CRLF will be
>> replaced by LF" warning is printed several times over; I'd expect it to
>> be print
On Fri, May 13, 2016 at 12:46:57PM -0700, Junio C Hamano wrote:
> > We don't want commits that fail the test suite, since it makes bisection
> > more difficult. But you can mark known bugs like:
> >
> >test_expect_failure 'git-foo should output bar' '
> > ...
> >'
> >
> > I think it's
Jeff King writes:
> On Fri, May 13, 2016 at 02:49:53PM +0100, Adam Dinwoodie wrote:
>
>> (Tangentially: what's the accepted practice for submitting failing test
>> scripts? I've written a short test case to add to t0020 that shows this
>> bugged behaviour, but I've got the vague impression from
On Fri, May 13, 2016 at 02:49:53PM +0100, Adam Dinwoodie wrote:
> (Tangentially: what's the accepted practice for submitting failing test
> scripts? I've written a short test case to add to t0020 that shows this
> bugged behaviour, but I've got the vague impression from past emails
> that leading
Adam Dinwoodie writes:
> If you use .gitattributes to enable CRLF->LF rewriting, then commit a
> file that would have its line endings rewritten, the "CRLF will be
> replaced by LF" warning is printed several times over; I'd expect it to
> be printed only once.
>
> There's a test case in t0020 --
If you use .gitattributes to enable CRLF->LF rewriting, then commit a
file that would have its line endings rewritten, the "CRLF will be
replaced by LF" warning is printed several times over; I'd expect it to
be printed only once.
There's a test case in t0020 -- "safecrlf: print warning only once"
Thanks for your explanation
>
> The moment where I think you'd like to be notified is when we skipped
> doing anything with patch 1. You'd prefer it to say "woah, the other
> side of the rebase did the same thing as us".
Actually this is the problem where I want to be notified.
> But rebase does
On Fri, May 13, 2016 at 03:41:13PM +0800, 李本超 wrote:
> It does not warn me in this case. I replayed it again, below is my process:
>
> [...setup...]
So after you setup steps you have:
$ git log --decorate --oneline --raw
* a3ce3bc (HEAD -> B) modify
| :100644 100644 94954ab... 23509e0...
It does not warn me in this case. I replayed it again, below is my process:
$ mkdir bug_test
$ cd bug_test/
$ git init
Initialized empty Git repository in /home/libenchao/tmp/bug_test/.git/
$ echo 'hello' > README.md
$ git add README.md
$ git commit -m 'Add README.md'
[master (root-commit) 9cdb3a8
On Fri, May 13, 2016 at 12:27 PM, 李本超 wrote:
> Yes, you got the right understanding of my problem.
>
> You are right, the git behavior is quite correct. But I met this
> problem in my practical work:
>
> My colleague added a method but I didn't know. I also added the same method.
> Then I found th
Yes, you got the right understanding of my problem.
You are right, the git behavior is quite correct. But I met this
problem in my practical work:
My colleague added a method but I didn't know. I also added the same method.
Then I found that I didn't need the method actually, so I deleted it.
My
On Fri, May 13, 2016 at 11:28 AM, 李本超 wrote:
> git version 2.6.4 (Apple Git-63)
> system version: OS X EI Capitan 10.11.4
>
> below is the steps:
> $ mkdir test_repo
> $ cd test_repo
> $ git init
> $ echo "hello" > README.md
> $ git commit -a -m 'Add README.md'
It was my mistake. git-commit -a ad
git version 2.6.4 (Apple Git-63)
system version: OS X EI Capitan 10.11.4
below is the steps:
$ mkdir test_repo
$ cd test_repo
$ git init
$ echo "hello" > README.md
$ git commit -a -m 'Add README.md'
$ git checkout -b A
$ echo "world" > README.md
$ git commit -a -m 'Add one line'
$ git checkout m
Please mention the version no of git you are using and your system.
I am answering according to git 2.8.1 Lubuntu 15.04
On Fri, May 13, 2016 at 10:34 AM, 李本超 wrote:
> Hi all,
>
> Yestoday when I worked using Git, I found a bug. It's about
> rebase. Or I don't know if it is a bug, maybe that
Hi all,
Yestoday when I worked using Git, I found a bug. It's about
rebase. Or I don't know if it is a bug, maybe that is Git. Below is my
problem:
There is a master branch, and we develop in our own branch.
Let's simplify this: there are two branches created at the same commit
point
Hi,
On Sat, Apr 2, 2016 at 5:25 PM, Benjamin Sandeen
wrote:
> Today, I managed to create a duplicate branch in a git repository. While
> this may not be a bug per se, I do think that it is confusing and some way
> of preventing such issues in the future may be helpful.
>
> I first cloned the rep
On Sat, Apr 2, 2016 at 8:25 PM, Benjamin Sandeen
wrote:
> Today, I managed to create a duplicate branch in a git repository. While
> this may not be a bug per se, I do think that it is confusing and some way
> of preventing such issues in the future may be helpful.
This can be confusing. I'll h
Today, I managed to create a duplicate branch in a git repository. While
this may not be a bug per se, I do think that it is confusing and some way
of preventing such issues in the future may be helpful.
I first cloned the repository:
$ git clone https://github.com/CodeForChicago/superclass.git
I recently installed Git version 2.7.2.windows.1 (I am running Windows
7 64-bit). Since the update, I have been unable to run `git add` with
the `-p` option on files within a certain directory (or its
subdirectories) whose name is `_` (an underscore).
`git status` correctly reports that my file h
On Monday, February 08, 2016 06:55:17 PM Stephen & Linda Smith wrote:
> > #!/bin/bash
> > mkdir test-repository || exit 1
> > cd test-repository
> > git init
> > echo "Initial contents, unimportant" > test-file
> > git add test-file
> > git commit -m "Initial commit"
> > echo "commit-1-state" > tes
Ovidiu Gheorghioiu wrote:
> Hi git guys,
>
> The bug is fairly simple: if we have a conflicted merge, AND all the
> conflicts have been resolved to the version in HEAD, the commit
> --dry-run error code says nothing to commit. As expected, git commit
> goes through.
>
> The commit message IS cor
Hi Khải,
On Sat, 17 Oct 2015, Khải wrote:
> I'm using Windows 10. Before I install git 2.6.1.windows.1, I have
> installed git 1.9.5.github.0 (by installing GitHub Desktop), it works
> just fine.
Good.
> But when I installed git 2.6.1.windows.1 (from git-scm.com), I'm not
> able to use git anym
I'm using Windows 10. Before I install git 2.6.1.windows.1, I have
installed git 1.9.5.github.0 (by installing GitHub Desktop), it works just
fine.
But when I installed git 2.6.1.windows.1 (from git-scm.com), I'm not able
to use git anymore:
- The powershell console displayed [(unknown)] instea
hi,
- `git stash save -u` deletes a directory, even though the _contents_
of that directory are .gitignored (e.g. "foo/*" in .gitignore).
Detailed reproduction below.
- The behaviour is not present when instead .gitignoring the directory
itself (e.g. "foo"). This does imo not excuse the behaviour
Git devs,
Can I get a confirmation that someone has confirmed this as a bug?
And that it is in a queue somewhere for eventual fixing?
Thanks,
John Medema
Systems Administrator
United Drugs, a Subsidiary of AAP (American Associated Pharmacies)
john.med...@uniteddrugs.com
7243 N 16th Street, Phoen
On Wed, Sep 09, 2015 at 03:16:38PM +0700, Robert Macháček wrote:
> Sorry, I am new to git, I have just followed instructions at
> https://git-scm.com/community which says:
>
> Mailing List
> Questions or comments for the Git community can be sent to the mailing
> list by using the email address g
Hi Johannes,
Sorry, I am new to git, I have just followed instructions at
https://git-scm.com/community which says:
Mailing List
Questions or comments for the Git community can be sent to the mailing
list by using the email address git@vger.kernel.org. Bug reports
should be sent to this mailing l
Hi Robert,
On 2015-09-09 08:11, Robert Macháček wrote:
> Just reading this chapter:
> https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell
>
> I believe that: Figure 3-9. Divergent history
> (https://git-scm.com/book/en/v2/book/03-git-branching/images/advance-master.png)
> does no
Hi,
I am trying to add a submodule with option --branch and --depth
together, and failed. However, there is no problem if only one of them
is applied.
So, this worked:
git submodule add --branch develop
https://an...@bitbucket.org/anton/mysubmodule.git
This is also worked:
git submodule ad
Hi,
Just reading this chapter:
https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell
I believe that: Figure 3-9. Divergent history
(https://git-scm.com/book/en/v2/book/03-git-branching/images/advance-master.png)
does not show the final "2 branch situation" as described in the
exampl
Git gurus, your assistance is needed.
Environment #1:
git version 2.5.0.windows.1
git-gui version 0.20.GITGUI
Windows 7 Pro 64-bit
Environment #2:
git version 1.7.9.msysgit.0
git-gui version 0.16.GITGUI
Windows Server 2003 R2 32-bit
Environment #3:
Linux (check with dscho, https://github.com/git
Hi git guys,
The bug is fairly simple: if we have a conflicted merge, AND all the
conflicts have been resolved to the version in HEAD, the commit
--dry-run error code says nothing to commit. As expected, git commit
goes through.
The commit message IS correct (-ish), just not the error code:
"""
Summary: Certain diffs containing angle brackets ('<' or '>' characters) are
displayed incorrectly in gitk's "markup words" and "color words" modes. The bug
is caused by a feature that isn't aware of the formatting difference for the
word diff modes.
How to reproduce the bug:
Create a file wi
Hi,
On 2015-08-10 14:26, MS-Informatique wrote:
> My Windows notebook got updated to Windows 10 and now my Git Bash doesn't
> start and when I open an existing repository from Git Gui, I am getting next
> error:
> "0 [main] us 0 init_cheap: VirtualAlloc pointer is null, Win32 error 487
> Allocati
On Mon, 10 Aug 2015 14:26:44 +0200
"MS-Informatique" wrote:
> My Windows notebook got updated to Windows 10 and now my Git Bash
> doesn't start and when I open an existing repository from Git Gui, I
> am getting next error:
> "0 [main] us 0 init_cheap: VirtualAlloc pointer is null, Win32 error
>
My Windows notebook got updated to Windows 10 and now my Git Bash doesn't
start and when I open an existing repository from Git Gui, I am getting next
error:
"0 [main] us 0 init_cheap: VirtualAlloc pointer is null, Win32 error 487
AllocationBase 0x0, BaseAddress 0x6857, RegionSize 0x41, St
On Wed, Aug 05, 2015 at 10:35:45PM +0200, Hugo Roy wrote:
>
> Hello,
>
> I've tried to sign a commit following
> https://git-scm.com/book/tr/v2/Git-Tools-Signing-Your-Work however,
> this is what happened:
>
> % git commit -a -S -m "signed commit testing"
> gpg: échec de la signature : O
Hello,
I've tried to sign a commit following
https://git-scm.com/book/tr/v2/Git-Tools-Signing-Your-Work however,
this is what happened:
% git commit -a -S -m "signed commit testing"
gpg: échec de la signature : Opération annulée
gpg: signing failed: Opération annulée
error: gpg n
Hi Gary,
On 2015-06-19 16:09, Gary England wrote:
> Will do. It's unlikely that I'll be able to reproduce the error. But,
> in the event that it happens again, I'll let you know.
For the record, the problem usually lies with a certain implementation detail
on 32-bit only (if you know the `rebas
England
Cc: git@vger.kernel.org
Subject: Re: Bug report: Unhandled Exception
Hi Gary,
On 2015-06-11 21:21, Gary England wrote:
> Using git version 1.9.2-preview20140411, in Git Bash for Windows,
> performing a "git pull --rebase", received an unhandled exception.
Please note that the newest 1.
Hi Gary,
On 2015-06-11 21:21, Gary England wrote:
> Using git version 1.9.2-preview20140411, in Git Bash for Windows,
> performing a "git pull --rebase", received an unhandled exception.
Please note that the newest 1.9.x release is 1.9.5. Could you re-test with that
version, please? Or maybe yo
Alistair Lynn writes:
> $ git commit --allow-empty -m ‘test’
> $ git revert HEAD
>
> The latter fails silently, leaving HEAD pointing at the commit created
> by the first command.
I do not necessarily think it is a bug to ignore reverting a no-op.
"revert a no-op" should probably fail by default
Hello gitters
Steps to reproduce:
$ git commit --allow-empty -m ‘test’
$ git revert HEAD
The latter fails silently, leaving HEAD pointing at the commit created by the
first command.
A subsequent `git commit --allow-empty` has the revert message as the default
commit message when starting the
Hello,
Using git version 1.9.2-preview20140411, in Git Bash for Windows, performing a
"git pull --rebase", received an unhandled exception. Here is the stack trace:
MSYS-1.0.12 Build:2012-07-05 14:56
Exception: STATUS_ACCESS_VIOLATION at eip=00418DAA
eax=680A38E4 ebx=685704CC ecx=00542E38 edx=0
Argh, thanks a lot! Should have read the man page better. OTOH,
I expect 'git commit --allow-empty' being needed, but 'git rebase --keep-empty'
comes somewhat as a surprise - I wasn't expecting git rebase to commit
each in turn,
but of course that's what it does.
On 7 May 2015 at 01:47, Mikael Ma
On Wed, Jun 03, 2015 at 05:39:14PM +0200, Dennis Kaarsemaker wrote:
> On di, 2015-06-02 at 23:48 -0700, Junio C Hamano wrote:
> >
> > I am kind of surprised after reading these two threads that my
> > take on this issue has changed over time, as my knee-jerk
> > reaction before reading them was t
On di, 2015-06-02 at 23:48 -0700, Junio C Hamano wrote:
>
> I am kind of surprised after reading these two threads that my
> take on this issue has changed over time, as my knee-jerk
> reaction before reading them was the opposite, something
> along the lines of "This is only immediately after 'gi
On Tue, Jun 2, 2015 at 11:20 PM, Jeff King wrote:
>
> Here are some prior discussions:
>
> http://thread.gmane.org/gmane.comp.version-control.git/75692
>
> http://thread.gmane.org/gmane.comp.version-control.git/200504
>
> I just skimmed through them, but I expect the most desirable solution
>
On Wed, Jun 03, 2015 at 11:24:19AM +0530, Tummala Dhanvi wrote:
> When we do create a new empty git repo using git init or create a
> orphan branch and do a git log then I am getting an error saying that
> fatal: bad default revision 'HEAD'
>
> Well the error should have been something like no co
When we do create a new empty git repo using git init or create a
orphan branch and do a git log then I am getting an error saying that
fatal: bad default revision 'HEAD'
Well the error should have been something like no commits to show
either the branch is orphan / you didn't make any commits in
Hi Yuval,
On 2015-05-18 08:50, Yuval Greenfield wrote:
> Here is the command sequence that causes git to stop responding:
>
> mkdir mynewthing
> cd mynewthing
> git init
> mkdir abc
> touch abc/myfile
> git add abc/myfile
> git commit -a -m "whatever"
> git mv abc tmp
> git mv tmp Abc
>
> I wan
On Wed, Apr 29, 2015 at 09:30:00AM -0700, Junio C Hamano wrote:
> >> (
> >>while read x && test -n "$x"
> >> do
> >>:;
> >>done
> >>cat
> >> ) <../commit | eval "$filter_msg"
> >>
> >> would not spin too much in shell loop, perhaps?
> >
> > Yeah, that is not too ba
Jeff King writes:
> On Tue, Apr 28, 2015 at 10:39:44PM -0700, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > I'm not sure of a solution short of replacing the use of sed here with
>> > something else. perl would be a simple choice, but filter-branch does
>> > not otherwise depend on it. W
Jeff King writes:
> I'm not sure of a solution short of replacing the use of sed here with
> something else. perl would be a simple choice, but filter-branch does
> not otherwise depend on it. We could use a shell "read" loop, but those
> are quite slow (and filter-branch is slow enough as it is!
On Wed, Apr 29, 2015 at 12:39:47AM -0400, Jeff King wrote:
> So I can't figure out how to replicate the problem here.
Actually, that's not quite true. I could get hold of an OS X system to
replicate, which I just did.
The problem is that commit 3b754f212 does not have a newline at the end
of its
On Tue, Apr 28, 2015 at 01:02:17PM +0200, Olivier ROLAND wrote:
> Both versions are builded from source.
> head -1 "$(git --exec-path)/git-filter-branch"
> #!/bin/sh
>
> sh --version
> GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin14)
> Copyright (C) 2007 Free Software Foundation, Inc.
2015-04-28 7:55 GMT+02:00 Jeff King :
> On Sun, Apr 26, 2015 at 11:25:52AM +0200, Olivier ROLAND wrote:
>
>> OSX 10.10.3 git 2.3.6 HFS+ case-sensitive
>>
>> How to reproduce :
>> Step 1 : git clone https://github.com/begeric/FastParsers.git
>> Step 2 : cd FastParsers/
>> Step 3 : git filter-branch
On Sun, Apr 26, 2015 at 11:25:52AM +0200, Olivier ROLAND wrote:
> OSX 10.10.3 git 2.3.6 HFS+ case-sensitive
>
> How to reproduce :
> Step 1 : git clone https://github.com/begeric/FastParsers.git
> Step 2 : cd FastParsers/
> Step 3 : git filter-branch --env-filter 'if [ 0 = 1 ]; then echo 0; fi' -
Hello,
Seem to be a bug.
OSX 10.10.3 git 2.3.6 HFS+ case-sensitive
How to reproduce :
Step 1 : git clone https://github.com/begeric/FastParsers.git
Step 2 : cd FastParsers/
Step 3 : git filter-branch --env-filter 'if [ 0 = 1 ]; then echo 0; fi' -- --all
Result on OSX :
Rewrite 65df7c5ac1ed95625
On 2015-04-25 07.57, Chris wrote:
> Hello,
>
> Using git version 2.3.5 with kernel 3.19.3-3-ARCH #1 SMP PREEMPT x86_64 I see
> the following error message when pulling or cloning a repo over ssh:
>
> """
> git clone ssh://user@mydomain:/home/user/path/to/project.git
> Cloning into 'project'...
>
On Sat, Apr 25, 2015 at 3:57 PM, Chris wrote:
> Hello,
>
> Using git version 2.3.5 with kernel 3.19.3-3-ARCH #1 SMP PREEMPT x86_64 I
> see the following error message when pulling or cloning a repo over ssh:
>
> """
> git clone ssh://user@mydomain:/home/user/path/to/project.git
> Cloning into 'pro
Hello,
Using git version 2.3.5 with kernel 3.19.3-3-ARCH #1 SMP PREEMPT x86_64
I see the following error message when pulling or cloning a repo over ssh:
"""
git clone ssh://user@mydomain:/home/user/path/to/project.git
Cloning into 'project'...
ssh: Could not resolve hostname mydomain:: Name o
Junio C Hamano writes:
> Tobias Preuss writes:
>
>> I noticed some bizarre behaviour when using: git stash -u.
>> It deletes folders which contain files configured to be ignored.
>
> The files you mark as ignored are expendable and this is not limited
> to "stash".
> ...
> Here is what should ha
Tobias Preuss writes:
> I noticed some bizarre behaviour when using: git stash -u.
> It deletes folders which contain files configured to be ignored.
The files you mark as ignored are expendable and this is not limited
to "stash".
$ git init
Initialized empty Git repository in /var/tmp/
Hello.
I noticed some bizarre behaviour when using: git stash -u.
It deletes folders which contain files configured to be ignored. I
actually lost files by this which I could not restore.
Here is how you can reproduce the case.
1. Create a project folder to act as the root of the repository. `cd
2015-02-02 3:41 UTC-05:00, Chris Packham :
> [...]
> But it actually looks like git rev-parse --resolve-git-dir $path needs
> to be run inside a git repository _any_ git repository, which seems a
> bit backwards to me.
> [...]
Indeed, looking at git-rev-parse(1), the correct option might be
--show
On Mon, Feb 2, 2015 at 9:41 PM, Chris Packham wrote:
> Hi,
>
> On Sat, Jan 31, 2015 at 10:46 AM, Rémi Rampin wrote:
>> Hi,
>>
>> This bug report concerns git-gui. Apologies if this is not the right
>> mailing-list.
>>
>> By submodule I mean a r
Hi,
On Sat, Jan 31, 2015 at 10:46 AM, Rémi Rampin wrote:
> Hi,
>
> This bug report concerns git-gui. Apologies if this is not the right
> mailing-list.
>
> By submodule I mean a repository for which .git is not a regular Git
> directory, but rather a "gitdir: ..."
Hi,
This bug report concerns git-gui. Apologies if this is not the right
mailing-list.
By submodule I mean a repository for which .git is not a regular Git
directory, but rather a "gitdir: ..." file.
While running "git gui" from such a directory will work fine, trying
201 - 300 of 479 matches
Mail list logo
