8 ms·

Those who think a wrapper is going to help their development is in for something when things break and they don't know how to operate things the way they're mea

Those who think a wrapper is going to help their development is in for something when things break and they don't know how to operate things the way they're meant to. git is an especially poor choice for wrappers. You're hiding the concepts of staged and unstaged information, branches, tags, remotes, submodules. Regardless of VCS, you're setting yourself up for failure when you buy into a third-party tool's workflow rather than knowing what the hell you're doing. Pick up git as you go along. Rather than a tool doing who knows what behind the scene. If you really goof things when you're starting, don't be afraid to git reset --hard <ref> / git commit --amend + force push, as long as you know where you're at in history.

kevingoslar 9y ago
Git Town doesn't replace Git, nor does it try to shield you from learning how Git works. It shows the Git commands it runs for you, as well as their output. When using it, one should make sure to understand what it is doing. The thing is, Git is awesome, but intentionally designed as a low-level and generic tool. Using it correctly for particular workflows (like Git Flow or Github Flow) requires running many Git commands for each operation, and is highly repetitive. Good developers engineer repetition away. Great developers share what they build. Hence Git Town.
- nolemurs 9y ago
  > Good developers engineer repetition away. Great developers share what they build. Hence Git Town. Sure, but a handful of of bash and/or git aliases handles that just fine while also being better suited to a user's particular workflow and easier to learn.
  - allover 9y ago
    If you're trying to achieve a workflow like 'Git Flow' [1], having everyone in your team attempt it manually with their own home-brew aliases is going to go very badly. [1] http://nvie.com/posts/a-successful-git-branching-model/ http://nvie.com/posts/a-successful-git-branching-model/
- git-pull 9y ago
  > Good developers engineer repetition away. Great developers share what they build. Hence Git Town. As someone who has engineered repetition away and shares what he builds, I agree, and admire your gumption. > intentionally designed as a low-level and generic tool. git is high level. and opinionated. It has branches and tags baked right in. Compare to SVN or CVS where the support is second class. > requires running many Git commands for each operation, and is highly repetitive. I run lots of git commands by hand, and can be pretty verbose in commit messages. I (sort of) try to follow this: https://chris.beams.io/posts/git-commit/ https://chris.beams.io/posts/git-commit/ However, to speed things up, I will sometimes at shell prompt use `ctrl-r` and search history a bit, then `ctrl-e` to start scrolling in a line brought back up if I want to both 1. see what I committed last, and 2. get a head start on writing the commit message. I also find the staging workflow git has (another thing I personally consider high-level, purposeful, opinionated to git, and use regularly) to be very convenient. I can type `git status`, `git diff`, `git diff --cached` to see what's staged and unstaged. I can use `git reset` to unstage a file. Overall, I get more granularity on which files I want to add to that commit. This comes in really handing when reverting, merging and rebasing. So in my workflow, I don't want to give up control of these things. Apparently, while I don't use these features, `git bisect` and `git blame` also benefit from being thoughtful with commits. > It shows the Git commands it runs for you, as well as their output. I am glad to hear that. > nor does it try to shield you from learning how Git works This is what irks me. I view git as high level and opinionated already, and have no way of knowing how it would effect someone learning git. I developed my own habits w/ VCS a long time ago. That said, leave it up to the people who want to try your project. (I followed you and starred your repository.)
  - crdoconnor 9y ago
    >This is what irks me. I view git as high level and opinionated already However high level you think it is, it has no opinion on workflows and there's a need for a tool that will automate and enforce git workflows. I'm not sure if this tool the answer, but there is a need for some sort of tool like this. I wrote a hacky 'git sync' script at an old company and it achieved what sending a bunch of developers on a course about git did not (it sped up the workflow and cut down on git errors).
humanrebar 9y ago
I mostly agree but we don't exactly expect devs to call gcc or javac directly. Make, maven, Gradle, etc. all have their place as well.
- throwme_1980 9y ago
  comparing this glorified set of aliases to Maven and gcc shows a fundamental misunderstanding of said tools
  - humanrebar 9y ago
    ...you're just overanalyzing what I said. I just meant that git stays out of the workflow business and higher level tools might be able to fill in the gap. I'm not sure I'd use this tool, but I'm not going to get upset if people like it.
throwme_1980 9y ago
This right here, this thing will only attract new developers and will delay the inevitable - which is learning git properly. Reminds of a banana peeling machine ....
Certhas 9y ago
The git model for a context where not everyone is a software developer is: Use these three git commands you have memorized. If something breaks ask the person who understands git. That is the reality. Anything that makes people more productive, especially in contexts where the difference between staged/unstaged and all the other things you mention, don't matter, is very very welcome.
saurik 9y ago
While I absolutely agree that you should know how your underlying tools work--and the way I teach people git is to start at the representation level and work up, showing all the file formats in play so people can see how it actually works--I disagree that "git is an especially poor choice for wrappers"... almost all of the tools people normally use with git--the ones that come with git and one might argue "are git"--are also just wrappers (called "porcelain") over lower level tools... most people I know who feel they are sufficient in git only actually know how to use these higher-level tools.

