Sverre Rabbelier [off-list ref] writes:
On Fri, Jan 29, 2010 at 22:24, Ron Garret [off-list ref] wrote:
quoted
Yes, I read that. But what I'm trying to do is not just *look* at the
history, I want to restore my working tree to a previous version. The
"Exploring History" section of the docs doesn't say how to do that.
Do you want to restore your working tree only, or also throw away the
history? If the former, you could look at 'git revert',...
I think he wanted to check paths out of a commit and the set of paths
happened to be "everything".
IOW, "checkout $commit ."
In article [off-list ref],
Junio C Hamano [off-list ref] wrote:
Sverre Rabbelier [off-list ref] writes:
quoted
On Fri, Jan 29, 2010 at 22:24, Ron Garret [off-list ref] wrote:
quoted
Yes, I read that. But what I'm trying to do is not just *look* at the
history, I want to restore my working tree to a previous version. The
"Exploring History" section of the docs doesn't say how to do that.
Do you want to restore your working tree only, or also throw away the
history? If the former, you could look at 'git revert',...
I think he wanted to check paths out of a commit and the set of paths
happened to be "everything".
IOW, "checkout $commit ."
Yes!!! That's it exactly!
rg
On Fri, Jan 29, 2010 at 4:12 PM, Ron Garret [off-list ref] wrote:
In article [off-list ref],
Junio C Hamano [off-list ref] wrote:
quoted
Sverre Rabbelier [off-list ref] writes:
quoted
On Fri, Jan 29, 2010 at 22:24, Ron Garret [off-list ref] wrote:
quoted
Yes, I read that. But what I'm trying to do is not just *look* at the
history, I want to restore my working tree to a previous version. The
"Exploring History" section of the docs doesn't say how to do that.
Do you want to restore your working tree only, or also throw away the
history? If the former, you could look at 'git revert',...
I think he wanted to check paths out of a commit and the set of paths
happened to be "everything".
IOW, "checkout $commit ."
Yes!!! That's it exactly!
However, that updates the index and doesn't delete files that didn't
exist in $commit, and you said earlier that you don't want to update
the index (though perhaps you didn't really know what you wanted
there).
My idea:
Isn't the difference between 'checkout' and 'reset' almost essentially
a matter of whether the branch reference (HEAD), index, and tree are
modified? Couldn't these commands be merged into one command or make
use of one command?
Rather than relying on flags like --hard, --soft, and --mixed, why not
*also* provide flags for specifying at a finer granularity what is
desired for the index, working tree, and HEAD.
Then:
git checkout $commit
does a lot of its work through something like:
git update --index --tree --detach $commit
Also:
git checkout $commit $f
translates:
git update --index --tree --keep-tracked-files $commit $f
Also:
git reset [--mixed] $commit
translates:
git update --index --head $commit
Also:
git reset --soft $commit
translates:
git update --head $commit
Also:
git reset --hard $commit
translates:
git update --index --tree --head $commit
And so on.
In fact, with --no-* flags, you could modify 'reset' and 'checkout'
commands from their defaults. So, to update all of the paths
(including deleting tracked files not in $commit), but keep the index
untouched, we have:
git checkout --no-update-index --no-update-keep-files $commit .
Of course, you might as well just use the hypothetical 'update'
command directly:
git update --tree $commit .
Sincerely,
Michael Witten
Michael Witten [off-list ref] writes:
Isn't the difference between 'checkout' and 'reset' almost essentially
a matter of whether the branch reference (HEAD), index, and tree are
modified? Couldn't these commands be merged into one command or make
use of one command?
I don't think that reduces any confusion.
By exposing orthogonal options like --index, --head, etc., you are opening
yourself to nonsensical combinations that were never possible with the
existing command set, and I suspect it would make it even more confusing,
not less.
What does "git update --detach $commit" _really_ mean, for example?
You can of course say "it detaches the HEAD at $commit, but otherwise does
not change anything else", but such a mechanical description does not give
an answer that helps end users. "What would I do after doing that?" and
"What would I use this for?" are the questions they need an answer to.
What matters is "after doing this, next commit will record _this_, which
is often what users want in _that_ situation, and that is why this
combination of options makes sense." Do all (or majority) of option
combinations to your "update" think have _meaning_ in that sense? I don't
think so.
Flexibility and orthogonality is often good, but uncontrolled flexibility
is not. And I suspect your "git update" is just an uncontrolled mess that
would not help users [*1*].
[Footnote]
*1* It is a different matter to have something like that as an ingredient
to build Porcelain scripts out of. Porcelain writers may appreciate the
flexibility and they will choose to use only combinations that make sense
for the situation they are trying to deal with.
In article [off-list ref],
Junio C Hamano [off-list ref] wrote:
Michael Witten [off-list ref] writes:
quoted
Isn't the difference between 'checkout' and 'reset' almost essentially
a matter of whether the branch reference (HEAD), index, and tree are
modified? Couldn't these commands be merged into one command or make
use of one command?
I don't think that reduces any confusion.
Ahem... as the confused one here I respectfully disagree.
By exposing orthogonal options like --index, --head, etc., you are opening
yourself to nonsensical combinations that were never possible with the
existing command set, and I suspect it would make it even more confusing,
not less.
No, because it would make it much easier to map intent back into a
command that implements that intent. Don't forget, this whole thing
began because I wanted to do something very simple, tried what seemed to
be the obvious way to do it, and stumbled accidentally on an advanced
feature. That would not have happened if I'd been able to just do a git
update --tree master^.
What does "git update --detach $commit" _really_ mean, for example?
What difference does that make? Sure, there would be ways to shoot
yourself in the foot with git update, but there is no shortage of ways
to shoot yourself in the foot now. And now if you shoot yourself in the
foot you have to start by trying to figure out where the bullet came
from.
BTW, nothing prevents you from providing the usual repertoire of
higher-level functionality as thin layers on top of something like git
update.
You can of course say "it detaches the HEAD at $commit, but otherwise does
not change anything else", but such a mechanical description does not give
an answer that helps end users. "What would I do after doing that?" and
"What would I use this for?" are the questions they need an answer to.
Sure. So document the combinations that make sense, and then say "You
can mix and match the options in other ways, but you probably shouldn't
unless you really know what you're doing." Done.
Flexibility and orthogonality is often good, but uncontrolled flexibility
is not.
That seems to me to run directly counter to the design philosophy behind
git.
rg