71–80 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.
I understand that Git is a fairly complex utility. But you can accomplish a lot just memorizing about 5 Git commands and what they do. Besides, if you decide to use an abstraction such as this one without understanding the plumbing, what do you do when 'git sync' fails due to conflicts?
When a merge fails, it gets you out of the merge conflict state and prints a nice message about what to do next.
It's probably better to just write one's own wrapper for git that best fits you/your company's workflow, especially if it's for your company, since you can better justify the time spent writing the wrapper code. As a point of reference, the company I work at (five devs total) is moving off cvs(!!!) to git, but writing a wrapper tool to git to create branches and set them up in the manner we need for our product.
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, switching from `feature/x` to `develop` happens quite a bit. So, they compliment each other well.
Earlier quoted context omitted.
It seems like the use case he's optimizing for here is if you're accidentally on the wrong branch, and need to move your working changes over to the correct branch. Personally, I almost always use stash if I'm not quite ready to commit, but need to quickly fix a bug that takes precedence over whatever I'm currently working on. I stash what I'm doing, fix it, and them come back. Some of these operations seem at odds w…
I've used that workflow too. What disturbs me about the `git switch` proposed here is the unstashing. I think the intended optimization is more general: when you're trying to switch to another branch for any reason but git doesn't let you because of unsaved changes. But your use case of being on the wrong branch seems like the actual optimization for a fairly (at least for me) uncommon workflow. More frequently I, li…
Earlier quoted context omitted.
It seems like the use case he's optimizing for here is if you're accidentally on the wrong branch, and need to move your working changes over to the correct branch. Personally, I almost always use stash if I'm not quite ready to commit, but need to quickly fix a bug that takes precedence over whatever I'm currently working on. I stash what I'm doing, fix it, and them come back. Some of these operations seem at odds w…
I've used that workflow too. What disturbs me about the `git switch` proposed here is the unstashing. I think the intended optimization is more general: when you're trying to switch to another branch for any reason but git doesn't let you because of unsaved changes. But your use case of being on the wrong branch seems like the actual optimization for a fairly (at least for me) uncommon workflow. More frequently I, li…
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/ .
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.
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 you exactly one warning and then forever complains about a dirty index tree. The error messages are borderline incomprehensible for someone who doesn't understand git internals (refs/head say what?). The reset command is far to easy to typo into oblivion.
What else. I haven't spent a lot of time thinking about it, but obtaining an exact list of differences between branches is hard (git `log sha1..sha1` compared with `git log sha1...sha1`).
This is just off the top of my head. Git is great, it's fast, I don't understand people who are still on svn, but the user interface is abysmal.
EasyGit, single script, very well thought out, longstanding tested project, doesn't "conflict with" or conceal the underlying git just fixes up the UI. http://people.gnome.org/~newren/eg/ https://github.com/blog/333-easy-git
If you know what these commands are doing under the covers, these commands are a true time saver. If you don't know what these commands are doing, they're basically "magic" and in the hands of inexperienced developers could be harmful to their education on Git.
I completely agree. I hope to add a `verbose` mode that prints every git command that is being run under the covers. It could be a good teaching tool perhaps?