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

71–80 of 108 posts

Re: Git add -p: a powerful git feature

#71

Post by recursive »

bowmessage wrote: post #70
mnutt wrote: post #68

Earlier quoted context omitted.

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…

For the future, mnutt: I love Chrome's developer tools, you can directly edit CSS rules from the browser by right clicking on it and selecting inspect element. Helps a lot with these situations!

And it's a gui!

Re: Git add -p: a powerful git feature

#72

Post by to3m »

johnkary wrote: post #61
daveungerer wrote: post #58

Or you could just use a GUI app and save yourself a lot of time. SourceTree (OS X only, free - http://sourcetreeapp.com ) has changed the way I use git since I started using it a few weeks ago. The best thing is the discoverability - you don't need to know about the -p flag, for instance, since it's handled by the UI. Same for many other useful git commands that are hard to remember - they are often a simple option o…

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…

I think denying beginners the GUI is particularly cruel. The command line is much more of an abstraction in this case, I think! - gitk displays the actual tree of this graph that git manipulates, but the command line just prints text ;) It's especially illuminating (or I found it so, anyway) to keep gitk --all open as you do merges, rebases, pushes, fetches, etc., refreshing the display after each operation - it makes it very clear what's actually happening. I found git a bit of a mystery until I realised I could see what it was doing this way, and suddenly everything became clear.

Or maybe that's just me. I don't claim to be the sharpest tool in the box.

But anyway, you need have no fear that people won't get forced into using the command line eventually, just because they like git gui. Any time you want to do anything remotely complicated, you need to drop out of git gui and hit the command line. gitk, for all its ability to display the history in a useful format, is similarly limited (or designed for a specific purpose, if you prefer).

I really didn't get on with GitX, but I don't remember it being a great deal more than git gui and gitk, in the same app, with a fancy OS X-looking interface. So the same would probably apply.

Re: Git add -p: a powerful git feature

#73

Post by motti »

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…

git add -i

Re: Git add -p: a powerful git feature

#74

Post by tomlu »

daveungerer wrote: post #58

Or you could just use a GUI app and save yourself a lot of time. SourceTree (OS X only, free - http://sourcetreeapp.com ) has changed the way I use git since I started using it a few weeks ago. The best thing is the discoverability - you don't need to know about the -p flag, for instance, since it's handled by the UI. Same for many other useful git commands that are hard to remember - they are often a simple option o…

SourceTree is really cool but IME it's best for beginners to start with the command line. I've taught git to quite a few people now and see a correlation between early command line usage and understanding what is going on.

Once you're at the level of git add -p you can probably start thinking about using a GUI if that's your cup of tea.

Re: Git add -p: a powerful git feature

#75

Post by tomlu »

Jach wrote: post #53
tebeka wrote: post #21

So you end up committing untested code? (since you did test the whole change, not just part of it). Sounds like a bad idea to me.

Nothing wrong with committing untested code, it's pushing it as a ref one can reasonably expect people will merge/fast-forward to that it becomes a problem. git add -p is a nifty workaround for the type of people who don't like the workflow of "commit early, commit often" (some people have 'save file' bound to also make a commit) but who still want to have lots of small, contained commits.

Not a huge deal, but it can become problematic when you're using something like git bisect.

Re: Git add -p: a powerful git feature

#76

Post by olalonde »

johnkary wrote: post #61
daveungerer wrote: post #58

Or you could just use a GUI app and save yourself a lot of time. SourceTree (OS X only, free - http://sourcetreeapp.com ) has changed the way I use git since I started using it a few weeks ago. The best thing is the discoverability - you don't need to know about the -p flag, for instance, since it's handled by the UI. Same for many other useful git commands that are hard to remember - they are often a simple option o…

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…

I feel GUIs can be great learning tools to become better with the CLI. I've personally learned a lot of tricks and commands using a GUI Git client.

Re: Git add -p: a powerful git feature

#77

Post by cpeterso »

emillon wrote: post #60
cpeterso wrote: post #59

When preparing a series of commits in a branch, what is the recommended method for editing non-HEAD commits? I know how to git commit --amend the HEAD commit, but how would one modify an earlier commit and rebase/replay the subsequent commits? git checkout the earlier commit and create a new branch from there? In Mercurial, I would use an hg patch queue to hg qpop , qrefresh , then qpush .

"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!

Re: Git add -p: a powerful git feature

#78

Post by Myrmornis »

pielud wrote: post #18

I don't ever use git -p directly, but I use magit ( https://github.com/magit/magit ) for emacs, which makes staging changes this way very easy.

+1 emacs users should definitely try magit for this. I use the git CLI a ton but never for interactive staging at the hunk / sub-hunk level.

Re: Git add -p: a powerful git feature

#79

Post by Myrmornis »

msbarnett wrote: post #31
tebeka wrote: post #21

So you end up committing untested code? (since you did test the whole change, not just part of it). Sounds like a bad idea to me.

None of this implies committing untested code. The index is not a commit; it is a pre-commit staging area. When you use 'git add -p', you are adding hunks to the staging area, not committing them. What's the difference? When you're done staging your patch, you can then check out the staging area and run unit tests on it prior to promoting it to a commit. Doesn't compile? Tests fail? Restage as necessary.

Really? I'd definitely commit before running tests. You can always use reset to redo the commit later. Branches are cheap, commits are cheap.
Post reply on HN