Re: master^ is not a local branch -- huh?!?
- From
- Ron Garret <ron1@flownet.com>
- Date
- Jan 30, 2010, 06:16 UTC
- Message-ID
- <ron1-FA4289.22165129012010@news.gmane.org>
- In-Reply-To
- <7vvdek70ma.fsf@alter.siamese.dyndns.org>
In article <7vvdek70ma.fsf@alter.siamese.dyndns.org>, Junio C Hamano <gitster@pobox.com> wrote:
Show 8 quoted lines
> Michael Witten <mfwitten@gmail.com> 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.
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