5 ms·

To be honest I don't see the issue at all here. Fundamentally the following all make sense to me intuitively: git checkout dir (lets assume cwd is in a git

by mitchty 13y ago

To be honest I don't see the issue at all here. Fundamentally the following all make sense to me intuitively: git checkout dir (lets assume cwd is in a git repo) cd dir && git checkout . And for completeness: git checkout file I don't buy the argument that something could be a path or a ref is bad in this case. It allows for both common cases simply. Want to update a single file/directory git checkout that file. Want to checkout a revision? Checkout the sha1hash. Basically what I'm saying here, is reusing '.' is more of a problem for hg in that they're repurposing an already common idiom in unix. If my arguments to why aren't convincing we'll have to disagree that this is a git "fault" or "inconsistent ui". I think of it as neither however.

jordigh 13y ago
This is not "completeness". These are fundamentally different things, like I explained in another comment. You even used a different verb for the file case, "update a file", which coincidentally matches closer the verb that hg uses, "update". Here, this is a funnier way to explain why "git checkout" is such a weird command: http://stevelosh.com/blog/2013/04/git-koans/#one-thing-well http://stevelosh.com/blog/2013/04/git-koans/#one-thing-well
- mitchty 13y ago
  I'm not sure where I used completeness in my argument prior? Updating a file and updating a directory to me are effectively the same thing. The fact that git checkout can accept either a filename/directoryname, or a revision strikes me as no worse/better than the alternative in hg. That is: git checkout file/directory git checkout revision Is no better/worse than: hg revert file/directory hg update -r revision (or wherever . is actually used, i'll admit I've never used it in mercurial) In fact in many ways the git methodology maps closer to how english verbs are overloaded as well. That is, we're checking out some file/directory named whatever back to its last known good value, or we're checking out everything to a specific revision (I'll omit every option possible for brevity). Its rather easily parsed and explained to humans. The mercurial versions to be honest seem more pedantic than intuitive. I have to use both and vastly prefer the git way in this regard. But to each his own. The link is cute but I couldn't get past the first few paragraphs. It is trying a bit too hard to be funny/cute for my tastes. That said I looked at the listings of things that are messed up and sure I don't argue that git has an "intuitive" interface by any means in regards to listing tags/revisions. But this one point I don't see as its most glaring of issues. If its that big of an issue just do what I do and create a git alias in .gitconfig to call the arcane incantation of magick. Then it doesn't really matter how inconsistent it is. Eh enough not working for me, tschuss!

by mitchty 13y ago

jordigh 13y ago

This is not "completeness". These are fundamentally different things, like I explained in another comment. You even used a different verb for the file case, "update a file", which coincidentally matches closer the verb that hg uses, "update". Here, this is a funnier way to explain why "git checkout" is such a weird command: http://stevelosh.com/blog/2013/04/git-koans/#one-thing-well http://stevelosh.com/blog/2013/04/git-koans/#one-thing-well

mitchty 13y ago
I'm not sure where I used completeness in my argument prior? Updating a file and updating a directory to me are effectively the same thing. The fact that git checkout can accept either a filename/directoryname, or a revision strikes me as no worse/better than the alternative in hg. That is: git checkout file/directory git checkout revision Is no better/worse than: hg revert file/directory hg update -r revision (or wherever . is actually used, i'll admit I've never used it in mercurial) In fact in many ways the git methodology maps closer to how english verbs are overloaded as well. That is, we're checking out some file/directory named whatever back to its last known good value, or we're checking out everything to a specific revision (I'll omit every option possible for brevity). Its rather easily parsed and explained to humans. The mercurial versions to be honest seem more pedantic than intuitive. I have to use both and vastly prefer the git way in this regard. But to each his own. The link is cute but I couldn't get past the first few paragraphs. It is trying a bit too hard to be funny/cute for my tastes. That said I looked at the listings of things that are messed up and sure I don't argue that git has an "intuitive" interface by any means in regards to listing tags/revisions. But this one point I don't see as its most glaring of issues. If its that big of an issue just do what I do and create a git alias in .gitconfig to call the arcane incantation of magick. Then it doesn't really matter how inconsistent it is. Eh enough not working for me, tschuss!