Live data from Hacker News

More Productive Git

increment.com

41–50 of 147 posts

Re: More Productive Git

#41

There's one of these articles at least once per week that makes it to top of HN. When are we collective going to come to the realization that Git is a corded drill in a battery-powered drill world? Don't get me wrong, version control is necessary. Obviously. But if a plumber, a word-worker or some other artisan used a tool that required a weekly "It's okay, you'll catch on eventually" article, we would have never got…

These articles aren't for the Artisan - they are for, in your metaphor, the apprentice and journeyman.

You should do a lot of learning on using a table saw before you touch one. Using git wrong won't kill you, using a table saw wrong will.

Re: More Productive Git

#42

There's one of these articles at least once per week that makes it to top of HN. When are we collective going to come to the realization that Git is a corded drill in a battery-powered drill world? Don't get me wrong, version control is necessary. Obviously. But if a plumber, a word-worker or some other artisan used a tool that required a weekly "It's okay, you'll catch on eventually" article, we would have never got…

On the other hand, I don't know who these articles are really for. I have _never_ met a developer who struggles with git. Not many claim to understand it deeply, but all can rebase, cherry-pick, use the reflog, etc. and almost never do they run into issues.

It mystifies me. Git isn't hard, nor complicated. "Checkout" has a few too many meanings, and thats the singular gripe I have with it.

Re: More Productive Git

#43

There's one of these articles at least once per week that makes it to top of HN. When are we collective going to come to the realization that Git is a corded drill in a battery-powered drill world? Don't get me wrong, version control is necessary. Obviously. But if a plumber, a word-worker or some other artisan used a tool that required a weekly "It's okay, you'll catch on eventually" article, we would have never got…

It’s not obvious to me that a battery powered drill is the best tool for the job. If you are a professional doing non-trivial work sometimes the corded drill, with all its benefits, is exactly what is needed.

Re: More Productive Git

#44

There's one of these articles at least once per week that makes it to top of HN. When are we collective going to come to the realization that Git is a corded drill in a battery-powered drill world? Don't get me wrong, version control is necessary. Obviously. But if a plumber, a word-worker or some other artisan used a tool that required a weekly "It's okay, you'll catch on eventually" article, we would have never got…

I think experience has shown that some people really like tools that others find really awkward. Sometimes even over the same features described in completely different ways. It is counterintuitive and different from other VCS and reuses commands to mean very different things (especially checkout and reset); that doesn't matter to people who are used to methodically learning these things from first principles.

Plus there's an intrinsic elitism in it being hard to use.

Re: More Productive Git

#45
If you really want more productive Git, stop playing the Git Adventure Game!

When you poke at your repo on the command line, you never get to see it as a unified whole. All you can do is try a command, see what it prints out, and try to make a mental model of what this all means.

A good Git GUI will show you the state of your repo and unify all of the scattered concepts of the command line like the index, the reflog, and stashes.

SmartGit is my favorite. I've also heard good things about Tower, although it's only available on Mac and Windows, not Linux. (SmartGit supports all three.)

A couple of examples from the article:

> The process of a cherry-pick is brief. First, we identify the SHA for the commit or commits you want to pick, using git log or the like. Next, we check out the branch we want to apply the commit(s) to. We then pick the commits.

  git cherry-pick d8119f49cd4fd6b0366c5ca3af205f9c25af89ba
In SmartGit, you see the commit you want to pick in the log, right click it, and select Cherry-Pick.

> Another common issue is committing and then discovering you missed something in that commit. Sure, you could make an edit and add another commit, but sometimes you want to maintain all related changes in a single commit. In this case, you can use the git commit --amend command to fix it up.

> Let’s say you’ve edited useful_func.clj and then committed it.

  git add useful_func.clj
  git commit -m "Added even more useful function"
> But you forgot to commit your code and document your new function. Instead of editing and committing again, you can amend. Make the required changes to the useful_func.clj file, then add it again:

  git add useful_func.clj
> But instead of running a normal commit, run an amendment.

  git commit --amend --no-edit
> This will amend your last commit with your new changes and commit it. The --no-edit flag tells Git not to launch the editor and skip amending the commit log message. If you want to update the commit log message too, you can omit this flag.

