131–136 of 136 posts
Earlier quoted context omitted.
Indeed no. That's exactly what git reset does: "copy entries from to the index". I got that from the unusably bad man page. It was the first sentence.
My question was a rhetorical one :)
Earlier quoted context omitted.
It worked on a branch, filtered by a file name. I think that's an important distinction. That distinction unifies the definition of `git checkout`.
But But it doesn't lead to an obvious, consistent command syntax, and that was the point.
Earlier quoted context omitted.
But But it doesn't lead to an obvious, consistent command syntax, and that was the point.
It's a consistent syntax with smart defaults you can leave out. You wouldn't say Unix's wc is inconsistent, would you, just because it has default behavior?
Better example is tar vs cp, where you go
cp files you want to copy destination/
tar destination.tar files you want to archive
Earlier quoted context omitted.
> git push heroku staging:master Without the shortcuts, this command would be: git push heroku refs/heads/staging:refs/heads/master "refs/heads/master" is literally the branch location in the $GIT_DIR on the remote. You could do something like: git push heroku staging:refs/personal/phillmv/staging to stick the branch in a non-standard location, or you could do: git push ssh://hostname/path/to/repo staging:staging or:…
Huh. Out of curiosity, why would I ever want to do this? > git push heroku staging:refs/personal/phillmv/staging Will it still appear in git branch lists? I get what you're saying and I appreciate the lesson :). Is there a reason for the syntax in checkout being remote/branchname then? I care about consistency more than the specific syntax.
> Will it still appear in git branch lists?
> Is there a reason for the syntax in checkout
> being remote/branchname then? I care about
> consistency more than the specific syntax.
The right side of the ':' in the git-push command resolves on the remote repo, but git-checkout resolves in your local repo.
Also look at the git-rev-parse manpage for info on the resolve order/etc for branch name shortcuts. It's the 3rd bullet point under 'Specifying Revisions.'
Earlier quoted context omitted.
+1, If you just take 2 hours and read the entirety of progit.org (including the section on internals) all of these workflows on top of git start to look unnecessarily confusing.
-1, as a git user who finally submitted to learning the internals, I think this is not the right way to design software. I realize linux/et al are all geek inspired technology festivals, but to imply that a good User Interface and human accessible commands are unnecessary is... silly, the rhetoric reminds me of the elitist GNU/linux propeller heads back in 1999 who would constantly and derisively snort in disdain at…
Earlier quoted context omitted.
It's a consistent syntax with smart defaults you can leave out. You wouldn't say Unix's wc is inconsistent, would you, just because it has default behavior?
Apples to Oranges. wc is a bad example. Better example is tar vs cp, where you go cp files you want to copy destination/ and tar destination.tar files you want to archive And yes, I would say that's inconsistent.
wc is "word count" it's not a sane default. it's a obviously explicitly behavior. if git checkout were called 'git checkbranch' then you would have a point.
tar does not have sane defaults. it requires explicit flags. your example (besides not working because as i said, it does not have defaults) could very well be `tar -c files you want to copy -f destination.tar` and all would be well. you actually still repeat the very first tar command line example you ever saw to this day, even not agreeing with it :)