Re: master^ is not a local branch -- huh?!?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



In article <7vvdek70ma.fsf@xxxxxxxxxxxxxxxxxxxxxxxx>,
 Junio C Hamano <gitster@xxxxxxxxx> wrote:

> Michael Witten <mfwitten@xxxxxxxxx> 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

--
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]