91–100 of 136 posts
They say it's for humans, but then explain the commands in terms of "normal git". This'd made a lot more sense for me if they explain for what particular workflow it's intended and how to use it as such. With examples and all.
Maybe I should update it to "Git for Humans (that already use git)"
Switch, synch, publish, unpublish - those all made sense, but when they started adding things like 'sprout' and 'graft' it just passed into the realm of trying to be too cute with the branching metaphor for my tastes. Personally, I'd pick git-flow over this. It seems more useful and makes, syntactically, more sense (though it can get a bit verbose at times `git flow feature start some-feature`). Starting and finishin…
Creator of Legit here. git-flow is awesome. I use it every day. This isn't so much of a branching model tool, but a tool that allows you to switch branches and interact with remotes very easily. When you switch branches with Legit, any pending changes you have made are stashed automatically. When you switch back, they are unstashed. This saves me a lot of typing. If you're following Vincent's branching model, switchi…
complement.
From the site: >Legit is a complimentary command-line interface for Git I do realize it's free, but I think you mean complementary.
Earlier quoted context omitted.
That's silly. As developers we constantly try to make better interfaces for our users. When it comes to our own tools we supposed to put up with difficult interfaces because that's the way it is? Engineers seem to treat mastering the command line and complex tools as a badge of honour, and as a way of differentiating themselves from the noobs. If there is really an easier way then is that really a bad thing?
> That's silly. As developers we constantly try to make better interfaces for our users. When it comes to our own tools we supposed to put up with difficult interfaces because that's the way it is? We're not talking about a different interface here but a new terminology. It's a bit like saying that you think English is too hard so you'll be communicating in Spanish from now on. This is not a realistic decision in a w…
The actual analogy you should have used is: English is too hard, so we will use simplified, task specific terminology (or better yet, pictographs) to ensure task specific communication in a multilingual environment.
When you are working in a multi lingual environment that has built in restrictions and a short list of common terminology (like at an assembly plant, or github commands) it is much easier/faster/simpler for a korean and brazilian (lets just say) to communicate using a short list of common, simplified, task specific english terms like "bathroom, please", "dangerous", "stop production", "broken", "connect here", "lift here", "this side up", that is oriented around the things they actually do at their job.
Hell, give this thing a GUI that is just a bunch of easy to recognize icons and you will have something approaching the real world solutions that are commonly recognized as best/safest practice.
I think the only two commands from this I like are `git sprout newbranch` and `git unpublish branch`. But only because I think `git checkout -b newbranch` and `git push origin :branch` are stupid syntaxes for doing what they do.
I agree regarding `git push origin :branch`. From the git man pages [0] > git push origin master:refs/heads/experimental Create the branch experimental in the origin repository by copying the current master branch. This form is only needed to create a new branch or tag in the remote repository when the local name and the remote name are different; otherwise, the ref name on its own will work. So, a direct substitutio…
PUT a branch refb with the commit-ish refa
PUT a branch refb with the commit-ish abc123
PUT a branch refa with the commit-ish nullEarlier quoted context omitted.
I'd be curious to see a few examples. Git is guilty of using a bunch of non-standard nomenclature, and of using existing terms in non-standard ways ("checkout", I'm looking at you). But I certainly wouldn't call the interface or syntax "inconsistent" or "random". It's actually very tersely designed and very well put together. The "actual concepts" are, for the most part, first class citizens in the interface.
> But I certainly wouldn't call the interface or syntax "inconsistent" or "random". Uhm, NO WAY. git checkout works on both branches and files. I can `checkout remote-name/branch` but I have to `push remote-name branch`. Deleting a local branch is `branch -D` but deleting a remote branch is (I still can't fucking believe it) `push remote :branch`. It's surprisingly hard to unstage a file. If a rebase fails, it gives…
git checkout my-file
git checkout HEAD -- my-file
Not inconsistent at all, as far as I can tell. In fact, most features of git that I use on a regular basis are completely consistent and orthogonal. The exceptions are submodules and remote cache branches...
Earlier quoted context omitted.
I found that the syntax _was_ the hard part of git. That and the often-terrible man pages. Both docs and syntax are inconsistent, verging on random, and full of irrelevant details. It's pretty hard to figure out the actual concepts beneath all the noise and misdirection. the git vs EasyGit diff basically summarizes what I'd change about git.
I'd be curious to see a few examples. Git is guilty of using a bunch of non-standard nomenclature, and of using existing terms in non-standard ways ("checkout", I'm looking at you). But I certainly wouldn't call the interface or syntax "inconsistent" or "random". It's actually very tersely designed and very well put together. The "actual concepts" are, for the most part, first class citizens in the interface.
git tag git stashList tags/stashes:
git stash list
git tag [-l]Seems like a cool idea, but would be way (I've never even heard of the pip command before) better if it could be installed in one command. See http://betterthangrep.com/ , https://github.com/defunkt/gist or http://beginrescueend.com/ .
http://pypi.python.org/pypi/pip
Pip compared to easy_install:
Earlier quoted context omitted.
I agree regarding `git push origin :branch`. From the git man pages [0] > git push origin master:refs/heads/experimental Create the branch experimental in the origin repository by copying the current master branch. This form is only needed to create a new branch or tag in the remote repository when the local name and the remote name are different; otherwise, the ref name on its own will work. So, a direct substitutio…
git push origin refa:refb PUT a branch refb with the commit-ish refa git push origin abc123:refb PUT a branch refb with the commit-ish abc123 git push origin :refa PUT a branch refa with the commit-ish null