Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

More Productive Git

increment.com

Post reply on HN
Print view View original

21–30 of 147 posts

Re: More Productive Git

#21

Post by CardenB »

ChrisSD wrote: post #8
wyldfire wrote: 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.

I find the staging area useful. It especially helps when you only want to commit a change in part of a file or just generally reviewing a commit before it's a real commit. And also to double check I'm not going to be uploading any secret keys (which seems to happen to people more often than it should).

I think the staging area should be a more intermediate usage pattern, at least.

Re: More Productive Git

#22

Post by lgeorget »

jc_sec wrote: post #2

There's an article like this every week or so.. I don't get it. Git isn't that hard.. You can pretty much get by 99% of use cases with like four or five commands.

My thoughts exactly. Maybe it's because I've used SVM and Mercurial before but I learned Git very easily. I find the commands and options fairly intuitive once you know you're manipulating a graph of patches.

But I guess this is very subjective. After all, I've never been able to master gnupg despite how long I've been using it for.

Re: More Productive Git

#23

Post by saagarjha »

lgeorget wrote: post #22
jc_sec wrote: post #2

There's an article like this every week or so.. I don't get it. Git isn't that hard.. You can pretty much get by 99% of use cases with like four or five commands.

My thoughts exactly. Maybe it's because I've used SVM and Mercurial before but I learned Git very easily. I find the commands and options fairly intuitive once you know you're manipulating a graph of patches. But I guess this is very subjective. After all, I've never been able to master gnupg despite how long I've been using it for.

> I find the commands and options fairly intuitive once you know you're manipulating a graph of patches.

On the contrary, I find the "graph of patchs/Merkel tree/whatever" model pretty easy to understand, and have difficulty in using the commands to make the tree look like how I want it to.

Re: More Productive Git

#24

Post by saagarjha »

crimsonalucard wrote: post #16

Any interface that forces you to manually visualize a complex internal structure rather than show you the internal structure itself is a design smell. Any interface that forces me to manipulate such a complex structure with obscure textual commands rather than a drag and drop interface is a design smell. The git graph structure is not amenable to command line. When I do "git log" it lies to me. I see a linked list fo…

The command line shows you part of the graph: you choose which part it shows you based on what options you pass it.

Re: More Productive Git

#25

Post by tunesmith »

I found one article, only one, that did more than anything to help me understand git. Can't find it anymore. :-( But it had to do with reflog and how any command could be undone since nothing was truly destructive, and how reflog actually had the edges in the graph and you just needed to know how to repoint them to the right nodes. Or something. This is probably one of my least helpful HN comments.

edit: It might have been this one: https://hackernoon.com/https-medium-com-zspajich-understandi...

Re: More Productive Git

#26

Post by rbavocadotree »

ww520 wrote: post #10

Since started using Magit in Emacs, I found myself using the command line Git less and less. I can perform most Git commands with couple key strokes. Having a UI with integrated workflow with Git is pretty nice.

Despite using git for nearly a decade, I never became "good" at it until I started using Magit. Emacs is worth learning for Magit and org-mode alone.

Re: More Productive Git

#27

Post by mathieuh »

XCSme wrote: post #15

One mistake that I saw several times is cherry picking or merging another branch into the current one, then realizing later that you didn't need those changes yet, and you revert the merge commit. Later, if you actually want to merge the other branch into the current one you will get in trouble as it's already "up to date", as the current branch is ahead. Even worse, if you instead merge the current branch into the o…

You can just revert the revert commit.

Re: More Productive Git

#28

Post by no_gravity »

Put this in your bashrc:

    source /usr/share/bash-completion/completions/git
And you can type "git br" to write "git branch", "git checkout fun" to write "git checkout funky-feature", "git log --na" to write "git log --name-only" etc.

Pretty much every time you press somewhere while writing a git command, it does the right type of completion. And hitting multiple times lets you toggle through the options. So you learn git along the way.

This was one of my most enjoyable productivity jumps when it comes to using git.

Re: More Productive Git

#29

Post by draw_down »

It really is a testament to git’s disaster of a UI that so many of these articles exist. Still, I would take it over any other VCS I’ve used, and I’ve used plenty.

The UI is doubly unfortunate because once you understand git’s concepts, it’s almost miraculous how well it does its job. It just unnecessarily complicates the matter of telling it what job to do.

Re: More Productive Git

#30

Post by jordigh »

jc_sec wrote: post #2

There's an article like this every week or so.. I don't get it. Git isn't that hard.. You can pretty much get by 99% of use cases with like four or five commands.

The proliferation of articles like this is a very very good indication, that, yes, git is that hard, especially if you have to collaborate with other people.

Everyone has a different idea of what git does, what things are called, and different interpretations of the vast git vocabulary. What is a rebase? What is a branch? What is a reset? People have different mental models for all of these things.

Git would be easier if it weren't for all of the git users you have to work with. If you're a git solipsist, you develop your own mental model that works for you and you never have to care what anyone else does when they are using git.

Post reply on HN