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

131–140 of 147 posts

Re: More Productive Git

#131

Post by narnianal »

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

But you could also review the commit before pushing and then modify it instead.

Re: More Productive Git

#132

Post by narnianal »

nexuist wrote: post #4
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.

"Everyone knows four or five git commands, but they're all different ones."

Just learn all ten and be done with it. You wouldn't work in a factory with professional tools without learning to use the tools either. So why not just learn this professional version control system in and out. It's not that hard either.

Re: More Productive Git

#133

Post by narnianal »

Stratoscope wrote: post #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,…

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

Or simply learn to use the git commands right. Then it shows you everything the UI tool would show.

I recommend everybody adding this to their ~/.gitconfig

    [alias]
        lol = log --oneline --graph --decorate
        lola = log --oneline --graph --decorate --all
        lols = log --oneline --graph --decorate --all --max-count=10
Then you can simply do a `git lol` or `git lola` to get the same result as your fancy UI is showing you. And it also works via ssh. If you've manually typed that alias in a few times you will also remember it and have it readily available when you ssh into a customer server etc.

Re: More Productive Git

#134

Post by narnianal »

dmh2000 wrote: post #79

thanks for telling me about 'git amend'. I frequently screw up and fail to add the files I want or as soon as I commit I remember I needed to change something else. So my projects all have strings of commits that are a few seconds apart.

`git amend` and `git rebase -i` are two core features of git. It's okay if especially interactive rebasing takes some time to get used to. But it should certainly be part of every users standard tool set.

Re: More Productive Git

#135

Post by XCSme »

mathieuh wrote: post #55
XCSme wrote: post #35

Earlier quoted context omitted.

Biggest issue is the first part, when it's "already up to date", so then when you merge the feature into the current branch and think it's merged, it will actually be missing, so you might forget to revert the revert, or not work anymore because of new commits/conflicts.

I honestly can't say I have ever had this problem. I also don't understand how you could forget to revert the revert? And why would new commits matter? Sure you may have conflicts, but you would have had them anyway if you hadn't reverted. We've had to revert commits on our master branch after several commits have been added on top before, and we've never had an issue just checking out a branch off master and reverti…

You can easily forget if someone else (not yourself) did this (they merge the branch and reverted it), later when you try to merge the branch it could be successful, without any merge conflicts, but still won't lead to the expected changes.

Re: More Productive Git

#136

Post by pmeunier »

User23 wrote: post #100
alkonaut wrote: post #49

Earlier quoted context omitted.

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 em…

Pijul looks cool, but "replace hard to understand directory content snapshots with easy category theory" isn't a compelling proposition outside of maybe the ML/Haskell community.

The main point of Pijul is, you never have to think about categories when using it. It's just a sort of Git where you almost never need to branch (the equivalent of a Git branch in Pijul is just a patch), merges are always deterministic and easy to understand, cherry-picking is the default, and works even for conflict resolutions.

Re: More Productive Git

#137

Post by kyberias »

jedberg wrote: post #48
kyberias wrote: post #34

Earlier quoted context omitted.

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.

Because git reset --hard is kinda dangerous, I've resorted to managing my changes with other safer commands. I undo changes with git checkout. Sometimes I stash and forget.

I only use git reset --hard when I have accidentally committed something to an incorrect branch and I want to reset that branch to point to a specific commit after creating another branch.

I strive for perfection in other areas of my like as well. :)

Re: More Productive Git

#138

Post by kyberias »

atq2119 wrote: post #96
kyberias wrote: post #34

Earlier quoted context omitted.

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

git reset --hard makes a lot of sense with printf debugging. A typical workflow starts by adding printfs or whatever your equivalent is until you've narrowed down the bug. Then you fix the bug, keeping the printfs until the fix is confirmed. Then you use git gui or an equivalent tool to form the commit(s) for your bugfix. Finally, use git reset --hard to remove the debugging detritus.

Ok, I have to admit I've forgotten people actually (need to) do development/debugging like that.

Re: More Productive Git

#139

Post by __MatrixMan__ »

rbavocadotree wrote: post #26
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.

Vim zealot here. Been tempted by org mode. This comment pushed me over the edge--I'm gonna give Emacs a try. Winces and waits for the world to explode

Re: More Productive Git

#140

Post by zaiste »

__MatrixMan__ wrote: post #139
rbavocadotree wrote: post #26

Earlier quoted context omitted.

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.

Vim zealot here. Been tempted by org mode. This comment pushed me over the edge--I'm gonna give Emacs a try. Winces and waits for the world to explode

Long time Vim user here as well. I started my transition to Emacs few years ago. Along the way I discovered Emacs Doom distribution, which is specifically created for Vim users (and similar to Spacemacs, but lighter), and I never looked back.
Post reply on HN