Le 29/07/2016 à 16:16, Guillaume Munch a écrit :
Le 28/07/2016 à 23:19, Richard Heck a écrit :
I wonder if
git rm .gitattributes
git add .gitattributes
git reset --hard
would be enough.
I do not understand how this would solve, but I will try next time it
happens.
git rm
Le 28/07/2016 à 23:19, Richard Heck a écrit :
On 07/23/2016 06:30 PM, Guillaume Munch wrote:
Since it looks so severe, I wonder whether there is a radical solution,
such as rewriting the history of master, provided developers agree that
the problem is that annoying.
That sounds dangerous.
On 07/23/2016 06:30 PM, Guillaume Munch wrote:
> Le 26/06/2016 à 01:21, Scott Kostyshak a écrit :
>> I think this is due to the recent fixes in .gitattributes. In any case,
>> git reset --hard does not fix anything. But the following does work for
>> me:
>>
>> git rm .gitattributes
>> git add -A
Le 26/06/2016 à 01:21, Scott Kostyshak a écrit :
I think this is due to the recent fixes in .gitattributes. In any case,
git reset --hard does not fix anything. But the following does work for
me:
git rm .gitattributes
git add -A
git reset --hard
Thank you very much for this message. I have
On Sun, Jun 26, 2016 at 09:10:31PM +0200, Georg Baum wrote:
> Scott Kostyshak wrote:
>
> > On Sun, Jun 26, 2016 at 07:46:21PM +0100, Guillaume Munch wrote:
> >> Le 26/06/2016 18:08, Georg Baum a écrit :
> >
> >> > Funnily I never saw that
> >> > myself, but it should be fixed at 933bc7f0ddf.
Scott Kostyshak wrote:
> On Sun, Jun 26, 2016 at 07:46:21PM +0100, Guillaume Munch wrote:
>> Le 26/06/2016 18:08, Georg Baum a écrit :
>
>> > Funnily I never saw that
>> > myself, but it should be fixed at 933bc7f0ddf. PLease tell me if you
>> > ever see this again.
>> >
>>
>> I just saw this
On Sun, Jun 26, 2016 at 07:46:21PM +0100, Guillaume Munch wrote:
> Le 26/06/2016 18:08, Georg Baum a écrit :
> > Funnily I never saw that
> > myself, but it should be fixed at 933bc7f0ddf. PLease tell me if you ever
> > see this again.
> >
>
> I just saw this when checking out a commit after
Le 26/06/2016 18:08, Georg Baum a écrit :
Scott Kostyshak wrote:
I think this is due to the recent fixes in .gitattributes. In any case,
git reset --hard does not fix anything. But the following does work for
me:
Yes, this was caused by the introduction of .gitattributes, since these
files
Scott Kostyshak wrote:
> I think this is due to the recent fixes in .gitattributes. In any case,
> git reset --hard does not fix anything. But the following does work for
> me:
Yes, this was caused by the introduction of .gitattributes, since these
files were checked in with windows line ends
On 06/25/2016 08:21 PM, Scott Kostyshak wrote:
Just in case anyone else has this issue:
I keep having the following situation come up:
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
(use "git add ..." to update what will be
Just in case anyone else has this issue:
I keep having the following situation come up:
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
(use "git add ..." to update what will be committed)
(use "git checkout -- ..." to discard
11 matches
Mail list logo
