[git-users] Re: git reset with staged changes

2014-06-09 Thread Pierre-François CLEMENT
Hey guys, for the record here's the the thread I've started on git's official mailing list. Hopefully we'll get some feedback on this. -- You received this message because you are subscribed to the Google Groups "Git for human be

Re: [git-users] Re: git reset with staged changes

2014-06-05 Thread Philip Oakley
- Original Message - From: Pierre-François CLEMENT To: git-users@googlegroups.com Sent: Thursday, June 05, 2014 11:21 AM Subject: Re: [git-users] Re: git reset with staged changes Le mercredi 4 juin 2014 16:28:27 UTC+2, Dale Worley a écrit : Yeah, but what one *feels* is

Re: [git-users] Re: git reset with staged changes

2014-06-05 Thread Dale R. Worley
> From: Paul Smith > > There are a million special case situations and it's too exhausting for > both the author and the reader to be sure to cover all of them every > time, which is why you perceive ambiguities in the documentation. There is a definition of "tracked" which was settled upon by t

Re: [git-users] Re: git reset with staged changes

2014-06-05 Thread Pierre-François CLEMENT
Le mercredi 4 juin 2014 16:28:27 UTC+2, Dale Worley a écrit : > > Yeah, but what one *feels* is the definition of the word is not > relevant. > It somehow is IMO, as I got that feeling from my day-to-day use of git and from reading its manual, so it might be the symptoma of some incoherences a

Re: [git-users] Re: git reset with staged changes

2014-06-04 Thread Paul Smith
On Wed, 2014-06-04 at 10:28 -0400, Dale R. Worley wrote: > > From: Paul Smith > > > > A tracked file is a file that Git knows about. An untracked file is a > > file Git doesn't know about. More concretely, any file that has ever > > been "git add"'d is tracked. Files that have never been "git

Re: [git-users] Re: git reset with staged changes

2014-06-04 Thread Dale R. Worley
> From: Pierre-François CLEMENT > > Really? Sounds a bit strange. I feel like "tracked files" are committed > files, and that staged files are "about-to-be-tracked files" so in a sort > of a transient state. Yeah, but what one *feels* is the definition of the word is not relevant. To work consi

Re: [git-users] Re: git reset with staged changes

2014-06-04 Thread Paul Smith
On Wed, 2014-06-04 at 11:23 +0200, Pierre-François CLEMENT wrote: > Beware, though. I don't have my Git reference to hand, but > I've noted that if the file is in the index, it is > "tracked" [...] > Really? Sounds a bit strange. I feel like "tracked files" are > committed

Re: [git-users] Re: git reset with staged changes

2014-06-04 Thread Pierre-François CLEMENT
> > Beware, though. I don't have my Git reference to hand, but I've noted > that if the file is in the index, it is "tracked" [...] > Really? Sounds a bit strange. I feel like "tracked files" are committed files, and that staged files are "about-to-be-tracked files" so in a sort of a transient st

Re: [git-users] Re: git reset with staged changes

2014-06-03 Thread Dale R. Worley
> From: Pierre-François CLEMENT > Ah, my mistake I've misread you in the first place. You're right, it feels > natural they should return to their "untracked" state rather than being > deleted. And it sounds definitely possible to implement: git could just > check if the file was tracked or not b

Re: [git-users] Re: git reset with staged changes

2014-06-03 Thread Pierre-François CLEMENT
2014-06-03 17:03 GMT+02:00 André Hänsel : > On Tuesday, June 3, 2014 2:16:44 PM UTC+2, Pierre-François CLEMENT wrote: >> >> It seems logical to me that git-reset 's >> --hard option resets everything, what's staged, what's not, etc. I see it >> as a *"make my wor

[git-users] Re: git reset with staged changes

2014-06-03 Thread André Hänsel
On Tuesday, June 3, 2014 2:16:44 PM UTC+2, Pierre-François CLEMENT wrote: > > It seems logical to me that git-reset 's > --hard option resets everything, what's staged, what's not, etc. I see it > as a *"make my working dir in the exact same state as this commit

[git-users] Re: git reset with staged changes

2014-06-03 Thread Pierre-François CLEMENT
It seems logical to me that git-reset 's --hard option resets everything, what's staged, what's not, etc. I see it as a *"make my working dir in the exact same state as this commit"* command, which I believe it is. If you don't want it to reset your index or w