On Fri, 29 Jan 2010 13:34:01 -0800, Ron Garret <ron1@xxxxxxxxxxx> wrote:
In article <op.u7a909hf4oyyg1@alvarezp-ws>,
"Octavio Alvarez" <alvarezp@xxxxxxxxxxxxxxxx> wrote:
On Fri, 29 Jan 2010 12:20:46 -0800, Ron1 <ron1@xxxxxxxxxxx> wrote:
It means that if you switch to master^ and commit, your commit will
be applied but not tracked (since there is not any branch to advance).
You would need to do git checkout -b 'new_branch', and then commit.
Now, new_branch will advance with your new commit.
OK, I think I understand that.
Here's the thing: I can do this:
git checkout commit-id filename
and restore a particular revision of a particular file to my working
tree without affecting my HEAD pointer. I would expect then that
git checkout commit-id
with no filename would do the same thing, except restore the entire tree
from that commit (including deleting files that didnt' exist then). And
indeed it does that (or at least appears to -- I haven't explored this
in depth), except that it DOES move my HEAD pointer to this weird
non-branch thing.
I see. You somehow imply that "git checkout commit-id" overlaps with
"git reset --hard commit-id".
Even assuming the behavior was not documented in man git-checkout, the
second example looks useless. What is your use case? What would you do
after having all the files in the tree switched to another commit,
without actually updating HEAD to the commit, other than git reset --hard
again or git revert?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html