Re: [git-users] Undocumented reset behavior

2017-04-23 Thread vvs
On Sunday, April 23, 2017 at 6:26:57 PM UTC+3, Konstantin Khomoutov wrote: > Even if the issue the OP is facing will evoke nothing more than > rehashing of the old argument about the (un)expected semantics, it > might result in documentation patches. ;-) I could just add to that argument that

Re: [git-users] Undocumented reset behavior

2017-04-23 Thread Konstantin Khomoutov
On Sat, 22 Apr 2017 17:57:26 +0100 "Philip Oakley" wrote: [...] > I tried it locally but didn't get what I think you expected. I am on > git version 2.9.0.windows.1.323.g0305acf (~the last which supports my > harware). > > What I have / see is [...] > So in both these

Re: [git-users] Undocumented reset behavior

2017-04-23 Thread Igor Djordjevic
On Saturday, April 22, 2017 at 11:14:08 PM UTC+2, vvs wrote: > > On Saturday, April 22, 2017 at 11:28:49 PM UTC+3, Philip Oakley wrote: >> >> On the main list thare is a similar "issue" [1] regarding the expectation >> for `git checkout`, and importantly (for me) these collected views >>

Re: [git-users] Undocumented reset behavior

2017-04-22 Thread vvs
On Saturday, April 22, 2017 at 11:28:49 PM UTC+3, Philip Oakley wrote: > > On the main list thare is a similar "issue" [1] regarding the expectation > for `git checkout`, and importantly (for me) these collected views > regarding the "Git Data Protection and Management Principles" is not within

Re: [git-users] Undocumented reset behavior

2017-04-22 Thread Philip Oakley
From: vvs To: Git for human beings Cc: vvs...@gmail.com ; flatw...@users.sourceforge.net ; philipoak...@iee.org Sent: Saturday, April 22, 2017 6:33 PM Subject: Re: [git-users] Undocumented reset behavior On Saturday, April 22, 2017 at 7:57:40 PM UTC+3, Philip Oakley wrote

Re: [git-users] Undocumented reset behavior

2017-04-22 Thread vvs
On Saturday, April 22, 2017 at 7:57:40 PM UTC+3, Philip Oakley wrote: > > Modify: 2017-04-22 16:47:19.43750 +0100 > Modify: 2017-04-22 16:47:29.640625000 +0100 > > > So in both these cases, the test simplification appears to result in > identical output (unless I missed something -

Re: [git-users] Undocumented reset behavior

2017-04-22 Thread Philip Oakley
(copying in Konstantin) - Original Message - From: vvs To: Git for human beings Cc: vvs...@gmail.com ; philipoak...@iee.org Sent: Saturday, April 22, 2017 3:18 PM Subject: Re: [git-users] Undocumented reset behavior On Saturday, April 22, 2017 at 4:50:41

Re: [git-users] Undocumented reset behavior

2017-04-22 Thread vvs
On Saturday, April 22, 2017 at 4:50:41 PM UTC+3, Philip Oakley wrote: > > If i understood the initial statement your have two different seqences of > commands and their interaction isn't as expected. but I couldn't decide > what the specific sequence were. > > Would you ab able to show a

Re: [git-users] Undocumented reset behavior

2017-04-22 Thread Philip Oakley
- Original Message - From: vvs To: Git for human beings Cc: vvs...@gmail.com Sent: Saturday, April 22, 2017 2:25 PM Subject: Re: [git-users] Undocumented reset behavior On Saturday, April 22, 2017 at 4:10:17 PM UTC+3, Konstantin Khomoutov wrote: All forms of `git

Re: [git-users] Undocumented reset behavior

2017-04-22 Thread vvs
On Saturday, April 22, 2017 at 4:10:17 PM UTC+3, Konstantin Khomoutov wrote: > > All forms of `git reset`, if not given a specific commit/tree-ish, > take HEAD as the commit/three-ish to take the data from. > Yes, of course. I was just referring to relevant parameters for brevity. > tree

Re: [git-users] Undocumented reset behavior

2017-04-22 Thread Konstantin Khomoutov
On Fri, 21 Apr 2017 13:54:30 -0700 (PDT) vvs wrote: > I found out that "git reset --hard" produced different outcome > depending on current index content, i.e. when there is no entry for a > file in working tree it actually changed that file. While on the > contrary, if you use

[git-users] Undocumented reset behavior

2017-04-21 Thread vvs
I found out that "git reset --hard" produced different outcome depending on current index content, i.e. when there is no entry for a file in working tree it actually changed that file. While on the contrary, if you use "git reset --mixed" right before that, the file won't be touched. This