"git reset" and newly created files.

"git reset" and newly created files.

[Junio C Hamano]

When you made a mistake and committed a set of incomplete
changes, the "git reset" command comes handy.

    ... Edit, compile, and test.
    $ git commit -s -m 'The perfect change.'
    ... Test again, OOPS it fails --- it was not perfect.
    $ git reset HEAD^
    foo: needs update
    bar: needs update

The commit object name for the botched commit is kept in the
$GIT_DIR/ORIG_HEAD file, the HEAD commit and the index file are
"reset" to the commit before ORIG_HEAD.  The files in the
working tree are not touched and they are the same as what are
in ORIG_HEAD.  The command tells which files in the working tree
are different from the HEAD commit.

So you would naturally be tempted to do this:

    ... Re-edit, compile, and test.  This time it is perfect.
    $ git commit -a -C ORIG_HEAD

Well, not really.  You can lose any file newly created in
ORIG_HEAD this way.  Instead, you need to do this:

    ... Re-edit, compile, and test.  This time it is perfect.
    $ git add <whatever file you have changed>
    $ git commit -a -C ORIG_HEAD

Do people find this a big problem?

Technically, what "git reset" does is correct, because its
definition says the index file is reset to what was in HEAD,
which did not know about the files added by the ORIG_HEAD, and
there is no way for it to keep an eye on the file you wanted to
add in the botched ORIG_HEAD commit.

But it does not _feel_ right.

This relates to the fact that there currently is no way to
record "intent to add" (aka "please keep an eye on") in the
index file.  I think we could solve this with something like
this:

    $ git-update-cache --add-maybe foo
    $ git status
    # Changed but not updated:
    #   (use git-update-cache to mark for commit)
    #
    #       new file: foo
    $ git-update-cache --refresh
    foo: needs update
    $ git-update-cache foo
    $ git status
    # Updated but not checked in:
    #   (will commit)
    #
    #       new file: foo

The "git reset" command should be able to detect the paths found
in ORIG_HEAD but lacking in HEAD, reset the index to HEAD and
say "git-update-cache --add-maybe" for such paths.

Hmm?

Re: "git reset" and newly created files.

[Sam Ravnborg]

> 
> So you would naturally be tempted to do this:
> 
>     ... Re-edit, compile, and test.  This time it is perfect.
>     $ git commit -a -C ORIG_HEAD
> 
> Well, not really.  You can lose any file newly created in
> ORIG_HEAD this way.  Instead, you need to do this:
> 
>     ... Re-edit, compile, and test.  This time it is perfect.
>     $ git add <whatever file you have changed>
>     $ git commit -a -C ORIG_HEAD
> 
> Do people find this a big problem?

I often do some maybe not that brilliant changes in my tree,
and when I then ask git to reset these I expect git to reset
everything.

After a git-reset HEAD^ I really expect git to have rewinded back till
where I started with no files added whatsoever.

>From the matter of least suprise git should not remember files added,
one have to do that by themself again if needed.

	Sam

Re: "git reset" and newly created files.

[Junio C Hamano]

Sam Ravnborg <sam@ravnborg.org> writes:

>> So you would naturally be tempted to do this:
>> 
>>     ... Re-edit, compile, and test.  This time it is perfect.
>>     $ git commit -a -C ORIG_HEAD
>> 
>> Well, not really.  You can lose any file newly created in
>> ORIG_HEAD this way.  Instead, you need to do this:
>> 
>>     ... Re-edit, compile, and test.  This time it is perfect.
>>     $ git add <whatever file you have changed>
>>     $ git commit -a -C ORIG_HEAD
>> 
>> Do people find this a big problem?
>
> I often do some maybe not that brilliant changes in my tree,
> and when I then ask git to reset these I expect git to reset
> everything.
>
> After a git-reset HEAD^ I really expect git to have rewinded back till
> where I started with no files added whatsoever.

That is another thing I initially expected from the "git reset"
command, but I do not think that is what this command is about.
It is about reverting your working tree and index file to the
state just before you make your commit to create the botched
commit, so that you can make minor fixes and recommit.

Viewing it that way, it might even be a good idea to "git add"
the files that are in ORIG_HEAD but not in the head you are
"resetting" to.

> From the matter of least suprise git should not remember files added,
> one have to do that by themself again if needed.

What I was getting at was that doing things that way means new
files and modified files are handled inconsistently.  With the
current implementation, git "remembers" the files modified, but
not files added.  And if the purpose of "reset" is to eventually
re-commit, it would be useful if git remembers both, not just
modified files.

One way to achieve that would be "git-update-cache --add-maybe"
I talked about in the original message, but at least something
like the following would still be an improvement.  Instead of
echoing the output from diff-tree, we might even be better off
if we just feed it to "xargs git-update-cache --add".

------------
[PATCH] Remind the user of "about to be lost" files. 

Files that are in the current HEAD but not in the head we are
resetting to can easily be lost when "git reset HEAD^" is
followed by re-edit and "git commit".

This patch reminds the user about those files.

Signed-off-by: Junio C Hamano <junkio@cox.net>

---

diff --git a/git-reset-script b/git-reset-script
--- a/git-reset-script
+++ b/git-reset-script
@@ -6,6 +6,16 @@ git-read-tree --reset "$rev" && {
 	if orig=$(git-rev-parse --verify HEAD 2>/dev/null)
 	then
 		echo "$orig" >"$GIT_DIR/ORIG_HEAD"
+
+		# Remind the user about files that are in ORIG_HEAD
+		# but not in $rev.  We would really want to do
+		# "git-update-cache --add-maybe" on these paths, but
+		# that is not available (yet).
+		git-diff-tree -r --diff-filter=D $rev ORIG_HEAD |
+		while path
+		do
+			echo "$path: needs add"
+		done
 	fi
 	echo "$rev" > "$GIT_DIR/HEAD"
 }