Re: git -C has unexpected behaviour

Hi Felix, On Mon, 7 Nov 2016, Felix Nairz wrote: > From what you are saying I can see that this expects as designed. It's > confusing in the submodule case, but I get you don't want to add extra > rules which slow down performance and mess with other people at the > same time. The "messing with

Re: git -C has unexpected behaviour

Hi guys, thanks for the answer and the clarification. >From what you are saying I can see that this expects as designed. It's confusing in the submodule case, but I get you don't want to add extra rules which slow down performance and mess with other people at the same time. I will look into

Re: git -C has unexpected behaviour

Hi Felix, On Fri, 4 Nov 2016, Felix Nairz wrote: > Now, to the unexpected part, which I think is a bug: > > If the TestData folder is there, but empty (I deleted all the files), > then running > > git -C .\TestData reset --hard > > will NOT throw me an error but run > > git reset --hard > >

Re: git -C has unexpected behaviour

On Fri, Nov 4, 2016 at 7:28 AM, Felix Nairz wrote: > Hi guys, > > I ran into some really weird git behaviour today. > > My git --version is: git version 2.8.1.windows.1 > > We have a git repository with a submodule called TestData. The data in > there is modified and reset

git -C has unexpected behaviour

Hi guys, I ran into some really weird git behaviour today. My git --version is: git version 2.8.1.windows.1 We have a git repository with a submodule called TestData. The data in there is modified and reset as part of our unit tests. The submodule is a sub-folder of the git repository called