Hacker News Reader

Comment by tony | Hacker News Reader

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.

View on HN

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.

> 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/

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.)

>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).

> it has no opinion on workflows

Oh really? Staged/Unstaged + Commit + Push to remote+branch. Branches (I suppose you could chuck everything in master), and opt-in or out of tagging.

Maybe users will keep their own remote repositories ("forks")? Even then, it's still pulling in code with the same history that's going to get reconciled via a merge or rebase. Whether it's "forked" to their own repo or in a branch of the "main" repo, it's all the same in the end.

> there's a need for a tool that will automate and enforce git workflows

There's easy, light-weight branching baked right into git.

They scale locally, remotely, and also work with different user's remotes.

You can also merge branches into branches. You can pull --rebase them as well.

> there's a need for a tool that will automate and enforce git workflows.

Beyond branches and remotes?

> 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).

Checking out branches and git add/status/diff/commit/push is that time consuming not only would you need to create a shortcut, other devs would opt-in to it?

I use shortcuts for various things in my shell. I have a .gitconfig in my dot-config files (https://github.com/tony/.dot-config). Personal tweaks for coloring and editor settings, a global gitignore. I'm the kind of a guy who picks up shell plugins for fun to try them, but I know that pushing a tool on top of a VCS on colleagues won't go over well.

What did `git sync` do?

>there's a need for a tool that will automate and enforce git workflows. Beyond branches and remotes?

Yeah, because most branching and merging in a team setting follows a policy. That branch/merge strategy (and naming) is based upon a whole host of things including testing strategies, release schedules, issue tracker used, code review policies, how much you need bisect, etc.

Git is entirely indifferent to those workflows and is as happy to let you follow it as it is to let you commit and push directly to the master branch with a commit message of "fixed shit".

>Checking out branches and git add/status/diff/commit/push is that time consuming not only would you need to create a shortcut, other devs would opt-in to it?

Yeah, when you add stashing, changing to the correct branches, rebasing and pushing, changing back and unstashing it actually does get tedious, especially since I needed to run it about 20 times a day.

I actually didn't even create the script for them originally, I created it for me and they just started using it.

"This is what irks me. I view git as high level and opinionated already,"

I've always found this very strange when it's creators don't feel the same way :)

It was built as a low level content addressable filesystem, it's own docs says they weren't even trying to pretend otherwise until version 1.5.

It's only relatively recently (in the scheme of things) it's tried to become higher level.

> 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.

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/

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.

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.

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.

comparing this glorified set of aliases to Maven and gcc shows a fundamental misunderstanding of said tools

...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.

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 ....

Reply on news.ycombinator.com