kevingoslar 9y ago

Git Town doesn't replace Git, nor does it try to shield you from learning how Git works. It shows the Git commands it runs for you, as well as their output. When using it, one should make sure to understand what it is doing. The thing is, Git is awesome, but intentionally designed as a low-level and generic tool. Using it correctly for particular workflows (like Git Flow or Github Flow) requires running many Git commands for each operation, and is highly repetitive. Good developers engineer repetition away. Great developers share what they build. Hence Git Town.

nolemurs 9y ago
> Good developers engineer repetition away. Great developers share what they build. Hence Git Town. Sure, but a handful of of bash and/or git aliases handles that just fine while also being better suited to a user's particular workflow and easier to learn.
- allover 9y ago
  If you're trying to achieve a workflow like 'Git Flow' [1], having everyone in your team attempt it manually with their own home-brew aliases is going to go very badly. [1] http://nvie.com/posts/a-successful-git-branching-model/ http://nvie.com/posts/a-successful-git-branching-model/
git-pull 9y ago
> Good developers engineer repetition away. Great developers share what they build. Hence Git Town. As someone who has engineered repetition away and shares what he builds, I agree, and admire your gumption. > intentionally designed as a low-level and generic tool. git is high level. and opinionated. It has branches and tags baked right in. Compare to SVN or CVS where the support is second class. > requires running many Git commands for each operation, and is highly repetitive. I run lots of git commands by hand, and can be pretty verbose in commit messages. I (sort of) try to follow this: https://chris.beams.io/posts/git-commit/ https://chris.beams.io/posts/git-commit/ However, to speed things up, I will sometimes at shell prompt use `ctrl-r` and search history a bit, then `ctrl-e` to start scrolling in a line brought back up if I want to both 1. see what I committed last, and 2. get a head start on writing the commit message. I also find the staging workflow git has (another thing I personally consider high-level, purposeful, opinionated to git, and use regularly) to be very convenient. I can type `git status`, `git diff`, `git diff --cached` to see what's staged and unstaged. I can use `git reset` to unstage a file. Overall, I get more granularity on which files I want to add to that commit. This comes in really handing when reverting, merging and rebasing. So in my workflow, I don't want to give up control of these things. Apparently, while I don't use these features, `git bisect` and `git blame` also benefit from being thoughtful with commits. > It shows the Git commands it runs for you, as well as their output. I am glad to hear that. > nor does it try to shield you from learning how Git works This is what irks me. I view git as high level and opinionated already, and have no way of knowing how it would effect someone learning git. I developed my own habits w/ VCS a long time ago. That said, leave it up to the people who want to try your project. (I followed you and starred your repository.)
- crdoconnor 9y ago
  >This is what irks me. I view git as high level and opinionated already However high level you think it is, it has no opinion on workflows and there's a need for a tool that will automate and enforce git workflows. I'm not sure if this tool the answer, but there is a need for some sort of tool like this. I wrote a hacky 'git sync' script at an old company and it achieved what sending a bunch of developers on a course about git did not (it sped up the workflow and cut down on git errors).

humanrebar 9y ago

I mostly agree but we don't exactly expect devs to call gcc or javac directly. Make, maven, Gradle, etc. all have their place as well.

throwme_1980 9y ago
comparing this glorified set of aliases to Maven and gcc shows a fundamental misunderstanding of said tools
- humanrebar 9y ago
  ...you're just overanalyzing what I said. I just meant that git stays out of the workflow business and higher level tools might be able to fill in the gap. I'm not sure I'd use this tool, but I'm not going to get upset if people like it.

throwme_1980 9y ago

This right here, this thing will only attract new developers and will delay the inevitable - which is learning git properly. Reminds of a banana peeling machine ....

Certhas 9y ago

The git model for a context where not everyone is a software developer is: Use these three git commands you have memorized. If something breaks ask the person who understands git. That is the reality. Anything that makes people more productive, especially in contexts where the difference between staged/unstaged and all the other things you mention, don't matter, is very very welcome.

saurik 9y ago

While I absolutely agree that you should know how your underlying tools work--and the way I teach people git is to start at the representation level and work up, showing all the file formats in play so people can see how it actually works--I disagree that "git is an especially poor choice for wrappers"... almost all of the tools people normally use with git--the ones that come with git and one might argue "are git"--are also just wrappers (called "porcelain") over lower level tools... most people I know who feel they are sufficient in git only actually know how to use these higher-level tools.