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

51–60 of 147 posts

Re: More Productive Git

#51

Post by alkonaut »

F-0X wrote: post #42
chiefalchemist wrote: post #31

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.

I’m about to roll out git to a team of 30 windows devs of the kind that do NOT like using command line (which is a perfectly sensible thing on Windows I should add, it’s rarely needed there and most command line tools including the shell itself sucks). I assure you they will find it complicated. I’ll insist we switch to git but it’s still going to be an uphill battle. Some will surely struggle also a year from now.

Re: More Productive Git

#52

Post by dearrifling »

no_gravity wrote: post #28

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

On debian this is the default behavior.

Re: More Productive Git

#53

Post by BinaryIdiot »

no_gravity wrote: post #28

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

I don't know why I never thought to look for more completions for git. This is a great tip!

Re: More Productive Git

#54

Post by GauntletWizard »

no_gravity wrote: post #28

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

Here's mine:

    [alias]
      git = !cd -- ${GIT_PREFIX:-.} && git
This turns my most common typo (starting to type a git command, thinking about it, typing 'git' again) into what I wanted it to be.

Re: More Productive Git

#55

Post by mathieuh »

XCSme wrote: post #35
mathieuh wrote: post #27

Earlier quoted context omitted.

You can just revert the revert commit.

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 reverting the revert commit.

I feel like there are workflow things you could be doing to avoid whatever problems you're encountering possibly?

Re: More Productive Git

#56

Post by the_duke »

F-0X wrote: post #42
chiefalchemist wrote: post #31

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.

You are lucky.

I know many devs that only use git through their editor or some other git UI and don't know more than commit, pull and clone in the terminal.

Inevitably they always need help when something gets screwed up, or they jump through endless loops to somehow get the desired result through the UI

Re: More Productive Git

#58

Post by house9-2 »

ggregoire wrote: post #20
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.

Because a lot of people have a terrible workflow. Then they spend 1 hour on StackOverflow searching a magic solution to fix their mess. And there are also those people who inflict themselves unnecessary strict rules for whatever reason. Like those who refuse to rebase and push -f on their own branches. Or those who refuse to use a GUI but keep messing up when diffing, resolving conflicts and staging specific files/li…

I really do not like `push -f` because in the past git default configuration was to push all branches; things have improved now that the default is to push to the current branch.

Recently got turned onto `git push --force-with-lease` which is great.

http://blog.developer.atlassian.com/force-with-lease/

Re: More Productive Git

#59

Post by panpanna »

dearrifling wrote: post #52
no_gravity wrote: post #28

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

On debian this is the default behavior.

Same in Ubuntu.

Bash completion on Ubuntu/debian is out of this world. I can do things like

lxc exec

and get a list of currently running containers.

Re: More Productive Git

#60

Post by claytonjy »

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.

For me, it's never the case that new code I'm writing is SO devoid of value I'd rather pretend I never wrote it, but that's what a reset does. Rather, I keep iterating until I've made clear progress, then commit.
Post reply on HN