Re: Git reset --hard with staged changes

On Tue, May 31, 2016 at 8:02 AM, Junio C Hamano wrote: > > diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt > index 25432d9..c4cc035 100644 > --- a/Documentation/git-reset.txt > +++ b/Documentation/git-reset.txt > @@ -65,8 +65,14 @@ If `-N` is specified,

Re: Git reset --hard with staged changes

Yotam Gingold writes: > I read Junio's enumerations of the situations, and I appreciate that the > current behavior of git reset --hard cannot be changed because of the > many tools that rely on the current behavior. After reading it, I have > modified my proposed

Re: Git reset --hard with staged changes

> On May 24, 2016, at 2:20 AM, Christian Couder > wrote: > > On Mon, May 23, 2016 at 11:16 PM, Junio C Hamano wrote: >> >> >> I am not sure if that is a good addition, though. > > I am not sure either, but at least if something like that is

Re: Git reset --hard with staged changes

On Mon, May 23, 2016 at 11:16 PM, Junio C Hamano wrote: > Christian Couder writes: > >>> This should be clarified to define what a tracked file is. I propose >>> appending: >>> >>> A file is considered tracked if it exists in a prior commit or

Re: Git reset --hard with staged changes

Christian Couder writes: >> This should be clarified to define what a tracked file is. I propose >> appending: >> >> A file is considered tracked if it exists in a prior commit or in the >> staging area. Note that a newly added file not in any prior commit

Re: Git reset --hard with staged changes

On Mon, May 23, 2016 at 2:55 AM, Yotam Gingold wrote: > Pierre-François CLEMENT gmail.com> writes: >> 2014-06-10 17:27 GMT+02:00 David Kastrup gnu.org>: >>> Pierre-François CLEMENT gmail.com> writes: >>> ... Hm I see. Even though the documentation doesn't

Re: Git reset --hard with staged changes

Yotam Gingold writes: > --hard Resets the index and working tree. Any changes to tracked files in the > working tree since are discarded. > > This should be clarified to define what a tracked file is. A "tracked file" in that sentence is a file that is not untracked, I

Re: Git reset --hard with staged changes

Pierre-François CLEMENT gmail.com> writes: > 2014-06-10 17:27 GMT+02:00 David Kastrup gnu.org>: >> Pierre-François CLEMENT gmail.com> writes: >> >>> ... >>> >>> Hm I see. Even though the documentation doesn't make it very clear >>> about what happens to such files, it turns out the scenario we

Re: Git reset --hard with staged changes

2014-06-10 1:28 GMT+02:00 Junio C Hamano gits...@pobox.com: Pierre-François CLEMENT lik...@gmail.com writes: Hm, I didn't think of git apply --index... Makes sense for this special use, but I'm not sure about the other use cases. Try merging another branch that tracks a file your current

Re: Git reset --hard with staged changes

Pierre-François CLEMENT lik...@gmail.com writes: 2014-06-10 1:28 GMT+02:00 Junio C Hamano gits...@pobox.com: Pierre-François CLEMENT lik...@gmail.com writes: Hm, I didn't think of git apply --index... Makes sense for this special use, but I'm not sure about the other use cases. Try merging

Re: Git reset --hard with staged changes

2014-06-10 17:27 GMT+02:00 David Kastrup d...@gnu.org: Pierre-François CLEMENT lik...@gmail.com writes: 2014-06-10 1:28 GMT+02:00 Junio C Hamano gits...@pobox.com: Pierre-François CLEMENT lik...@gmail.com writes: Hm, I didn't think of git apply --index... Makes sense for this special use,

Re: Git reset --hard with staged changes

Hi all, Someone pointed out on the Git for human beings Google group (https://groups.google.com/d/topic/git-users/27_FxIV_100/discussion) that using git-reset's hard mode when having staged untracked files simply deletes them from the working dir. Since git-reset specifically doesn't touch

Re: Git reset --hard with staged changes

Pierre-François CLEMENT lik...@gmail.com writes: Hi all, Someone pointed out on the Git for human beings Google group (https://groups.google.com/d/topic/git-users/27_FxIV_100/discussion) that using git-reset's hard mode when having staged untracked files simply deletes them from the working

Re: Git reset --hard with staged changes

2014-06-09 16:04 GMT+02:00 David Kastrup d...@gnu.org: Pierre-François CLEMENT lik...@gmail.com writes: Hi all, Someone pointed out on the Git for human beings Google group (https://groups.google.com/d/topic/git-users/27_FxIV_100/discussion) that using git-reset's hard mode when having

Re: Git reset --hard with staged changes

Pierre-François CLEMENT lik...@gmail.com writes: Hm, I didn't think of git apply --index... Makes sense for this special use, but I'm not sure about the other use cases. Try merging another branch that tracks a file your current branch does not know about and ending up with conflicts during

Re: Git reset --hard with staged changes

From: Pierre-François CLEMENT likeyn at gmail.com You create a new (untracked) file. You use git-reset's hard mode to go one commit back, the new (untracked) file's still there. You add/stage that new file. You use git-reset's hard mode again to go one commit back, and the new untracked file

Re: Git reset --hard with staged changes

Dale Worley wor...@alum.mit.edu writes: (As far as I can tell from Git's behavior, the definition of tracked file is any file that is in the base commit or in the index. Based on that definition, git reset --hard is working as documented.) The book (whichever book you guys are talking about)