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

Git add -p: a powerful git feature

johnkary.net

Post reply on HN
Print view View original

101–108 of 108 posts

Re: Git add -p: a powerful git feature

#101

Post by masklinn »

microtonal wrote: post #97
w0utert wrote: post #89

Earlier quoted context omitted.

In general I agree. In the case of git, I disagree. The git CLI is downright terrible and dangerous to use unless you're already a git pro, I would never ever force a git newbie to stick with the CLI instead of using a GUI like SourceTree (which is fantastic). I've used CVS, Subversion and Mercurial in the past and never needed or wanted a GUI, but with git, I don't even want to be bothered by all the inane commands…

The git CLI is downright terrible and dangerous to use unless you're already a git pro, The Unix CLI is far more dangerous than Git. Also, there not very much you can do really wrong if you regularly push to a remote repository, as long as you don't push with force. And don't we all do backups anyway?

> The Unix CLI is far more dangerous than Git.

Not necessarily: the Unix CLI has more powerful ways to saw off your leg, but it won't saw off your leg by accident, it won't destroy your files because you passed a strange flag to `ls`.

Re: Git add -p: a powerful git feature

#102

Post by to3m »

goldfeld wrote: post #99
daveungerer wrote: post #66

Earlier quoted context omitted.

How about staging 8 files out of 10 that are currently modified, with no matching glob patterns for the CLI to use? I don't care how fast your keyboarding is, simply selecting the 8 (even better, select all and unselect the 2 you don't want) and dragging them into the index is the fastest way. Or how about firstly determining which old commit you would like to revert a single file to, then secondly doing the actual r…

Some people literally actually don't have a mouse. It gets that good.

These people can use the keyboard - git has comprehensive command line support, even if it isn't always as quick as git gui.

Re: Git add -p: a powerful git feature

#103

Post by emillon »

cpeterso wrote: post #77
emillon wrote: post #60

Earlier quoted context omitted.

"git rebase -i" is what is commonly used instead of hg patch queues. You pass it the name of the last unchanged commit, and it opens an editor where you define what operations to do on it : fold commits together (fixup, like qfold), stop for editing a commit, reorder them, change their description, etc.

Thanks for the tip!

You're welcome !

Re: Git add -p: a powerful git feature

#104

Post by Evbn »

w0utert wrote: post #98
microtonal wrote: post #97

Earlier quoted context omitted.

The git CLI is downright terrible and dangerous to use unless you're already a git pro, The Unix CLI is far more dangerous than Git. Also, there not very much you can do really wrong if you regularly push to a remote repository, as long as you don't push with force. And don't we all do backups anyway?

>> The Unix CLI is far more dangerous than Git. Also, there not very much you can do really wrong if you regularly push to a remote repository, as long as you don't push with force. Sure, but that's not really an excuse for git to have such a confusing and possibly destructive command line. I'm not a GUI person at all, but the times I had to lookup 20 different ways that 'git reset' worked, or had to google what on e…

3 comments up I predicted 'reset' would make an appearance. What is the point of having multiple command names if the command name says nothing about its behavior, and the command flags trigger completely diverse functionalities? Just have the CLI be git -a to git -zz and stop teasing users.

Re: Git add -p: a powerful git feature

#105

Post by Evbn »

rogerbinns wrote: post #62
johnkary wrote: post #61

Earlier quoted context omitted.

I never advocate GUIs as the primary means by which a developer works with version control. Sure it might be OK for some things like browsing history (GitX) but most GUIs often abstracts away much of the underlying complexity, which is absolutely great if you're a designer without much command-line experience, but absolutely a disservice to your in-depth knowledge as a developer and the tools you rely on every day. I…

Do remember that half of all developers are below average/median for the relevant group. (See also "perpetual intermediates".) My experience has been in forcing developers to use guis to do commits. It significantly improved their commits because they would browse over the changeset, could commit only specific hunks, didn't accidentally include extra gunk like test files, and generally made better messages. It is cer…

What does a graphical diff and GUI message editor with interactive changelist management have to do with being "below median"? I came to write code, not restart my workflow from scratch every time I want to slightly edit my change.

Re: Git add -p: a powerful git feature

#106

Post by Evbn »

mnutt wrote: post #68
yuvadam wrote: post #64

Earlier quoted context omitted.

Save time with a GUI? Seriously??? Keyboard strokes are, by any definition, much faster than mouse pointing-and-clicking. I have yet to find a single GUI that gets stuff done faster than what I can achieve with a command line prompt.

I can't imagine myself using a GUI for git, but there are some things that are faster with a GUI and mouse than with a keyboard. Almost all of them involve some kind of visual feedback. For instance, lately I've been working on some projects that involve absolutely positioning HTML elements on the page. This is a huge pain using a text editor--you make an estimate, save it, reload the page, see how it looks, and repe…

TermKit author got mad at the community last year and went underground. :-( No idea if it will ever launch.

Re: Git add -p: a powerful git feature

#107

Post by Evbn »

daveungerer wrote: post #66
yuvadam wrote: post #64

Earlier quoted context omitted.

Save time with a GUI? Seriously??? Keyboard strokes are, by any definition, much faster than mouse pointing-and-clicking. I have yet to find a single GUI that gets stuff done faster than what I can achieve with a command line prompt.

How about staging 8 files out of 10 that are currently modified, with no matching glob patterns for the CLI to use? I don't care how fast your keyboarding is, simply selecting the 8 (even better, select all and unselect the 2 you don't want) and dragging them into the index is the fastest way. Or how about firstly determining which old commit you would like to revert a single file to, then secondly doing the actual r…

They day I learned that gvim has support for mouse hover tooltips, was a great day.

Re: Git add -p: a powerful git feature

#108

Post by rogerbinns »

Evbn wrote: post #105
rogerbinns wrote: post #62

Earlier quoted context omitted.

Do remember that half of all developers are below average/median for the relevant group. (See also "perpetual intermediates".) My experience has been in forcing developers to use guis to do commits. It significantly improved their commits because they would browse over the changeset, could commit only specific hunks, didn't accidentally include extra gunk like test files, and generally made better messages. It is cer…

What does a graphical diff and GUI message editor with interactive changelist management have to do with being "below median"? I came to write code, not restart my workflow from scratch every time I want to slightly edit my change.

Because everyone thinks of themselves as being above median, and a wiz at the tools. They know all the flags, workflows etc memorized and think everyone should be like them.

Whilst in the real world the other half do things like 'git commit -a' to make commits which likely picks up unwanted gunk. A gui does not require memorizing flags and makes everything plain.

Post reply on HN