In SmartGit, you use the same Commit dialog as a normal commit. It's on the menu, or Ctrl+K (Command+K on Mac) will take you right there. The Commit dialog has an "Amend last commit" checkbox which is normally unchecked. Simply check that box and it will do an amended commit. You can either keep the previous commit message that is displayed in the dialog, or edit it right there.

A couple of other topics the article doesn't touch on...

What about the index? In SmartGit, you can either use the index or ignore it as you see fit. I rarely use it myself. The Commit dialog just does the right thing when I ignore the index, committing my working tree changes directly. And if I do want to use the index, it's easy to get to from the same dialogs.

One of my favorite features in SmartGit is how it handles the reflog. Instead of printing out a list of hashes and poking through them to find the one you need, simply click the Recyclable Commits box in the log view. Now every commit in the reflog shows up as part of the normal commit log tree. You can work with these commits just like any other.

It does the same thing with stashes. Click the Stashes checkbox and they show up in the commit log too. (I wonder how many Git users realize that a stash is simply another commit by a different name?)

Maybe you're not sure exactly what was changed between two fairly distant commits? Click one of them, and then Ctrl+click the other. Now the Files panel shows you exactly which files were changed between these two commits and the exact differences.

I could go on for a while, but what I really wonder is why so many developers are reluctant to even try a Git GUI like SmartGit. It is so much more powerful and productive than the command line adventure game.

Re: More Productive Git

#46
post #41

There's one of these articles at least once per week that makes it to top of HN. When are we collective going to come to the realization that Git is a corded drill in a battery-powered drill world? Don't get me wrong, version control is necessary. Obviously. But if a plumber, a word-worker or some other artisan used a tool that required a weekly "It's okay, you'll catch on eventually" article, we would have never got…

These articles aren't for the Artisan - they are for, in your metaphor, the apprentice and journeyman. You should do a lot of learning on using a table saw before you touch one. Using git wrong won't kill you, using a table saw wrong will.

Messing up a rebase and then force pushing your altered history might at least equate to shaving off a small chunk of finger :-)

Re: More Productive Git

#47
For many of us git should be a multiplier - spend time doing your code and experiments in a safe way, because git, used well, will protect you. As such, learn the tool! Pro Git[0] is great, and you learn the how, but more importantly the why of the tool, so that you can make git a multiplier.

[0]https://git-scm.com/book/en/v2

Re: More Productive Git

#48
post #11

Earlier quoted context omitted.

What makes you say that? I use that command nearly every day.

There is something wrong with your workflow if you have to use git reset --hard nearly every day.

Why in the world would you say that? I check out a branch, I write some code, it doesn't do what I want, I do a git reset and try again.

If you aren't using git reset that means you're either a genius coder who doesn't make mistakes, or you are a coder who would rather keep going down a bad path instead of just starting fresh. Some people find it easier to just start fresh.

Re: More Productive Git

#49

There's one of these articles at least once per week that makes it to top of HN. When are we collective going to come to the realization that Git is a corded drill in a battery-powered drill world? Don't get me wrong, version control is necessary. Obviously. But if a plumber, a word-worker or some other artisan used a tool that required a weekly "It's okay, you'll catch on eventually" article, we would have never got…

Agree (And ironically of course some people agree on this in the discussion on every one of these articles).

Git is the C++ of version control. Of course it’s powerful. Of course it can do everything. And of course it’s a huge frustrating footgun with error messages that rival any c++ template compiler error.

The problem is that we have made it a de facto standard so it’s hard to replace. Even if a much better VCS emerged tomorrow, it doesn’t help if there isn’t support in large issue trackers, CI/CD systems, IDEs and so on.

I have great hopes that pijul will be the better git. But again, it’s the tooling and ecosystem that matters, not the qualities of the vcs itself.

Re: More Productive Git

#50
post #6

Earlier quoted context omitted.

> Git isn't that hard. It's not, but if you don't use it mostly every day, or if you decide to "Delete repository and clone again" every time there's a problem, you won't ever get to learn how to fix it. The staging area is totally unnecessary IMO. I think git would be easier if we didn't have it. The term `checkout` is multiplexed to do more things than I would've guessed.

> The staging area is totally unnecessary IMO. I think git would be easier if we didn't have it. Staging area / Index is one of the best features of Git for me. If I end up having a bunch of semi related changes in-progress; being able to easily group those into individual commits is great. > The term `checkout` is multiplexed to do more things than I would've guessed. Agree

You can do that in svn too with the "changelist".
Post reply on HN