From: Junio C Hamano <junkio@cox.net>
To: Linus Torvalds <torvalds@osdl.org>
Cc: git@vger.kernel.org
Subject: "git reset" and newly created files.
Date: Sun, 21 Aug 2005 12:31:19 -0700 [thread overview]
Message-ID: <7vbr3rccjc.fsf@assigned-by-dhcp.cox.net> (raw)
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?
next reply other threads:[~2005-08-21 21:26 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-21 19:31 Junio C Hamano [this message]
2005-08-21 21:46 ` "git reset" and newly created files Sam Ravnborg
2005-08-22 8:17 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vbr3rccjc.fsf@assigned-by-dhcp.cox.net \
--to=junkio@cox.net \
--cc=git@vger.kernel.org \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox